> 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/platform-overview/what-amigo-does.md). # What Concurrence Does How Concurrence combines a shared healthcare data foundation, configured agent workflows, and operational evidence within an existing organization. Concurrence is a healthcare data and AI platform connecting patient context, specialized applications, and human operations. The Health World Model preserves source-linked understanding across interactions. Agents, Scribe, and customer applications can connect to that foundation through configured interfaces and integrations while owning the work they perform. Evaluate a deployment by the work it completes: an appointment changed and confirmed, information collected and available to the responsible team, or an exception resolved by an operator. Conversation quality is one part of that assessment. ## The Problem the Platform Addresses Consider a patient trying to move an appointment. Their identity may be stored in one system, availability in another, and the reason for the change only in the conversation. A new time can become unavailable between lookup and booking. A request can be recorded successfully even when the scheduling system never accepts it. The workflow depends on accurate identity, current information, permission to act, and confirmation from the scheduling system. Those dependencies remain even when the conversation itself works well. Concurrence provides configuration, data access, execution, and operational tools for connecting those steps. The implementation team defines the required sources, verification rules, permitted actions, and exception handling. ## A Shared Data Foundation The [world model](/data/world-model.md) retains supported source observations and derives current views of entities such as patients, practitioners, and appointments. Provenance records where an observation came from. Confidence classes and projection rules help resolve competing observations without treating all inputs as equally authoritative. Agents, operators, customer applications, and analysts can use this data through their supported interfaces. Each interface has its own permissions, available records, and freshness. Source mappings and business definitions remain part of the integration design. Source history remains important when records disagree. A patient's report of a new address can be retained even while a stronger source still supplies the projected address. The workflow then determines whether to verify the report or request an external update. ## Configured Agent Workflows Agent workflows are one way to use this foundation. Scribe owns note capture and review; other applications own tasks and transactions. They can read shared context and contribute observations without sharing one operational database or one decision policy. The [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) map explains these boundaries. An [agent](/agent/agents.md) supplies identity and general guidance. A [Context Graph](/agent/context-graphs.md) organizes the workflow into objectives, states, transitions, and eligible tools. A service brings the selected configuration into an operating context, with channel and runtime settings. The runtime combines that configuration with the current interaction and selected data. It can retrieve additional facts, call supported tools, respond, or use an authored escalation path. Model-driven decisions remain probabilistic. Permissions and action validation belong in enforced controls as well as in the workflow's instructions. [Voice, text, messaging, and Surfaces](/channels/conversations.md) deliver different parts of a workflow. Their capabilities, identity rules, and delivery semantics differ. Reusing agent configuration across channels still requires testing each channel and provisioning the relevant resources. ## Operations and Improvement A deployment also needs people who can inspect and act on exceptions. [Operators](/operations-and-safety/operators.md) can monitor and intervene in eligible runs. Supported approval workflows can require a decision on a specific proposed action. External systems report their own delivery or mutation outcomes. [Testing](/testing/testing.md), [analytics](/intelligence-and-analytics/intelligence.md), and [configuration versions](/platform-overview/deployment-model.md) support ongoing improvement of the deployment. Teams investigate evidence, author a candidate change, validate it, and make an explicit release decision. Production observations do not autonomously rewrite or promote the agent. The next application can reuse the foundation built for the first. Evaluate that reuse through an accepted second outcome, the integration effort it requires, and how coherently the workflows operate together. [Connect Another Workflow](/data/connect-another-workflow.md) turns that evaluation into a scoped plan. ## How Concurrence Fits into Your Organization Start with a defined workflow and the systems it needs. Existing systems retain authority over the records and operations they own. Concurrence supplies the configured agent, supported data and action interfaces, and operational evidence; the deployment team connects those capabilities to the organization's processes. The Developer Console supports configuration, testing, and operation. APIs and provisioned data access let customer teams integrate their own applications and reporting. Integration coverage, custom implementation work, and access requirements should be confirmed for each interface. The [operating model](/platform-overview/operating-model.md) assigns responsibility for clinical and operational policy, source access, consent, exception handling, and release decisions. The [deployment model](/platform-overview/deployment-model.md) describes how to move from a baseline to a reviewed release. Hosting, residency, retention, and external data access follow the arrangement agreed for that deployment. Continue with [Core Concepts](/platform-overview/core-concepts.md) for the system's vocabulary, then [How It Works](/platform-overview/how-it-works.md) for the complete interaction lifecycle. --- # 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/platform-overview/what-amigo-does.md?ask=&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.