> 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. Direct integration calls and event-driven connector delivery have separate contracts and confirmation steps.
## 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 authored workflow still determines what verification is required 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 |
| **Event-driven connector delivery** | A supported write records an event; outbound policy evaluates it for a configured destination | Eligibility, any required review, and the connector's separate delivery outcome |
Supported text integration calls can pause for conversation-scoped approval. The private-preview external write queue is a separate connector review workflow. Neither is 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
