Chapter I · What xMesh does

A mission is a trade: booked the instant it fills, checked by a counterparty, settled at end of day. What xMesh does, how to drive it from your coding agent, and how cognition moves without pooling every mind.

What xMesh does

xMesh is an enterprise agentic-mesh runtime: you give it a business task and the criteria that would settle it, and it forms a crew, runs the work, grades the criteria mechanically, books the outcome the instant the work fills, has that booking checked by an independent counterparty, and settles the whole day's book at end of day so that only what broke reaches a person. It runs on the open Mesh Memory Protocol; the runtime and the cognition core are proprietary. The unit of work is a mission, and a mission is handled the way a trading desk handles a trade — booked on fill, matched against a counterparty, settled in a batch, never rewritten. Nothing in a mission waits on a human mid-run.

The problem is not getting an agent to answer

An agent can draft a plan, inspect a system or write code. The hard part starts after the answer: who should have contributed, what evidence was used, who carried the consequence, and what the organization should remember when the same class of problem returns. Conventional orchestration distributes tasks. Knowledge systems store documents. Neither preserves the reasoning and the verified consequence that made a result trustworthy.

There is a second problem, and it retired the previous edition of this chapter. The old model ran offer → assemble → perform → verify → learn, and the verify step waited for a human ruling on every mission. That does not scale past a handful of missions a day: the human becomes the queue. The runtime's own measurements made it concrete: across two hundred deliveries with cross-vendor verification switched on, the critic produced zero approvals and zero objections, and nobody noticed — nothing in the model required a verdict to exist before a mission was treated as done. Silence read as consent.

The current model inverts that. A fill books immediately and unconditionally. Verification is a separate obligation with its own record, and a missing verdict is a named state on the book rather than an absence. A human is asked for exactly one thing: a ruling on the bookings that did not match.

Drive it from your coding agent

For a developer, the way to use xMesh is not curl and not a cockpit: it is the coding agent you already sit in. @sym-bot/xmesh ships an MCP server (xmesh-mcp) that exposes the mesh as five tools; register it once and your agent hands the mesh work by mission request and reads the outcome the same way.

{ "mcpServers": { "xmesh": { "command": "xmesh-mcp",
    "env": { "XMESH_URL": "http://localhost:8787", "XMESH_PASSCODE": "<your passcode>" } } } }

The pattern is the one this chapter describes below, driven from a prompt: "post a mission: write the migration plan to /srv/work/plan.md; CHECK: file /srv/work/plan.md; CHECK: contains /srv/work/plan.md ROLLBACK" — the agent calls mesh_mission, the mesh fills it, the counterparty checks it, and end of day settles it. Three seats on one host — a coding agent, a mesh, a wire between them — is a complete developer deployment; the Station is for the operator of a team's mesh, and has its own chapter.

A mission is a trade

Six steps. Each one is an API call you can make yourself; the runtime makes the same calls on its own schedule.

1. Offer. POST /api/worlds records the ask and its criteria as a signed offer. A standing room whose memory fits the ask may host it; otherwise a fresh mission room forms with a doer and, if verification is on, a critic on a different model or vendor.

2. Fill. The doer works, reports progress, and completes with an artefact. The harness grades the criteria mechanically. The mission books at once — delivered, or, if the doer hit a capability it does not have, a root-cause booking with an approval card left open for the operator. The doer's capacity is released at booking; the critic is held. Follow any mission through GET /api/commissions, which carries status, checks, cost and harness.

3. Counterparty. The critic reads the artefact and the doer's evidence log and either approves or objects, on the record. Adversarial review lenses may file their own verdicts against the same fill: a challenge lands as an objection, a searched-and-found-nothing lands as an approval, an unable-to-test lands as nothing at all.

4. End of day. POST /api/eod, or the daily ticker at the operator's hour, matches every booking since the last run against its counterparty. Only breaks reach a person: GET /api/eod/breaks, which names each break's exits.

5. Rule. POST /api/lifecycle/<key> with {"verdict":"validated"} overrules the counterparty; {"verdict":"dismissed"} upholds it. POST /api/commissions/<key>/replay mints a new trade citing the old one as parent; the original booking is left exactly as it booked, with a pointer to the newest replay. A booking is never rewritten. An open mission that has become pointless is withdrawn with POST /api/commissions/<key>/abandon; an already-booked one refuses that call and tells you to replay or rule instead.

6. Read why. GET /api/commissions/<key>/rca returns the break's root-cause report — the fill, the objection, the harness it ran on, and an implicated resource, one of criteria, constitution, rubric, artefact or unclear, each answer naming the evidence it rests on. POST /api/commissions/<key>/rca/deep hands the mesh the causal question: which side does the artefact support, and which single resource change would have prevented the split.

