Chapter I · What xMesh does
Give xMesh a task and a clear definition of done. It assembles an agent crew, runs the work, checks the result, preserves the evidence and returns a durable mission record to the coding agent or operator who requested it.
What xMesh does
xMesh is an Agentic Mesh runtime and control plane for work that needs more than one model response. A mission can recruit specialist agents, coordinate their work, evaluate explicit acceptance criteria and retain the evidence behind the outcome. People can operate the same mesh through xMesh Station; MCP-capable coding agents can commission and follow missions through the bundled xmesh-mcp bridge.
xMesh implements the open Mesh Memory Protocol. The xMesh runtime and cognition core remain proprietary; the protocol is the interoperable boundary between independently governed participants.
The problem is not getting an agent to answer
An agent can draft a plan, inspect a system or write code. The harder questions come after the answer: which agents contributed, what evidence they used, whether the result met its acceptance criteria, whether an independent reviewer agreed, and what the team should remember when a similar problem returns.
Conventional orchestration distributes tasks. Knowledge systems store documents. xMesh connects execution, evidence, verification and retained learning in one mission record, while keeping consequential human decisions visible.
From task to verified outcome
1. Define the mission. State the outcome you want and, where possible, the conditions that make it complete. A natural-language request is enough when you use xMesh through a coding agent.
2. Assemble the crew. xMesh selects available agents whose capabilities and context fit the work. A mission may use a standing team or form a temporary crew.
3. Perform the work. The crew produces the requested result while the runtime records progress, artefacts and evidence.
4. Check the result. Mechanical CHECK: clauses test the parts that can be verified deterministically. Their results remain attached to the mission.
5. Review independently. When a critic is configured, it examines the artefact and evidence separately from the agent that performed the work. Approval, objection and absence of a verdict are distinct states; silence is never presented as independent approval.
6. Return and retain. The requesting agent receives the mission id and can fetch its result later. The original completion, automated checks, independent review and any human ruling remain separate, linked facts instead of being rewritten into one opaque status.
Drive it from your coding agent
Start with the Developer quick start. Install @sym-bot/xmesh, start the local runtime, register its bundled MCP bridge, restart your coding agent, then ask for useful work in normal language.
Run this task in xMesh: review this repository and identify the top three release risks.
The coding agent handles the MCP call and returns the mission id. Keep that id so you can ask the agent to check progress or retrieve the final result later.
| Tool | What it does |
|---|---|
mesh_mission | Run a task in xMesh and return its mission id. |
mesh_missions | Follow live work or retrieve a known mission by id. |
mesh_ask | Ask the mesh a question and receive a grounded, cited answer. |
mesh_recall | Search the mesh’s synthetic memory along a CAT7 category. |
mesh_canon | Read the validated cognition that survived verification. |
mesh_board | Read and manage the shared work board. |
mesh_review | Commission an independent review of an artefact. |
Write useful acceptance criteria
Criteria can combine plain-language expectations with mechanical CHECK:clauses. The current grammar supports five forms.
CHECK: file <path> the artefact exists CHECK: contains <path> <needle> the artefact contains required content CHECK: not-contains <path> <needle> forbidden or placeholder content is absent CHECK: contains-at-least <path> <N> <needle> required content appears at least N times CHECK: run <command> behaviour passes where execution is permitted
Use absolute workspace paths and include at least one substantive check. File existence alone proves only that a file was created; a content or behaviour check gives the reviewer evidence about what was delivered. A malformed clause is rejected before the mission runs.
Independent review is explicit
Verification is configured, not implied. Enable a critic when the mission needs an independent judgement, and use a different model or vendor where stronger separation matters.
XMESH_MISSION_CRITIC=1 XMESH_MISSION_MIND_B=claude XMESH_MISSION_MODEL_B=claude-sonnet-5
A critic can approve, object or fail to return a verdict. xMesh records those outcomes separately. If no critic is configured, the mission can still complete, but its result must not be described as independently reviewed.
What xMesh retains
A mission record can carry the request, acceptance criteria, artefacts, evidence, check results, reviewer verdict, human ruling, cost and the runtime configuration stamp used for the work. This makes two attempts comparable and gives an operator a traceable explanation when a result is disputed.
Replaying work creates a new mission linked to the earlier attempt. It does not overwrite the old result. Human validation or dismissal is also recorded as a later judgement, so the history shows both what the agents produced and what the organization decided.
How cognition moves
Each mesh node has an identity, its own store and its own admission boundary. A node does not expose its private memory to the network. It emits a deliberately bounded projection—a Cognitive Memory Block, or CMB—across seven dimensions of cognition: Focus, Issue, Intent, Motivation, Commitment, Perspective and Mood.
SVAF compares each dimension with the receiver’s own anchors. Those dimension-level signals support one decision about the complete block: admit, quarantine or reject. xMesh applies the outcome to the complete block.
The receiver creates its own semantic geometry. It ignores foreign vectors and re-encodes the projection locally. One local MiniLM transformer supports both SVAF admission and meaning-based recall; the mission model still performs the reasoning. Recall can search durable cognition from finished mission rooms, not only live nodes.
An admitted remix retains lineage to its source. CAT7 is an exchange schema, not a shared business ontology, so participating teams do not have to surrender their vocabulary or pool their stores.
This removes a single pooled cognitive store as a system-wide point of compromise. It does not replace ordinary security: identities, credentials, node stores and deployment boundaries still require protection.
One governed deployment per team
A developer can run xMesh locally for evaluation. A team deployment places runtime state and participant stores under one governed team root. Back up that complete root, and never run two xMesh processes against the same writable state.
Scale by adding independently governed deployments and connecting them through the protocol, rather than making multiple runtimes write to one store. Deployment, backup, restoration and federation are covered in the operations chapters of this Guidebook.