> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/readme.md).

# Welcome

Understand Concurrence's data foundation, agent workflows, deployment responsibilities, and the evidence used to improve healthcare operations.

Concurrence is a healthcare data and AI platform. Its Health World Model connects source records into shared patient and operational context. Applications, including agents and Scribe, can use that context and contribute observations through configured integrations. Teams define each application's permissions, supervise its actions, and evaluate the results.

{% hint style="info" %}
**Amigo is now Concurrence.** These docs use the new name. Existing API endpoints, SDK packages, and integration identifiers remain unchanged by this documentation update. See [Rebrand and Compatibility](/reference/concurrence-rebrand.md).
{% endhint %}

A useful deployment brings these pieces together. An agent rescheduling an appointment needs the right patient context, current availability, permission to make the change, confirmation from the scheduling system, and a person to handle exceptions. The conversation is one part of the work.

A second workflow can reuse authorized connections, identity mappings, and source-linked context from the first while keeping its own permissions and transactions. The [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) map shows how the pieces fit together.

## Choose Your Path

Prefer a concrete example? [One Patient, Two Workflows](/data/patient-context-walkthrough.md) follows shared patient context from a clinician-reviewed note to a confirmed booking, with source evidence and ownership at each step.

| Your goal                 | Start here                                                                                                                                                                           | Leave with                                                                      |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| Evaluate Concurrence      | [Technical Evaluation Packet](/platform-overview/evaluation-packet.md)                                                                                                               | Architecture, availability, effort, and pilot acceptance evidence               |
| Connect a second workflow | [Connect Another Workflow](/data/connect-another-workflow.md)                                                                                                                        | Reuse plan, application contract, recovery tests, and an acceptance record      |
| Try a configured service  | [First Console Conversation](https://docs.concurrence.com/developer-guide/guides/first-console-conversation)                                                                         | A browser text test, inspected answer, and ended session                        |
| Build with Concurrence    | [First Verified Conversation](https://docs.concurrence.com/developer-guide/guides/first-verified-conversation)                                                                       | A runnable client and verified result, with explicit provisioning prerequisites |
| Operate and improve       | [Operating Model](/platform-overview/operating-model.md), [Testing](/testing/testing.md), and [Troubleshooting](https://docs.concurrence.com/developer-guide/guides/troubleshooting) | Owners, failure investigation, evaluation, and recovery steps                   |
| Find an exact contract    | [API Reference](https://docs.concurrence.com/api-reference)                                                                                                                          | Generated operation and model definitions                                       |
| Plan a change             | [Upgrade guidance](https://docs.concurrence.com/api-reference/change-logs/upgrade-guide)                                                                                             | Current integration boundaries and relevant historical changes                  |

## Understand the System

Read these pages in order for a technical introduction:

1. [What Concurrence Does](/platform-overview/what-amigo-does.md) - the product, the problem it addresses, and where it fits in an existing organization.
2. [Core Concepts](/platform-overview/core-concepts.md) - how workspaces, world-model data, services, agents, Context Graphs, and runs relate.
3. [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) - a visual map of the data foundation, events, and application ownership.
4. [How It Works](/platform-overview/how-it-works.md) - follow an appointment change from source data to a confirmed outcome and later evaluation.
5. [Design Principles](/platform-overview/design-principles.md) - the engineering choices and trade-offs behind that architecture.
6. [Operating Model](/platform-overview/operating-model.md) - who defines the workflow, operates it, and decides what changes.

## Follow Your Question

For the architecture thesis, read [Universal Reasoning and the Liquid World Model](/agent/universal-reasoning.md): how software defines the problem, data supplies evidence, and exact programs, fast decisions, and deliberative models divide the work.

| Your question                                                     | Continue here                                                                                                                                                                                       |
| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How does Concurrence represent conflicting or incomplete records? | [World Model](/data/world-model.md), then [Connectors and EHR](/data/connectors-and-ehr.md)                                                                                                         |
| How is an agent configured and constrained?                       | [Agent Core](/agent/agents.md), [Context Graphs](/agent/context-graphs.md), and [Runtime Safety](/operations-and-safety/runtime-safety.md)                                                          |
| How does a workflow reach a patient or operator?                  | [Channels](/channels/conversations.md) and [Operators and Escalation](/operations-and-safety/operators.md)                                                                                          |
| How do we establish that it works and release a change?           | [Testing and Evaluation](/testing/testing.md), [Deployment Model](/platform-overview/deployment-model.md), and [Continuous Improvement](/agent/pattern-discovery-and-reuse.md)                      |
| Where does data go, and what can we inspect?                      | [Data Residency](/platform-overview/data-residency.md), [Compliance and Audit](/operations-and-safety/compliance.md), and [Intelligence and Analytics](/intelligence-and-analytics/intelligence.md) |
| What evidence supports a deployment decision?                     | [Evaluating Concurrence](/platform-overview/evaluating-amigo.md)                                                                                                                                    |

The [healthcare use cases](/use-cases/use-cases.md) apply these concepts to specific workflows. They are design patterns; provisioning, integrations, and operating decisions determine the deployed behavior.

## Concepts, Implementation, and Reference

This space explains behavior, architecture, and operating boundaries. The [Developer Guide](https://docs.concurrence.com/developer-guide) provides authentication, endpoint contracts, SDK guidance, and integration examples. Start its [Getting Started path](https://docs.concurrence.com/developer-guide/getting-started) when you are ready to implement. The [API Reference and Change Logs](https://docs.concurrence.com/api-reference) provide generated operation schemas and historical changes. The [Glossary](/reference/glossary.md) is a lookup reference; [Core Concepts](/platform-overview/core-concepts.md) explains the relationships behind the names.

Unless a page says otherwise, these concepts describe the Platform API. The Classic API remains supported for existing integrations and has its own resources and contracts. Use the API named in the implementation guide for your deployment.

## Read Capability Claims in Context

A documented interface can require provisioning, configuration, or a particular runtime. The [capability matrix](/platform-overview/capability-availability.md) distinguishes those requirements from private previews, demonstrations, proposed designs, and retired workflows. Confirm the capabilities needed for your deployment before committing to scope or timing.

When evaluating a deployment, trace the claim to its prerequisites and observable result. A recorded request, a completed agent turn, a delivered message, and a confirmed external change are different pieces of evidence.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.concurrence.com/readme.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.