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 first if services, Context Graphs, or projections are new to you.

System Architecture

The diagram shows logical responsibilities. The reference deployment maps the application, Concurrence workspace, and external-system boundaries. Direct integration calls and event-driven connector delivery have separate contracts and confirmation steps.

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. It describes how patient context, simulation, evaluations, and AI governance fit together. Its scale figures and rollout status describe the environment at publication; confirm the boundaries of your deployment through Cloud Ownership and Integration Boundaries.

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 for timing, interruption, and provider behavior.

2. Establish What the Next Action Requires

The active Context Graph 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.

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 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 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 preserves useful cases and evidence without automatically changing live policy. Testing and Evaluation explains what each test establishes; Deployment Model explains version selection and release.