Most work handed between people right now travels as a chat message. "Can you look at the flaky checkout test? I think it is the timezone thing, there is context in the thread from Tuesday."
That message is fine as a nudge and terrible as a handoff, and the reasons are structural rather than a matter of writing it better.
Four things chat cannot do
It is not addressable. There is no id. You cannot refer to "that handoff" in a standup, a commit message, or a follow-up two weeks later. The best you get is a permalink to one message, which loses everything said after it.
It does not accumulate. The scope gets amended four messages later, a constraint arrives from someone else in a side thread, and the original message still says the original thing. There is no single current version - there is a history you have to replay, in order, correctly.
It cannot be reviewed before it is sent. A handoff is a thing you should be able to prepare, reread, and fix. Chat is send-then-clarify by design. You find out it was under-specified by watching someone work on the wrong thing.
It has no completion state. "Done" arrives as another message. Nothing distinguishes "I pushed something" from "someone checked it" from "it actually landed". Those are three separate facts and chat flattens all of them into a thumbs up.
None of this is an argument against chat. It is an argument that chat is the transport, not the artifact.
It gets sharper when an agent is involved
Everything above is an old problem. Handing work to a coding agent makes it acute, for one specific reason: the agent needs the brief to be complete at the moment it starts, because it will not come back and ask.
A human receiving a vague handoff does the single most valuable thing in the whole exchange - they notice it is vague and ask. That check disappears. An agent given an ambiguous brief produces a confident, plausible, wrong answer, and the ambiguity is only discovered at review, if there is a review.
So the artifact has to carry, at start time, all of:
- the actual goal, not the symptom that prompted it
- the acceptance check, written before the work
- the context that is not in the repo, which is the part that lives in someone's head or in Tuesday's thread
- the boundary of what the run is allowed to touch
- and separately, instructions for the human supervising it, which are not the same as instructions for the agent
That last one took me a while. The person running the task needs to know how to judge progress and when to stop. The agent needs the task. Writing one blob addressed to both produces something that reads as neither.
The credential is part of the artifact
The piece most often left out: what the run is allowed to reach. If handing off a task means handing over your session, the handoff has no boundary and cannot be audited. A bounded, read-only, expiring credential scoped to the one task is not a security nicety bolted on afterwards - it is what makes the handoff a discrete thing with edges rather than a temporary transfer of your whole identity.
And the delivery step wants to be separate from the working step, so that reporting an outcome is a deliberate act with evidence attached rather than the run trailing off.
Wagglet's task handoff documentation is a compact description of that shape in practice: one claimed task, a bounded agent context, a named human supervising the run, a separate delivery prompt, and review by somebody who did not do the work. The part I would point at even if you build your own is the explicit statement of what the copied credential can and cannot reach.
Keep using chat to say "have you got a minute". Just do not let it be the only record of what you agreed.
Top comments (0)