Concord is a semantic contract layer for governed work. It sits between applications, agents, connectors, humans, and durable workflow runtimes. It defines what an action means, who or what is allowed to perform it, what state or memory it touches, which artifacts it produces, and how it must be audited.
DBOS gives durable execution. Postgres gives durable truth. Concord gives the contract for governed work.
Agents do not execute directly. Agents propose commands. Concord governs them. DBOS executes them durably. Postgres records the truth.
Concord is not trying to be an agent framework, a workflow engine, a BPM suite, a policy engine, a connector marketplace, or an observability product. It is the semantic contract layer that coordinates those systems under one governed action model.
Concord standardizes work as a small set of durable, composable primitives.
Audit, business events, and agent-step traces all live in one unified domain_events table, disambiguated by a purpose column. The same row schema serves compliance, product UX, and observability.
Any consequential action becomes: Ingress → Command → Context → Policy → Plan → DBOS workflow / step → Artifact / Memory / Approval / Notification → Domain event (purpose: audit)
| Category | Examples | What they do | Overlap with Concord | Complementary role | Where Concord shines |
|---|---|---|---|---|---|
| Durable runtime | DBOS, Temporal | Durable workflows, retries, steps/activities, timers, queues, recovery. | High — execution semantics, workflow state, retries, idempotency, long-running work. | DBOS is Concord's default runtime today. Temporal is the named future adapter for native saga compensation and workflow versioning capabilities. | Concord defines command, policy, approval, memory, artifact, connector, agent, and audit semantics above the runtime. |
| Agent frameworks & harnesses | LangGraph, CrewAI, AutoGen, custom loops | Run agents — tools, context, memory, planning, subagents, traces, human-in-the-loop. | High around AgentRun, AgentStep, tool calls, subagents, swarms. |
Agent runtimes plug in as adapters inside Concord. | Concord ensures agents propose governed commands instead of directly executing side effects. |
| BPM / process orchestration | Camunda, Flowable, Pega | Model business processes, human tasks, rules, assignments, forms, enterprise visibility. | Medium — approvals, state machines, human tasks, process governance. | Useful for heavyweight enterprise process management; can be downstream or alternative for approval-heavy processes. | Concord is lighter, developer-native, app-local, Postgres-first, and agent/connector/memory-aware. |
| DevOps / SDLC platforms | Harness, GitHub Actions, GitLab CI/CD | Build, test, secure, deploy, and operate software-delivery pipelines. | Medium — pipelines, approvals, connectors, policy, audit, triggers. | Can be invoked by Concord as a connector for deployment or software-delivery commands. | Concord applies the same command contract to non-SDLC actions: bookings, memory writes, reports, agent swarms, external business side effects. |
| Policy engines | OPA, Cedar, custom rules | Evaluate allow/deny decisions and policy-as-code. | Medium around Policy. |
Concord can call a policy engine to evaluate checks. | Concord wraps policy into a larger contract: command + plan + approval + artifact + memory + connector scope + audit + execution. |
| Data & DAG orchestrators | Airflow, Dagster, Prefect | Schedule and run data pipelines, DAGs, assets, task dependencies. | Medium — tasks, dependencies, schedules, retries. | Can be invoked by Concord as an execution connector for data workflows. | Concord covers app actions, agents, memory, approvals, connector governance, and domain artifacts beyond data DAGs. |
| Observability & eval platforms | LangSmith, OpenTelemetry tools, agent-eval systems | Trace, debug, evaluate, and monitor agent or application behavior. | Medium — traces, agent steps, audit, evaluation. | Concord can export traces and audit events to these tools. | Concord records domain meaning, not just runtime spans or model traces. |
| Connector / iPaaS platforms | Zapier, Workato, n8n, custom connectors | Connect applications and automate operations across SaaS tools. | Medium around ConnectorInvocation and triggers. |
Can provide connectors or downstream automations. | Concord governs connector authority, idempotency, approval, artifacts, and audit as part of one action contract. |
| Memory & retrieval systems | Vector DBs, RAG frameworks, user-preference stores | Store and retrieve semantic context or preferences. | Medium around Memory. |
Concord can use them as storage/retrieval adapters via the MemoryStore protocol. |
Concord governs memory reads/writes with scope, consent, confidence, supersession, and audit. |
| Overlap area | Concord stance |
|---|---|
| Workflows | Concord defines what the workflow means; DBOS executes it. |
| Queues | Concord declares semantic queue names (connector_calls, agent_runs, swarm_children, notifications, …); the runtime owns claim, lease, concurrency, and rate limit. |
| Approvals | Concord defines the approval packet, risk, approver, and domain state; the runtime handles durable waiting. |
| Agent tools | Agent frameworks expose tools; Concord turns each tool call into a governed command. |
| Policy | OPA / Cedar / custom rules may evaluate decisions; Concord decides when policy applies and what happens after the decision. |
| Observability | Tracing tools show execution; Concord records domain audit and action meaning. |
| Connectors | Connector systems perform integrations; Concord governs connector operations, scopes, side effects, and artifacts. |
DBOS is not a competitor — it's the intended runtime. DBOS gives Concord durable workflows, steps, queues, retries, schedules, workflow IDs, durable sleep, and Postgres-backed execution semantics.
Concord = what work means DBOS = how work runs durably
Agent frameworks run the reasoning loop. Concord wraps the loop with action governance: every tool call, memory write, connector write, or subagent spawn becomes a governed command.
Agent runtime = decides / proposes Concord = governs DBOS = executes
Harness can be a downstream connector. Concord governs a deploy_service command, then calls Harness to execute a delivery pipeline.
Concord command: deploy_service → policy → connector: harness.start_pipeline → audit
Concord can call a policy engine, but policy output is one part of the action contract. Concord also decides approval, plan, artifact, memory, connector scope, and audit semantics.
Policy engine = decision Concord = decision + consequence
MemoryStore protocol.child_scope ⊆ parent_scope.Do not claim that no one has workflows, policies, approvals, connectors, agents, memory, or audit. Many systems have those pieces.
The stronger claim is:
No one has a clean, developer-native contract layer for governed work that unifies deterministic execution, agentic execution, connectors, memory, approvals, artifacts, audit, and swarms on top of a durable runtime.
Concord's novelty is not any single primitive. The novelty is the unified contract and enforcement boundary.
A concrete illustration of the contract layer in action. The full worked Concord design for this flow is at examples/hotel-booking.html ↗.
| Action | Without Concord | With Concord |
|---|---|---|
| Search hotels | Agent calls a search tool. | Agent proposes search_hotels; Concord checks connector scope; DBOS executes the connector step; results recorded as an artifact. |
| Rank options | Agent returns a ranked list. | Ranking output becomes a typed artifact with lineage and audit. |
| Remember preference | Agent writes memory ad hoc. | Agent proposes a memory candidate; Concord checks consent, scope, confidence, and conflicts before commit. |
| Book hotel | Agent calls the booking tool after user says yes. | Concord creates an approval packet for >$500 bookings; verifies terms / payment / cancellation; DBOS executes the booking step durably with an idempotency key. |
| Cancel reservation | Agent calls the cancellation tool. | Cancel is itself a command; runs the declared compensation (cancel_reservation) against the original book_hotel effect; audit captures who, when, what was undone. |
Concord should not be described merely as a workflow engine or an agent framework. The best category is:
Semantic contract layer for governed work
Alternative phrases that work:
Concord is the missing contract layer between apps, agents, connectors, humans, and durable workflow runtimes. DBOS runs work. Postgres records truth. Agent frameworks reason. Connectors integrate. Policy engines decide. Concord defines the governed action contract that binds them together.
These references ground the comparison categories. Concord's positioning is an architectural interpretation, not a claim that these systems cannot be extended to cover similar ideas.