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.

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.

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 map shows how the pieces fit together.

Choose Your Path

Prefer a concrete example? One Patient, Two Workflows 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	Architecture, availability, effort, and pilot acceptance evidence
Connect a second workflow	Connect Another Workflow	Reuse plan, application contract, recovery tests, and an acceptance record
Try a configured service	First Console Conversation	A browser text test, inspected answer, and ended session
Build with Concurrence	First Verified Conversation	A runnable client and verified result, with explicit provisioning prerequisites
Operate and improve	Operating Model, Testing, and Troubleshooting	Owners, failure investigation, evaluation, and recovery steps
Find an exact contract	API Reference	Generated operation and model definitions
Plan a change	Upgrade guidance	Current integration boundaries and relevant historical changes

Understand the System

Read these pages in order for a technical introduction:

1. What Concurrence Does - the product, the problem it addresses, and where it fits in an existing organization.
2. Core Concepts - how workspaces, world-model data, services, agents, Context Graphs, and runs relate.
3. Shared Context and Applications - a visual map of the data foundation, events, and application ownership.
4. How It Works - follow an appointment change from source data to a confirmed outcome and later evaluation.
5. Design Principles - the engineering choices and trade-offs behind that architecture.
6. Operating Model - 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: 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, then Connectors and EHR
How is an agent configured and constrained?	Agent Core, Context Graphs, and Runtime Safety
How does a workflow reach a patient or operator?	Channels and Operators and Escalation
How do we establish that it works and release a change?	Testing and Evaluation, Deployment Model, and Continuous Improvement
Where does data go, and what can we inspect?	Data Residency, Compliance and Audit, and Intelligence and Analytics
What evidence supports a deployment decision?	Evaluating Concurrence

The healthcare use cases 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 provides authentication, endpoint contracts, SDK guidance, and integration examples. Start its Getting Started path when you are ready to implement. The API Reference and Change Logs provide generated operation schemas and historical changes. The Glossary is a lookup reference; Core Concepts 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 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.