> 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/operating-model.md).
# Operating Model
How clinical, operational, data, engineering, and Concurrence teams divide responsibility for a deployed workflow and its ongoing improvement.
A healthcare agent deployment spans several owners. The team defining the workflow may not control the source records, scheduling system, communication channel, or people handling exceptions. The operating model connects those responsibilities so a successful agent turn can become completed work.
Start with one bounded workflow and name the people who can make its decisions. The responsibilities below are a planning model; the actual implementation and support commitments belong in the deployment agreement.
## Define the Outcome Before the Agent
For an appointment-change workflow, specify the starting condition, eligible population, permitted changes, required verification, and evidence of completion. Decide what happens when the patient cannot be identified, the external system is unavailable, or the result is ambiguous.
The workflow owner defines success in operational terms. Clinical leaders define clinically consequential boundaries and the evaluation criteria for those boundaries. Engineers translate those decisions into data access, tools, authored configuration, and tests.
An outcome definition can be written before every integration is available. It gives the implementation team a concrete target and exposes which missing data or authority prevents the workflow from reaching it.
## Assign Decision Rights
| Area | Organization's decision | Platform and implementation work |
| ----------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Workflow scope** | Which work is eligible, what completion means, and what stays with a person | Map that scope into agent guidance, Context Graph states, tools, and handoffs |
| **Clinical and operational policy** | Verification requirements, permitted actions, escalation boundaries, and review criteria | Make the policy inspectable in configuration; implement the applicable enforced controls and tests |
| **Data and integration** | Authorized sources, usable identifiers, freshness needs, and external-system permissions | Configure supported ingestion, mappings, retrieval, write-back, and reconciliation |
| **Messaging** | Sending brand, recipient consent evidence, message purpose, and follow-up ownership | Concurrence-managed provisioning and registration where required; configured routing and delivery handling |
| **Live operations** | Staffing, operating hours, who receives exceptions, and how unresolved work is closed | Configure and exercise supported monitoring, operator controls, and transfer paths |
| **Measurement** | Baseline, outcome definitions, relevant segments, and acceptable trade-offs | Configure available evaluations and reporting; connect external outcome evidence where needed |
| **Release** | Who can accept the evidence and authorize a change | Prepare reviewed configuration, targeted validation, rollout, and recovery procedures |
| **Data governance** | Access, residency, retention, and the intended recipients of shared data | Provision the agreed controls and verify actual access and evidence coverage |
The same person can own several areas in a small deployment. Name an accountable owner for each outcome and the teams that contribute to it. Record who can approve scope changes, stop a workflow, and accept unresolved risk. A platform permission grants an operation; the organization's policy determines when its use is appropriate.
## Separate Live Work from Improvement Work
**Live operations** handles the patient interaction and its immediate exceptions. Operators need enough context to act, a supported way to intervene, and a destination for work that cannot finish during the interaction. An escalation instruction is useful only if the relevant person or fallback is reachable.
**Improvement work** changes the system that handles future interactions. The team reviews patterns, forms a hypothesis, authors a candidate, and validates it before release. It can improve a source mapping, a tool, a workflow, or a measure as well as an agent instruction.
The arrows describe team work. Analytics, simulations, and version sets supply supporting capabilities; they do not autonomously approve, promote, or roll back a change.
## Plan the Handoffs That Usually Cross Teams
### Source Data to Workflow
Agree on the identifiers and source records required for an eligible case. Inspect representative joins before launching the interaction: can the intended person, appointment, practitioner, and location be found? Record the expected freshness and the fallback for missing or conflicting data.
A successful connector sync establishes only what that connector's result reports. It is not proof that every relationship needed by the workflow is available to the agent. See [Connectors and EHR](/data/connectors-and-ehr.md).
Keep source availability, mapping quality, and consumer readiness distinct in the operating agreement. Assign the team that can investigate each failure and one owner who coordinates resolution across the complete workflow.
### Agent to Operator
Define the reason for handoff, the context the operator needs, and what happens if no operator answers. Test the applicable listen, takeover, handback, or external-transfer path. Those controls have different behavior and availability across channels. See [Operators and Escalation](/operations-and-safety/operators.md).
### Platform to External System
Agree on what confirms an external action and who reconciles an ambiguous result. Preserve the identifiers needed to find the original request and destination record. Repeating a non-idempotent action is a business decision as well as an integration concern.
Define support hours, severity criteria, notification and escalation routes, and recovery expectations in the deployment agreement. Exercise the handoff with a representative failure before launch so the responsible teams can find the evidence and act on it.
### Evidence to Release Decision
Give the reviewer the candidate configuration, the relevant tests, known gaps, and the intended outcome comparison. Include associated integration or service-setting changes that are outside the pinned agent and Context Graph versions. [Deployment Model](/platform-overview/deployment-model.md) explains how those selections take effect.
## Establish a Review Rhythm
Use a review cadence appropriate to the workflow's volume and consequences. Start with unresolved work, failed or ambiguous external actions, missing evidence, and representative patient interactions. Compare outcome measures using the same definitions and relevant segments.
Assign each investigation to the team that can change the relevant part of the system. A drop in completion could begin in source data, delivery, staffing, a tool, or agent behavior. Preserve confirmed failure cases in the test set so the next change can be evaluated against them.
For the evidence to request during a technical review, continue with [Evaluating Concurrence](/platform-overview/evaluating-amigo.md). For the recurring engineering workflow, see [Continuous Improvement](/agent/pattern-discovery-and-reuse.md).
---
# 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/operating-model.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.
