Core Concepts
The relationships between workspace data, deployed configuration, live interactions, and outcome evidence in the Concurrence Platform.
Concurrence separates workspace data, workflow configuration, and execution records. Data supplies context, configuration defines the intended work, and execution records show what happened. Each has its own lifecycle.
This page introduces the Platform concepts. The Glossary provides shorter definitions, and the Developer Guide maps them to API resources.
Start with the Shared Context and Applications map to distinguish the data platform, change events, and transactional applications. The agent configuration and execution concepts below describe one application family; they are not the lifecycle contract for every application on the foundation.
Workspace: The Shared Boundary
A workspace scopes data, configuration, and access. A service, a patient entity, and an operator's permissions are evaluated within that boundary. Organizations use separate workspaces when they need separate access, configuration, or operational control.
A workspace is not a workflow or a version of an agent. One workspace can contain several services. Creating a workspace also does not provision every channel or establish a particular hosting, retention, or compliance arrangement.
Data: Records, Events, and Projections
Data source
A configured origin of supported records
A scheduling-system connection or a registered intake source
Entity
A modeled person or resource within the workspace
A patient, practitioner, or appointment
World-model event
A source-attributed observation or recorded change
A patient reports a new contact preference
Projection
A derived read view computed from relevant retained inputs
The current projected patient context
Provenance and confidence
Where an observation came from and how its source is ranked on supported paths
Distinguishing a patient report from a verified source record
The world model is the shared event and entity layer. A projection gives consumers a usable read without making them reconstruct the entire history. Projection is asynchronous, and some derived products use their own processing paths. An accepted event can exist before a later read reflects it.
Entity identity also needs an explicit basis. A recognized phone number can help resolve a caller binding; it is not, by itself, the workflow's identity verification. See Connectors and EHR for the current resolution and binding boundaries.
Configuration: What a Service Deploys
Agent
Identity, general behavioral guidance, and communication style
Context Graph
Workflow objectives, states, transitions, state guidance, and tool bindings
Tool
A specific operation the runtime can invoke under its access and execution rules
Skill
A prompt-driven companion definition that can use its declared tools; its state binding controls execution and result handling
Service
The deployment configuration connecting selected agent and Context Graph versions with runtime and channel settings
Version set
A named selection of component versions and supported runtime preferences for a service
Channel use case and binding
Provisioned channel identity and purpose, connected to the service that handles that route
This is a configuration relationship, not a processing sequence. A deployed interaction combines these pieces. State bindings govern workflow tools, while supported runtime and platform tools can also be exposed through service and channel configuration.
Agent guidance and Context Graph instructions steer model behavior. Server-side authorization and tool validation determine which operations may execute. A tool's presence in a prompt does not grant new permissions.
These definitions separate the agent's perspective from the problem it is solving. The same agent can work through different Context Graphs, and a graph can be evaluated with different agent guidance. The reasoning engine combines them with current context and runtime controls during execution.
Version sets can pin agent and Context Graph versions. An unpinned component can resolve to a newer version when configuration is loaded. Source data, generated memory, integrations, and other settings have their own lifecycles; pinning a graph does not freeze the entire environment. See Deployment Model.
Execution: Conversations, Sessions, and Runs
A conversation holds an interaction's history and lifecycle on a supported channel. A session is the runtime context processing the interaction. Continuity, termination, and retained configuration depend on the selected path; a new message does not universally create a new session or reload all configuration.
A run is the operational record used to inspect supported execution in the unified Runs surface. Run inventory and detail connect the operator or developer to the underlying interaction. They do not imply that every kind of listed historical run can still be started.
The reasoning engine uses signals for inputs and typed effects for outputs. An effect can request delivery or report work already executed, such as a tool invocation; it is not always an uncommitted action. Text and simulation can expose materialized effects; native voice uses navigation and engagement prompts within its own streaming pipeline, and provider-owned realtime voice has a separate conversation lifecycle. Shared definitions do not imply identical execution across channels. A generated reply and a delivered reply are separate outcomes.
Input, reasoning, actions, and delivery can have different lifetimes. A tool result can continue work without another user message, while a new request can arrive during a lookup. Tool bindings and channel controls determine how that overlap is handled; stopping a response does not undo an external action.
Context: Current Facts and Memory
World-model context supplies selected entity information. Memory derives useful observations and bounded models from earlier interactions, with scoped recall when more detail is needed. Conversation history supplies what has happened in the current thread, subject to that runtime's context handling. Together with state guidance and tool results, these inputs form the agent's working context.
These inputs serve different purposes. A remembered preference can help the agent communicate; a current scheduling lookup is needed when the next action depends on live availability. Generated memory and summaries can be incomplete and do not replace authoritative retrieval.
A Context Graph describes how work proceeds. The world model describes entities, evidence, and relationships. A workflow can consult related records without its states mirroring those relationships. Memory updates the context available for future reasoning; it does not train model weights or automatically rewrite the agent or graph definition.
Proposed extensions to object memory and execution coordination are documented separately as design direction. Use the current person-memory and channel contracts when scoping a deployment.
Evidence: What a Result Establishes
The meaning of success depends on the boundary being observed:
A retained observation shows what was recorded and its source.
A tool result shows the result exposed by that operation.
A provider receipt supplies the delivery evidence available for that channel.
A target acknowledgement or supported read-back can confirm an external change.
An evaluation scores the evidence available under its definition.
Use those records together to investigate an outcome. A completed run or a favorable evaluation does not establish every downstream result. How It Works follows these boundaries through one workflow.
Last updated
Was this helpful?