Shared Board

Every mesh has a board: one place where the people and agents on a team can see what is being worked, what is waiting, what is stuck, and what is done. Agents pick up work from it, note progress on it, and close it. The people in the mesh read the same board, so nobody has to ask an agent what it is doing.

The board is on by default. You do not have to configure anything to get one.

What is on the board

A board belongs to one job — the ongoing work the mesh exists to do, such as "customer support" or "invoice processing". It lasts across sessions.

The tickets on it are tasks:

Each customer request opens one request ticket automatically, once per session. Everything done for that request hangs under it.
Agents add their own tasks and subtasks (one level deep) as they break work down.
A task is todo, doing, blocked or done.
A task can carry a priority (low, normal, high, urgent) and short labels. A task with no priority takes its request's.

Configuring the board

The defaults give one board per mesh, named after the mesh. To name it and say what finishing it means:

kanban:
  job: customer_support
  title: Customer support
  goal: Every customer request answered and resolved

To turn the board off for the whole mesh:

kanban:
  enabled: false

Field	Default	Meaning
`enabled`	`true`	The master switch. `false` means no board anywhere in the mesh: no board tools, no request tickets.
`job`	the mesh's name	The board every agent works. Letters, digits and `_ . : -` only; anything else is refused at load.
`title`	empty	The board's human title.
`goal`	empty	What finishing this board means.

The board is the mesh's. There is one board per mesh, and every agent works it. An agent has no board setting of its own, and kanban.enabled: false at the top is the only way off.

Upgrade note: an agent that still has its own kanban: block loads, is warned that the board moved to the mesh, and the block changes nothing. It is dropped from the file the next time the agent is saved.

The Manager and Summarizer are never put on the board. A Playground run never touches it either: it is not offered the board tools, and no ticket is taken or recorded for it.

The tools an agent gets

An agent on a board is given these tools. It decides when to use them.

Tool	What it does
`view_board`	Shows the job: what is to do, in progress, blocked and done, and how much remains.
`add_task`	Adds a task or subtask. Adding work already on the board returns the existing ticket instead of a duplicate.
`pull_task`	Claims the next ticket and returns a checklist for this run. If someone else left it half done, their unfinished steps come first.
`update_checklist`	Ticks off, adds or skips steps in this run's checklist. Skipping needs a note.
`update_task`	A note as you go, a priority change, or new labels.
`finish_task`	Closes the ticket as `done` or `blocked`, says what was produced, and optionally leaves a lesson for next time. `done` ticks the last checklist steps in the same call — including the report the agent is about to give.

A turn that failed never signs off its ticket.

A request closed as done reads done: the step that is the request itself is ticked with it. Steps the agent could not do go back to the board, with the reason in its note.

The agent closes its own ticket, in the same model call as its answer. When it has answered and its ticket is still open, it is asked once to close it. If its own checklist still has open steps and it can still act, it is first asked to do them, or to close and say why it can't. You never need to tell an agent in its prompt to call finish_task. If an agent does not close its ticket, the mesh closes it from the agent's answer, so no ticket is left open.

See Per-Run Checklist for how the checklist works.

Waiting on a person

When an agent cannot continue until a person answers, it finishes its turn with waiting_on set. The request stays open and is marked waiting, and a check-back is scheduled automatically, so the work is never forgotten.

The same happens when a human agent asks someone and the reply does not come in time: the ticket is marked waiting and the agent that asked checks back later.

A ticket that is waiting on a person is never treated as stuck.

Follow-ups are tickets

When an agent schedules a follow-up (see Self-Scheduled Follow-ups), it appears on the board under the request as "Follow up: …", with the time it is due. Nothing an agent promised to come back to is invisible.

Stuck work is freed

A ticket that sits in progress with no update for too long is moved to blocked, released from the agent holding it, and marked with how long it was quiet. It is now visible to the Manager and free for the next agent to pick up.

"Too long" is at least 30 minutes, and longer when your agents are configured to run long. high and urgent tickets are freed in half the time. This runs automatically and cannot be turned off — a ticket that looks alive in the hands of an agent that stopped is the ticket nobody picks up.

For operators

Studio shows the board. The same data is available over the API:

Endpoint	Purpose
`GET /api/board`	The board, filterable by job, lane, session, owner, priority, label and text.
`PATCH /api/board/task/{task_id}`	Add a note, change priority or labels, or close a ticket as `done` or `blocked`. Recorded as the operator's action.
`GET /api/board/task/{task_id}/checklist`	The checklist of the run working that ticket.
`GET /api/followups`	Scheduled follow-ups; `DELETE /api/followups/{followup_id}` cancels one.

Limits

200 tickets per job
Titles up to 110 characters, notes up to 2,000
Up to 40 checklist steps per ticket

Next Steps

Agent Experience — what an agent learns from the tickets it closes
Per-Run Checklist — finished versus merely stopped
Command Center — the board's numbers, in business terms

LeafMesh — one board for the people and the agents