curl -s $HOST/api/worlds        -H "x-mesh-token: $T" -d '{"intent":"…","criteria":"CHECK: …"}'
curl -s $HOST/api/commissions   -H "x-mesh-token: $T"
curl -s $HOST/api/eod           -H "x-mesh-token: $T" -X POST
curl -s $HOST/api/eod/breaks    -H "x-mesh-token: $T"
curl -s $HOST/api/lifecycle/$KEY            -H "x-mesh-token: $T" -d '{"verdict":"dismissed"}'
curl -s $HOST/api/commissions/$KEY/replay   -H "x-mesh-token: $T" -X POST
curl -s $HOST/api/commissions/$KEY/abandon  -H "x-mesh-token: $T" -X POST
curl -s $HOST/api/commissions/$KEY/rca      -H "x-mesh-token: $T"
curl -s $HOST/api/commissions/$KEY/rca/deep -H "x-mesh-token: $T" -X POST

Two missions on the core-team deployment show both endings.

mission-ae8d91 is the first trade that matched. The doer delivered at 85 seconds. The critic, on a decorrelated model, approved. The world settled on that verdict rather than on its timer, and EOD matched the booking and paid the doer's authority. That was the first verdict of any kind the deployment had ever produced.

mission-0979b9 is the other ending, and it is the more instructive one. On 2026-08-18 the doer reversed a word into a file and passed 2 of 2 checks. The critic, running claude/sonnet, objected: "(f) violation — .verify-marigold.sh is deleted at step 18" — the doer had written a helper script, run it, and deleted it, so the evidence log contained a run whose target no longer existed by the time the critic looked. The mission booked delivered. EOD split the doer and the critic and wrote it as a break. The human dismissed it, upholding the critic. The break's root-cause report named constitution as the implicated resource: the objection cites a discipline rule the doer's brief should have carried. Nothing about the original booking changed; the dismissal is a separate event on the same row.

Writing criteria

Criteria are prose plus mechanical CHECK: clauses. There are five kinds and no others.

CHECK: file <path>                              the artefact exists — fabricable; a touch passes it
CHECK: contains <path> <needle>                 the artefact says something — substantive
CHECK: not-contains <path> <needle>             it does not say something — a scaffold mark, a placeholder
CHECK: contains-at-least <path> <N> <needle>    at least N occurrences — substantive
CHECK: run <command>                            behaviour — needs a shell the sandbox usually gates

Use absolute paths under the workspace and write at least one substantive check. A mission graded on file-existence alone is written as a break at end of day, because nothing substantive grounded it.

There is one rule that catches the commonest false green. A file that declares itself unfinished — a status line reading in progress, draft, scaffold or pending — fails every substantive check against it, with that as the stated reason. This exists because on 2026-08-18 exactly such a scaffold passed 8 of 8 checks with 7 of them substantive: it restated the brief's own vocabulary and the grader agreed with it.

A clause the grammar cannot read is refused at the offer, not at the grade. POST /api/worlds and POST /api/commissions return HTTP 400 naming the unreadable clause and listing the five kinds that exist. The earlier behaviour accepted the typo and failed it an hour later, after two mind slots had been spent.

The counterparty

Verification is staffed, not assumed.

XMESH_MISSION_CRITIC=1                  # staff a critic on every mission
XMESH_MISSION_MIND_B=claude             # or codex — a different vendor is the strongest independence
XMESH_MISSION_MODEL_B=claude-sonnet-5   # a different base model when the vendor is the same
XMESH_CRITIC_SETTLE_MS=300000           # the settlement window, default 5 minutes

The critic is fail-closed in both directions. It never falls back to another model when the configured one is unavailable, and its silence is never read as approval: no verdict means no counterparty on the blotter, and the report says exactly that rather than quietly matching the fill.

The settlement window is what makes a verdict possible at all. Booking releases the doer but holds the critic for XMESH_CRITIC_SETTLE_MS, 300,000 milliseconds by default — a critique of a real artefact runs one to three minutes, and five bounds a slow one without leaking a dead one. A verdict releases the critic immediately. Before this existed, booking-on-fill tore down the whole crew at the instant of the completion the critic existed to review; the critic was killed at 64 seconds with exit 143, every time.

One verdict is one counterparty: a remix of the critic's verdict carried by an operator node is not a second, and identical objection text counts once.

End of day

Matching has three outcomes, and each break carries the reason that produced it.

Matched — delivered, all checks passed, at least one verdict on the record and no objection. The doer's authority is paid, once, at EOD. There is no payout at fill: the mechanical tally is the doer grading its own work.

