Concord exists because modern applications now coordinate humans, agents, tools, connectors, memory, approvals, artifacts, and long-running workflows — but no shared contract explains what an action means, who authorized it, what it touched, what it produced, and how it should be audited.
Each piece below is a real operational pain that pushed Concord into existence. Read straight through, or skim the cards and jump to what hurts most.
Each card jumps to the section below.
Agent frameworks are good at reasoning, tool use, memory injection, and multi-step execution. But once an agent can call tools that mutate external systems, write memory, create artifacts, spawn subagents, or ask for approval, the agent loop alone is not enough.
Without Concord, agent behavior often looks like this:
agent decides → agent calls tool → tool mutates system → trace is recorded somewhere
That's too loose for high-impact workflows. Concord changes the model:
agent proposes action → Concord creates a command → policy evaluates the command → approval is requested if needed → DBOS executes the action durably → Postgres records the domain truth
The agent doesn't directly own execution. It proposes work under a governed contract.
Most systems treat deterministic jobs, human approvals, and agent workflows as different categories of infrastructure. Concord treats them as different execution modes under the same primitive contract.
A sync function, async task, connector call, human approval, memory write, artifact creation, agent run, and swarm run all become part of the same governed model:
Ingress → Command → Context → Policy → Plan → Execution → State → Artifact / Memory / Approval / Notification → Audit
The result: deterministic workflows and agentic workflows share the same governance, audit, approval, memory, and connector model.
Connectors are where real-world side effects happen — sending a Slack message, creating a GitHub PR, starting a Databricks job, booking a hotel, writing to a database, charging a payment method. Most systems expose these as tools or thin API wrappers.
Concord treats every connector operation as a governed capability. For each operation, the registry can declare:
The same access pattern works for an in-house HTTP wrapper and a third-party SaaS API. Safe, explainable, versioned.
Agent memory is often treated as a retrieval or vector-database problem. Concord treats memory as a governed domain primitive.
A memory write isn't just data persistence. It often encodes a user preference, team policy, behavioral pattern, or long-lived assumption that affects future actions. Concord makes that explicit:
memory candidate → memory policy → consent check → conflict check → confidence score → scoped memory write → audit event
This prevents agents from silently accumulating durable preferences or facts without governance — the class of bug that's invisible the first day and impossible to unwind on day 30.
Many workflow systems support approvals, but the approval is often just a pause, a button, or a pipeline gate. Concord treats approval as a domain object with a contract:
A hotel-booking approval should include price, dates, cancellation policy, payment summary, guest information, and expiration. A GitHub PR approval or memory-write approval has a different packet. The approval isn't generic — it's specific to the action being authorized.
Modern workflows produce durable outputs — reports, booking drafts, reservation confirmations, GitHub PR summaries, Databricks job results, approval packets, agent research summaries, memory summaries.
Without a shared artifact model, outputs scatter across logs, files, tool responses, chat messages, and database rows. Concord treats artifacts as first-class records with:
Workflow outputs become durable, queryable, reviewable, and reusable across runs.
Subagents introduce a new problem: delegation. If one agent can spawn another, the system must know what role the child has, what tools it can use, what connectors it can access, what memory it can read, what artifacts it can create, how deep spawning can go, how results are joined, how cancellation cascades.
Concord models this explicitly through:
AgentRun SwarmRun AgentInvocation AgentStep JoinStrategy ToolScope ConnectorScope MemoryScope
Subagent spawning isn't an uncontrolled runtime behavior — it's a governed command. The invariant: child_scope ⊆ parent_scope for tools, connectors, and memory.
In most systems, capability definitions spread across prompts, tool schemas, connector configs, workflow code, policy files, agent runtime settings, approval logic, memory rules, and artifact schemas. There's no single source of truth.
Concord introduces a Domain Registry to make the capability graph explicit. It defines and versions:
That graph can answer impact questions like "if we retire this connector operation, which tools break?" and "if we change this artifact schema, which commands produce it?" — questions that today are answered with grep, prayer, and an incident.
Workflow engines and agent frameworks can tell you what executed. Concord records what happened in domain terms.
Instead of only knowing:
step 4 succeeded tool call completed agent trace finished
Concord records:
hotel booking approval was requested user approved the final price and cancellation terms booking connector was invoked with idempotency key reservation confirmation artifact was created travel preference memory candidate was proposed notification was sent to the user
This is the difference between runtime observability and domain audit. Both are useful; they answer different questions.
DBOS gives Concord durable workflows, steps, queues, schedules, retries, and Postgres-backed execution. But DBOS doesn't define what a hotel booking, memory write, approval packet, artifact, connector operation, or subagent spawn means. Concord provides that semantic layer.
The split:
DBOS answers: How does this run durably? Postgres answers: What is the durable truth? Concord answers: What does this action mean, who allowed it, what does it touch, and how should it be governed?
Concord makes governed work composable. A hotel booking, a GitHub PR, a Databricks job, a Slack message, a memory write, a report, an approval request, a subagent spawn — all follow the same contract:
Command → Policy → Plan → Execution → Artifact / Memory / Approval / Notification → Audit
That gives application developers a consistent way to build workflows that are:
Concord isn't trying to replace DBOS, agent frameworks, policy engines, or connector systems. It gives them a shared contract.
DBOS gives durable execution. Postgres gives durable truth. Concord gives the semantic contract for governed work.
Ready for the architecture? The spec covers core primitives, multi-agent extensions, the runtime adapter, and the Domain Registry.
Read the architecture →