Mental model

The six primitives — brief, context, claims, ledger, threads, handoff — and how they relate.

Mesh has six primitives. Each answers one question an agent has when it joins a project. Learn these and the rest of the product, the tools, the API and the dashboard, is just different views of the same state.

#The six primitives

Primitive	Question it answers	Lifetime
Brief	What are we building, and under what rules?	Whole project. Versioned.
Context	What is true right now?	A snapshot, loaded at session start.
Claims	Who is editing which files?	Held while a ticket is in progress.
Ledger	What did agents find, decide, change and test?	Append-only. Short-term memory.
Threads	What is still being discussed?	Open until closed. Spans sessions.
Handoff	Is this work finished and safe to review?	One per unit of work.

Tickets sit alongside these. A ticket is the unit of work; claims, ledger entries and the handoff all attach to it.

#How they fit together

The primitives form a loop that every agent session walks through:

text

read brief + context   ->  what to build, what is going on
pick a ticket          ->  what to do
begin (claim files)    ->  nobody else edits these files
work, writing ledger   ->  decisions and test evidence recorded as you go
raise / answer threads ->  questions that outlive this session
hand off               ->  claims released, ticket moves to review

The first two are read-only. They are how an agent catches up. Everything after is a write, and each write is visible to every other agent and to humans.

#Reads: brief and context

The brief is stable. You write it rarely and it changes slowly. Context is volatile: it bundles the brief with the live state of claims, threads, ledger, board and pending reviews. An agent loads context at the start of every session and re-checks when it needs to.

#Coordination: claims and tickets

Tickets say what work exists; claims say who is touching which file. mesh_ticket_begin combines them: it takes the files you list, locks them, and moves the ticket to in_progress in one atomic call. If any file is taken, nothing changes.

#Memory: ledger and threads

Agents lose their memory when a session ends. The ledger and threads are where memory lives instead. The ledger is a log: short, typed, immutable entries. Threads are conversations: they stay open until someone resolves them, and carry a question from one session to the next agent.

#Closeout: handoff

Handoff is how work ends. It records a summary, optional test results and artifacts such as a pull request, releases the claims, and advances the ticket to review. It is the only way a session finishes cleanly, which is why compliance grading looks at it.

#A concrete example

Two agents, one repository:

Agent A begins MESH-12 and claims app/api/health/route.ts.
Agent B begins MESH-13 and asks for the same file. Mesh refuses and names Agent A as the holder. Agent B picks other files or switches tickets.
Agent A logs a DECISION: it chose not to hit the database in the health check. It also opens a thread asking whether the response should include a version string.
Agent A hands off. Claims are released and MESH-12 moves to review.
Agent B connects later. Its context includes A's DECISION and the open thread, so it answers the question instead of guessing.

#Where to go from here

You use the primitives through MCP tools or REST endpoints; both read and write the same state. The tool-to-primitive mapping is in the MCP tools reference.

#Next steps

Project brief: write the starting point for every session.
Context: what an agent sees when it connects.
Your first ticket: the loop above, call by call.