Break — one of four reasons, verbatim from the matcher: delivered with <passed>/<total> checks passing; delivered on file-existence checks only — no substantive check ran; <n> critic objection(s) against a delivery; cross-node judges split on the completion record (<n> judges). A break pays nothing until a human clears it, and that clearing is itself the annotation.

No counterparty — nothing to match against: a root-cause booking, a withdrawal, or a delivery with no critic configured and therefore no approval and no objection. It is confirmed and reported, and it is not paid. Paying an unmatched fill is how a scaffold graded green becomes an authority record at scale.

The breaks queue surfaces one more thing, a late break: a fill EOD matched and paid, which a human then dismissed. The ledger reverses the payout; the day's page still says matched and paid. Rather than rewrite the page, the queue reports the disagreement as a real break discovered late, with the same three exits as any other.

Cost and the harness stamp

Every fill records two things beyond its result. The first is what it cost: input, cached and output tokens, and USD where the provider states it, parsed off the worker's own completion line. The split matters and not just the sum — output runs about five times input and a cache read about a tenth.

The second is the harness it ran on: content-addressed eight-hex hashes of the doer's brief template, the constitution projected into its workspace, the critic's rubric and the check grammar, plus the runtime version, carried on the accept as harness t=… c=… r=… g=…. Without it, two replays of the same mission text could run on different templates and read as one experiment, and a rise in breaks could not be attributed to the rubric edit that caused it.

GET /api/eod/harness reads the blotter grouped by that stamp: bookings, matched, breaks, objections, approvals, matched rate, and USD per matched trade, alongside the harness this runtime would stamp today. That grouping is how a change to the harness is judged — you change one text and the blotter shows the before and after as two groups on real fills, rather than an argument about whether the new rubric reads better.

The four texts are overridable per deployment under <state>/resources/ as constitution.md, rubric.md, template.claude.md and template.codex.md, the templates carrying {{WORK}} and {{CRITERIA}}. A valid override replaces the default whole and is hashed like one, so the blotter cannot tell an override from a deploy — which is the point. An invalid override is ignored and logged once, never half-applied. Validity enforces refine-or-add: a constitution override must still contain every lettered clause of the default, and a rubric override every non-transcript clause, so no edit can silence a rule the critic scores by. The grammar has no override; a proposal against it is a finding for a developer.

How cognition moves

Each mesh node has an identity, its own store and its own admission boundary. A node does not hand its private memory to the network. It emits a deliberately bounded projection called a Cognitive Memory Block, or CMB, carrying seven categories: Focus, Issue, Intent, Motivation, Commitment, Perspective, Mood.

The receiver decides. It evaluates the complete projection against its own context and makes one decision for the whole block — admit or refuse — and an admitted remix retains lineage to its source. CAT7 is an exchange schema, not a shared business ontology; no team adopts anyone else's vocabulary to participate. A receiver cannot query another node's private store as if the organization were one warehouse; it can ask, receive a projection, and decide whether that observation belongs in its own context.

This removes the single pooled cognitive store as a system-wide point of compromise. It does not make security disappear: identities, node stores, runtime registries, credentials and deployment boundaries still need ordinary protection. It is also the line that makes xMesh a mesh rather than a router — the runtime enforces capacity and deadlines, and never decides which cognition a participant must accept.

One deployment per team

Native development uses two local trees: ~/.xmesh/ for sessions, passcode, mission and server state, and ~/.sym/ for the sovereign stores of local mesh participants. A customer or container deployment names one tenant root instead.

XMESH_TEAM_ROOT=/srv/xmesh/acme xmesh
# /srv/xmesh/acme/xmesh   server state
# /srv/xmesh/acme/sym     participant stores

Back up the complete tenant root. Do not run two xMesh processes against the same writable root. Scale by adding independently governed team roots, not writers to one store.

The passcode lives at <team-root>/xmesh/passcode for that root, or ~/.xmesh/passcode on a developer runtime. On a host running several team roots the commonest bad credential is the right passcode for a different deployment, so POST /api/session refuses it by naming the deployment that refused — a public-safe team id, never the root path — with a hint saying that another tenant's passcode is refused here. Wrong tenant and wrong passcode are distinguishable at the caller.

One operational note for macOS launchd. A plist edit is not picked up by launchctl kickstart -k: it restarts the process against the already-loaded job, so the new process keeps the old environment and the variable you just set is silently absent. After changing environment in the plist, launchctl bootout the job and then launchctl bootstrap it, and confirm with launchctl print against the running job. Use kickstart -k only for a code change under an unchanged plist.