Concord Engine

Concord Engine

Scale parallelism. Preserve alignment.

Describe a task. A fleet of agents builds it. They come back with work that is finished, tested and documented — and that agrees with itself, because none of them was allowed to contradict a decision another had already made.

Parallel agents don't scale past the human in the middle. You run five to go faster, four of them are right, the product is broken, and the only thing that catches it is you — reading everything, holding the whole picture, re-explaining choices that were already settled.

That isn't a prompting problem. Your agents have memory and they have verification, and neither answers the question that actually breaks a parallel run:

Did these two agents just settle the same question differently?

Concord Engine answers it by comparison, never by a model, and refuses the second answer at the moment it is written.

Recorded, not drawn. brag/record.mjs runs the real CLI and captures its output verbatim; brag/video.html only renders what was captured. The loop shows the refusal arc — the full run also writes the contract, binds it and briefs four workers first.

What a decision is

This is the part that gets undersold. A "decision" is not a variable name. It is any question two agents could answer differently and both be reasonable — and the cost is never the question itself, it's that nothing goes red.

Four agents implementing four reasonable answers to "what does an error body look like" produce four green test suites and one broken product. That is the whole category, and it is much wider than route paths.

The failure it stops

A refunds feature, split across a backend worker and a client worker. The backend settles the error shape. The client, working in parallel and with no visibility into the backend's files, reaches a different answer:

$ concord-engine decide --unit client --kind convention \

--subject "error response body shape" \ --value 'every non-2xx body is {"code":" ","detail":" "}' --as client

refused this contradicts a decision already in force. d-003 api (lead): error response body shape = every non-2xx body is {"error":" "} because: the client shows it to a person yours: every non-2xx body is {"code":" ","detail":" "}

Adopt the existing value, or supersede it deliberately: --supersedes d-003 --layer pm (an override, recorded as one) --force (record the disagreement for check to surface)

Verbatim from the recording above.

The agent is stopped at the moment it tries to disagree, and told what is in force, who decided it, why, and the two legitimate ways out. Not at integration. Not by you.

Three ways to run it

As a skill, which is how most people will use it. Describe the task; the agent runs the whole loop — authors the contract, binds it, briefs each worker, fans out, gates every decision, runs the acceptance checks, writes the design doc.

/concord-engine:concord-engine add refunds across the API, the client and the schema

/concord-engine:concord-engine migrate us off the legacy auth tables, five workers /concord-engine:concord-engine rename the tenant concept to workspace everywhere

Nothing about the task has to be small, and nothing has to be a route.

As an MCP server, so an agent already mid-task can reach the gate without being handed a workflow. Twelve tools: write_contract, bind_contract, brief_unit, fleet_plan, run_acceptance, generate_docs, cost_report, plus record_decision, binding_decisions, open_conflicts, record_attempt, status.

As a CLI, for humans and for CI. concord-engine check exits non-zero when anything contradicts, which is a one-line pipeline step.

Why this isn't another memory tool

And the obvious way to answer it — store decisions as prose, ask a model whether two of them conflict — is slow, costs a call per check, and is wrong often enough that people stop trusting it. A coordination layer nobody trusts is worse than none, because it adds latency and false alarms to a workflow that had neither.

Concord Engine decides agreement by comparison, never by a model. Decisions are typed and narrow, so a contradiction is a comparison: same subject, different value. No API call exists anywhere in the decision path — there's a test that fails if any file in that path can reach outside the process, and a second one that fails if any file in the package, anywhere, calls a model.

The loop

The gate above is one organ. v0.2 is the body around it: you describe a task, and the fleet that builds it is bound to one set of decisions from before the first line of code.

  describe a task

| [1] CONTRACT the agent authors JSON to a published schema; | the package validates it and stores it v [2] BIND the contract's decisions enter the log at PM layer, | binding before any code exists v [3] BRIEF one brief per unit: its slice, the decisions it must | honour, what it may not decide, how it will be judged v [4] FAN OUT the host spawns one worker per unit, each getting a | brief and nothing else v [5] GATE a worker that tries to decide something contradictory | is refused, told what is in force and who may override v [6] ACCEPT every acceptance criterion carries a command; the run | is not done until all of them exit 0 v [7] DOCS the design doc is generated from the decision log — | what was decided, by whom, and why v [8] COST what the fan-out sent, in bytes

