Delegation

A work item can be handed to an agent or to a team. The item is the task — not a copy of it filed somewhere else. The same row gains an assignee, a delegation record and, when the work returns, its evidence; its status and its result come back to the same card you delegated from.

Where it starts

Delegate to… appears in three places, all onto the same item: the kanban card's context menu, the matrix card's menu and the list row's context menu. It is one affordance mounted three times, so the surfaces cannot offer different recipients or word the same refusal two ways.

The menu lists the agents available to you, and a Team submenu for teams. With neither, it says so rather than opening onto an empty picker.

The brief

Choosing a recipient opens one compose sheet — the same sheet for a single agent and for a team, because a single-agent delegation is a one-member fan-out and giving it a shorter form would let it skip the boundary a team dispatch cannot skip.

The sheet collects what the work item itself does not hold:

Field	What it states
Objective	Defaults to the item's title. Override it when the title is too terse to act on.
Output format	How the answer should be shaped.
Tool and source guidance	What to prefer, and where to look.
Boundaries	What the recipient must not do.
Owned files	The files and interfaces this recipient may edit.
Acceptance check	The machine-checkable definition of done, plus how it is verified end to end.

Boundaries are not defaulted to boilerplate. A delegation with no stated boundaries is a delegation nobody bounded, and it is refused with that said plainly.

Tool requests are a request, never an authority. What the recipient actually holds is computed from that recipient's own capability grant, so a delegation can only ever ask for less than the recipient already has — nothing on the wire, and nothing on the row, can widen it.

If the item has dependency relations, the ids it is blocked by travel with the task, so what the recipient is told it depends on and what the surfaces treat as blocking cannot disagree.

Team fan-out: one item, one owner per file

Giving a team an item does not clone it. It splits one item across teammates by file ownership, producing one delegation leg per member — which is why an item has many delegations rather than a single "assigned to" field.

The per-member ownership editor shows every member's files side by side, and the plan is re-checked as you type:

• Two members claiming the same file is refused, naming the file and both claimants. Two agents editing one file overwrite each other, so this is a plan that cannot be carried out correctly, not a plan with a risk in it.
• A member with no files is refused, and so is a team with no members.
• The Delegate button stays disabled while any refusal stands.

Paths are compared case-insensitively, because on a case-insensitive volume two spellings of one path are one file — a rule that let them through would catch the collisions it can see and miss the ones it cannot.

Completion: an agent owes evidence, a person does not

This is the asymmetry at the centre of delegation, and it is deliberate.

An agent completing its own delegated item must show its work. The item must carry an acceptance check, and recorded evidence that the check passed. Without a check, the move to completed is refused — there is nothing a passing result could be measured against. With a check but failing or absent evidence, it is refused too, and repeated refusals are escalated for a person to look at.

A person marking their own item done is not the same act, and is not weakened to fit the same rule. There is no acceptance check to run on "call the plumber", and demanding evidence would either block the item forever or teach people to write a fake check. A person's judgement is the verification.

Which path applies is read from the item's own record of who holds it, so a caller cannot elect the human path for an agent's item merely by asserting it.

For a team fan-out, one member finishing is not the item finishing: a leg counts as verified only when it has both completed and produced passing evidence.

Where the evidence appears

The loop is visible on the item itself. Each delegation leg renders:

• the recipient and the leg's current state;
• Owns — the files that leg was given;
• History — each state the leg passed through, with when and why, so a run that failed twice before passing says so rather than presenting only its last state;
• Acceptance check and End-to-end — the check the leg must pass;
• the verdict in words alongside a pass/fail icon, and the check's own output verbatim and selectable.

Nothing is summarised away: a run claiming to have passed while its output says otherwise is exactly the case a reader needs to be able to see. Where a leg has returned nothing, the item says No evidence recorded yet rather than leaving a blank that could read as "no check was required".

A completed delegation otherwise renders exactly like completed human work — same checkmark, same assignee treatment. Evidence is the only difference, and a person who records evidence renders identically.

Re-delivering an identical result does not grow the history: one thing happened, and the record says so once. New evidence replaces old rather than merging, so an earlier attempt's passing result can never be used to complete a later failure.

Where to go next

• Work Items — the optional fields an item gains when it is delegated.
• Boards — the card the menu hangs off.
• Agent Mesh — how a task reaches an agent in the first place.