How Agents Hand Work Over

Step 11 · A Team

Four agents with separate access creates an obvious problem: what happens when a request belongs to a lane that is not the one you asked?

The tempting answer is to let agents reach into each other’s systems. I do not, and this page is the alternative.

The rule

Work crosses lanes by handover, never by access.

If the household agent is asked something that belongs to the health lane, it does not go and read the health records. It places the request on a shared board and the health agent picks it up.

That single decision is what keeps the boundaries real. An agent that can borrow another’s access has that access, whatever the documentation says.

The board

One shared board, visible to every agent and to me. Four ideas:

A card is a unit of work. Title, a written brief, an owner, a status.

An owner is an agent. Cards are assigned to a lane, and the lane whose job it is does the work.

The board is the only shared surface. No shared credentials, no shared memory, no side channels. Just cards.

Everything about a card is visible. Its brief, who wrote it, when it moved, every comment, and its full history of state changes.

  I ask the household agent something outside its lane
                    |
                    v
        it writes a card and assigns the owner
                    |
                    v
     that agent picks it up and does the work
                    |
                    v
        the result returns on the card

The shape of a good brief

A handover is not “please deal with this”. It is a finished brief with everything the receiving agent needs, because the receiving agent cannot see the conversation that produced it.

In the brief	Why
The deliverable — what to produce	Otherwise the work is guesswork
Exact inputs — where to find what is needed	The other agent has no access to the original context
One action	Ambiguity is what makes handovers fail
Hard constraints — especially what must never happen	e.g. “do not send anything”
How to prove it is done	So the receiver knows when to stop

The principle I hold to: hand over the deliverable, never the problem. A card that reads “sort out the insurance thing” produces an agent asking questions. A card that reads “produce a one-page comparison of these three quotes, do not contact anyone” produces work.

Rules the board enforces

Nothing is claimed twice. A card is claimed atomically, so two agents cannot work the same job.

Dependencies are explicit. A card can have parents. It stays parked until every parent is done, then wakes on its own. No agent has to remember to come back to it.

Comments are the protocol. Results, questions and follow-ups stay on the card rather than in someone’s head. A question on a card is answered on the card.

Nothing destructive happens without a person. An agent may complete its own work. The transitions that matter — retiring something, changing a system, sending anything outward — wait for me.

What this looks like in practice

A real one. I asked for research into a way to publish documents to a private web address, without spending much.

The receiving agent did not attempt the whole thing. It split it into four child cards — hosting options, authentication options, storage design, and a final proposal — ran them, and the parent card woke automatically when all four were done. The result was a single architecture proposal, attached to the card, with a summary on it.

Nobody had to chase anything, and the whole thing is still readable months later: what I asked, what each agent was told, what came back, and in what order.

Why not let them talk directly

Direct agent-to-agent messaging is tempting and I do not use it for work handover.

• It leaves no artefact. A conversation between two agents is invisible unless you go looking.
• It is unbounded. One agent can ask another for anything; on a board, the ask has to be written down and assigned.
• It blurs attribution. On a board, every piece of work has an owner and a reason.

The board is slower on purpose. Slower is what makes it reviewable.

Checkpoint

• Work that crosses lanes goes through a written, assigned card
• No agent holds another lane’s credentials
• Every handover states the deliverable, the inputs and the constraints
• Dependencies park and wake on their own
• You can read the history of any piece of work weeks later

Next

How It Is All Auditable.