concord-engine spec --schema              # the contract shape, as JSON Schema

concord-engine spec --from contract.json # validate and store it concord-engine bind --contract add-refunds concord-engine fleet --contract add-refunds # every brief, as JSON concord-engine brief --contract add-refunds api # one worker's brief concord-engine accept --contract add-refunds # run every check concord-engine docs --contract add-refunds concord-engine cost --contract add-refunds

Every loop command takes --contract. The MCP server exposes the same set as write_contract, bind_contract, brief_unit, fleet_plan, run_acceptance, generate_docs and cost_report.

The contract

One JSON document. The agent writes it; the package decides whether it holds.

openSubjects is the part people skip and shouldn't. Naming a thing before anyone decides it is what stops two workers inventing two different names for it — see Honest limits for the run where that went wrong.

{

"id": "add-refunds", "goal": "one sentence a reviewer can judge the result against", "scope": { "in": ["..."], "out": ["..."] }, "decisions": [ // binding from t=0, at PM layer { "kind": "api-contract", "subject": "refund endpoint", "value": { "method": "POST", "path": "/api/refunds", "status": 201 }, "rationale": "why this and not the alternative" } ], "openSubjects": [ // known to need deciding, not yet decided { "kind": "convention", "subject": "error response body shape", "note": "the server and the client both serialise this" } ], "units": [ // one worker each { "id": "api", "goal": "...", "files": ["src/api/**"], "mayDecide": ["convention"], // everything else must be requested "dependsOn": [] } ], "acceptance": [ { "id": "a1", "statement": "refunds endpoint returns 201", "check": "npm test -- refunds", "unit": "api" } ] }

Validation is not a formality. A contract is rejected when two of its own decisions contradict each other, when a unit depends on one that doesn't exist, when the dependency graph has a cycle, when a unit has no acceptance criterion, or when a criterion has no command. All of it in one pass, because fixing one error per round trip is the expensive way to find four:

$ concord-engine spec --from contract.json

concord-engine: contract is not valid:

• unit "api" depends on "ui", which is not a unit in this contract
• acceptance[a1] has no check — a criterion without a command is a wish

bind then puts the contract's decisions into the log at PM layer. If one of them contradicts a decision already live, binding refuses — a new contract quietly overriding decisions in force is the exact failure this tool exists to prevent.

What one worker gets

A brief, and not the conversation. This is the actual brief the unit that wrote this file was given. Verbatim, abridged only where marked:

$ concord-engine brief --contract concord-engine-v2 readme

You are one worker on "concord-engine-v2". Your unit is "readme".

GOAL Rewrite README.md around the loop without losing the v0.1 pitch that the gate is the product.

FILES YOU OWN README.md Do not edit files outside this list. Another worker owns them.

DECISIONS ALREADY IN FORCE — these are not suggestions

• [convention] model calls inside the package = no file in the package may call a model or open a network connection; enforced by a test (the one defensible sentence is that agreement is decided by comparison, never by a model — if authoring moves inside the package that stops being true)
• [naming] cli flag for selecting a contract = --contract (every loop command takes it, so it has to be the same word everywhere) ... 3 more decisions in force

WHAT YOU MAY DECIDE nothing — you write code and decide nothing

WHAT YOU MUST NOT DECIDE ALONE naming, convention, api-contract, enum, schema

RECORD A DECISION LIKE THIS — the flags are what enforce the two lists above concord-engine decide --contract concord-engine-v2 --unit readme \ --kind --subject " " --value ' ' --as readme --rationale " "

Omitting --unit skips the check on what you may decide. Use the MCP tool record_decision if you have it; it gates the same way. A refusal means a decision already covers this: adopt the existing value. Do not work around it, and do not --force it.

DONE MEANS [a-readme] the README covers the loop and keeps the gate pitch $ test -f README.md && grep -q 'spec --schema' README.md && grep -q 'refus' README.md && grep -q -i 'estimate' README.md

fleet prints all of them at once,