--- title: "Delegation — when an agent hands work to another team member" category: conventions tags: [team, delegation, agents, standard-v33, standard-v34, roadmap] updated: 2026-09-16 owner: rjj status: stable related: - https://meshkore.com/standard#28-delegation-between-team-members-v33-revised-v34 - https://meshkore.com/standard#25-agent-team-v29 --- # Delegation between team members Since **Standard v33 (§28)** any agent in a cluster can hand a step to another member of the team and be woken with its report, and since **v34 (§28.6)** that member is **one session** rather than one session per errand. The normative contract lives in the standard — read it, don't re-derive it: . ## A member is one session The first delegation to `deployer` opens that member's session. Every later one — from any agent, at any depth — goes to the **same** session, busy or not, merged into its next turn. This is the difference between a team and a pool of clones. Five agents that each need a deploy become five briefs in one deployer's hands, and that deployer can see that three of them are one deploy. Five sessions of the same role cannot: none of them knows the others exist, so they deploy the same working tree five times, seconds apart. What follows from it: - **Delivery is live, not a pending queue.** A brief handed to a member mid-turn is merged into its next turn. It receives the batch, not a trickle, and never waits on a scheduler. - **The member decides the order.** The daemon does not sequence or coalesce. A daemon that did would have replaced the judgement it was trying to buy. - **One report can answer several briefs.** `"for":["rq-…"]` names the requests it closes; every agent it closed gets its own wake. Omit it and it answers the whole batch. - **Who is waiting on whom is visible.** The member's session shows in the agents list like any other agent, with the briefs it is holding. This page is the practical guide: how to configure a roster so agents delegate *correctly*, and what to expect when they do. ## The default is one agent, not a pipeline An agent that can delegate will over-delegate if you let it. Three triggers, and nothing else: 1. **The work crosses a module.** Hand off that half, keep yours. 2. **It needs a privileged role.** Deploys, releases and publishing belong to `deployer`, even when the caller knows the commands. 3. **It is long and opaque.** A full verification run, a deploy pipeline — delegate so the caller's turn can END rather than block. Not triggers: "this is big", "this is boring", "I might be wrong about that API". A small fix, its test and its commit are one agent's job. **Order of steps is not a role.** dev → deploy → verify is a *workflow* (`.meshkore/workflows/`), and different projects order the same roles differently. A member card must never encode the sequence. ## Configuring the roster Each card at `.meshkore/team/.md` carries three frontmatter fields (§28.2) on top of the §25 member schema: ```yaml owns: "Backend and API work: relay/API services, daemon endpoints, data layers, workers, schemas." delegates_to: [ui-developer, tester, deployer, commit-pr-reviewer] never: "Frontend work (→ ui-developer) or deploys (→ deployer)." ``` - `owns` is the line **every other member reads** in its catalog. Write it as the answer to "delegate to me when…", not as a job title. A member with no `owns` is invisible and never gets delegated to. - One line each, ≤ 240 characters: they are injected into every other member's system prompt on every spawn, forever. - The card's prose body stays what it always was — that member's own standing instructions. The delegation doctrine is generated by the daemon; don't paste it into the body. A daemon that supports §28 backfills the canonical members on first touch of a project and leaves members you invented alone — a guessed `owns` is worse than none. ## What a delegated child owes 1. **The anchor.** It inherits the parent's `(initiative, task)`, named in its brief, and must not mint a new one: one unit of work, one roadmap entry. 2. **A report.** Its final reply ends with the `⟦report⟧` line carrying `{outcome, commit, files, tests, next, for}`. A missing report is a failure, not a silence. 3. **Trailers.** `Agent: ` plus `Parent: @` (§9.1, v33) — this is how a reader reconstructs which agent tree produced a change. 4. **No diary entry.** The root of the unit of work writes a single `.meshkore/log/.md` entry covering itself and its children, from their reports. The exception to (4): an operation that must be findable by date no matter who asked for it — a release, a deploy, a standard bump — writes its own entry *and* reports to its parent. ## What the runtime guarantees — and what it doesn't Enforced, each with a status code naming the reason: no handing a brief to a session already in your own chain, bounded chain length (`cluster.yaml#delegation.max_depth`, default 3), a bounded number of distinct members you are waiting on (two deploys to one deployer cost one unit, not two), exactly one wake per requester per report, and no wake into an archived conversation. **Not** guaranteed: that the model does what the brief says, or that a verification recipe exists for a project where nobody wrote one. The tree makes those failures visible and bounded inside a single wake — it does not remove them. **Open risk — concurrent writers.** Two agents editing one working tree is a real hazard. Member sessions remove the same-role case — the five deployers are now one — but two DIFFERENT members in one repo is still unguarded. Until your cluster has module leases, keep the fan-out at **1** for single-repo projects and fan out only across sibling repos. ## Working without a daemon From a plain CLI (VS Code, Cursor, a terminal) there is no conversation to delegate from: you are the root. Do the work, anchor it, write the diary entry. The roster is still worth reading — it tells you which parts of the project have an owner with standing instructions.