> 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/how-it-works.md).
# How It Works
Follow one appointment change through data retrieval, agent decisions, external action, human exceptions, and outcome evaluation.
A deployed workflow connects data, decisions, actions, and evidence. This page follows a patient rescheduling an appointment to show where each part of Concurrence participates. The example assumes a configured scheduling integration and an approved workflow; it is not a default flow enabled in every workspace.
Read [Core Concepts](/platform-overview/core-concepts.md) first if services, Context Graphs, or projections are new to you.
## System Architecture
The diagram shows logical responsibilities. The [reference deployment](/platform-overview/reference-deployment.md) maps the application, Concurrence workspace, and external-system boundaries. Each direct integration call has its own contract and confirmation step.
For a published architecture example, read the September 23, 2026 Databricks partner article [How Concurrence governs clinical AI at a trillion-token scale with Unity Gateway](https://www.databricks.com/blog/how-concurrence-governs-clinical-ai-trillion-token-scale-unity-gateway). It describes how patient context, simulation, evaluations, and AI governance fit together. Its figures describe the environment at its publication date; confirm the boundaries of your deployment through [Cloud Ownership and Integration Boundaries](/platform-overview/cloud-ownership.md).
## Call Lifecycle
The patient calls to move Thursday's appointment to Friday. The same operational goal could arrive through another supported channel, but the channel's identity, consent, continuity, and delivery rules still apply.
### 1. Resolve the Route and Caller Context
The provisioned channel route selects a service. The runtime loads the relevant service, agent, and Context Graph configuration. A supported existing caller binding can resolve the associated workspace entity and provide selected projected context.
Recognition helps locate a record. The record reaches the agent only after the caller's stated name and date of birth match exactly one record, and the authored workflow determines any further verification before disclosure or action. If the caller cannot be resolved, the agent needs an approved lookup, clarification, or human fallback.
On the supported voice path, preparation can begin while the call rings. Speech recognition and speech synthesis carry the interaction once connected. See [Audio Pipeline](/channels/voice/audio-pipeline.md) for timing, interruption, and provider behavior.
### 2. Establish What the Next Action Requires
The active [Context Graph](/agent/context-graphs.md) state defines the objective and relevant guidance. The runtime combines it with the conversation, selected entity context, and available memory. The model can ask for missing information or invoke an eligible tool.
For this example, a projected appointment record establishes useful background. A supported scheduling lookup checks the availability needed for the proposed change. If the patient describes an appointment that conflicts with the available record, the workflow should resolve that conflict before requesting a mutation.
The graph makes the intended sequence and boundaries reviewable. Model-driven navigation remains probabilistic. Required permissions and action validation must be enforced by the corresponding runtime or tool.
### 3. Request the Change Through the Configured Path
After the patient chooses an available time, the agent invokes the permitted scheduling operation. Two common action paths need different treatment:
| Path | What happens | What the workflow must observe |
| ---------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| **Direct integration** | A configured tool calls an external endpoint under its authorization and validation rules | The endpoint's actual result, including an ambiguous or failed response |
Supported text integration calls can pause for conversation-scoped approval. This is not a universal approval gate covering all tools or channels. See [Runtime Safety](/operations-and-safety/runtime-safety.md#write-safety).
Recording a request preserves intent. It does not confirm a booking. If delivery is asynchronous, the interaction needs an accurate pending response and a defined follow-up owner.
### 4. Confirm the Outcome or Handle the Exception
When the scheduling operation exposes a confirming acknowledgement or supported read-back, the agent can communicate the result it establishes. If the outcome is ambiguous, the workflow should preserve that uncertainty and route it for reconciliation. Blindly repeating a non-idempotent mutation can create a second change.
If a person needs to intervene, the [operator workflow](/operations-and-safety/operators.md) supplies the supported controls for that channel. On eligible voice calls, an operator can join by phone, listen, take over, and hand control back. Transfer to an external destination is a different path with its own answer and failure behavior.
For a messaging follow-up, an accepted send, a final delivery receipt, and a patient response remain different outcomes. The applicable [channel guide](/channels/conversations.md) defines the available evidence and prerequisites.
### 5. Retain Evidence and Update Read Views
The interaction can produce transcripts, tool activity, run records, source-attributed observations, and post-call artifacts. Each has its own production and retention conditions. Post-call summaries and intelligence are best-effort; the absence of an artifact needs to remain visible during review.
Accepted world-model observations can later appear in projected state. Generated memory may preserve relevant cross-session context through a separate process. A conversation ending does not mean every projection, summary, evaluation, or external write has completed.
## Measure the Whole Workflow
For the rescheduling example, separate these questions:
| Question | Evidence to inspect |
| ----------------------------------------------- | ------------------------------------------------------------------------------------- |
| Did the agent understand the requested change? | Available transcript and evaluated interaction evidence |
| Did it use the intended process? | Selected configuration, observed graph states, and recorded tool activity |
| Did the scheduling system accept the change? | The operation's acknowledgement, supported read-back, or reconciled destination state |
| Did the patient receive the confirmation? | Channel delivery evidence and any subsequent patient response |
| Did unresolved work reach the responsible team? | The applicable handoff or review record and the team's disposition |
The final business outcome may require customer-system data beyond the conversation. Define that join before using a conversation score as a measure of completed work.
## Improve the Next Version
Operational evidence informs a separate engineering process. The team investigates a failure, changes the relevant data mapping, tool, graph, or instruction, and tests the candidate. An authorized release decision selects what runs next.
This [continuous-improvement loop](/agent/pattern-discovery-and-reuse.md) preserves useful cases and evidence without automatically changing live policy. [Testing and Evaluation](/testing/testing.md) explains what each test establishes; [Deployment Model](/platform-overview/deployment-model.md) explains version selection and release.
---
# 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/how-it-works.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.
