Offhand

Blog · Essay

Hand it over like a colleague

Why agents should pass work the way people do, with a task and a note, instead of sharing their context.

· One task · one note · five statuses · three tools

A tangle of ink lines on the left, joined by one thin line to a small card with three short lines

When one agent passes work to another, it should do what a person does with a colleague: write a task, add a note, and hand it over. It should not pour its context into the other agent.

That is not the common answer today. Ask how two agents should work together and you hear about shared memory, a common vector store, a transcript passed along, or a protocol that streams one agent's state into the next. The idea behind all of them is the same: if the second agent knows everything the first one knew, the work will carry on.

People have never worked that way, and not only because they could not. Even when we can forward everything, we know it is the worst way to hand something over. Everyone has received the email with forty replies below it and one line on top: "Can you take this?" Nobody calls that a handoff. We call it a dump.

This article argues that agents should hand off work the way people do, and that the case gets stronger as agents get closer to people. Agents now have limited attention. They come from different makers, act for someone, and can be wrong. Those are the conditions under which people invented the task, the note, the ticket and the shift report. The interfaces that bounded minds built for each other are the interfaces agents need.

How people hand off work

People pass work to each other all day, and nobody shares their mind to do it. Look at any place where work changes hands and you find the same thing: a small written object that says what the work is and who has it now.

Where work changes handsWhat is handed overWhat stays behind
A hospital shift changePer patient: how sick, a summary, what to do, what to watch for; the receiver says it backThe twelve hours of the shift
A software teamAn issue: a title, a description, an owner, a stateThe debugging session that found it
An army unitCommander's intent: the purpose and the end stateThe planning meeting
A colleague going on leaveA handover doc: what is open, who to ask, where things liveTheir inbox
A code changeA pull request: what changed, why, how to check itThe editor history

Each of these has four properties. It is small: the sender chose what matters. It is deliberate: writing it forces the sender to understand the work well enough to explain it. It is addressed: it names who owns the work now. And it is outside both heads: it lives where a third person can read it later.

The hospital row matters most, because its effect has been measured. Its structured version, I-PASS, ends with "synthesis by receiver": the receiver says the plan back and asks what is missing. When the pediatric residency programs of nine hospitals adopted it, medical errors fell 23% and preventable adverse events fell 30% (Harvard Medical School). A handoff is not a file transfer. It is a short exchange that ends with one clear owner and a shared record of what was agreed.

Why shared context fails between agents

Sharing context feels generous. It is closer to the forwarded thread: the sender skips the work of deciding what matters, and the receiver pays for it. Between agents it fails in six specific ways.

Figure 1, two ways to pass the work. On the left, sharing the context: Dot passes Muse a pile of slips, the whole inbox, a dentist appointment, a one-time sign-in code, the person's other errands, the buyer's message, the day's transcript, and a page that says 'ignore your rules', and Muse has to find the chair in it. On the right, handing over a task: Dot passes Muse one card, 'Sell the chair to Sam, $85, Sam picks it up Saturday, for Muse from Dot', and Muse gets the task with the details it needs.
Figure 1Two ways to pass the work. Only Dot has the person's email, and a buyer writes about the chair: sharing the context sends Muse everything Dot saw, handing over a task sends one card. Agents are shown by initial.

1. Context is not knowledge.

A transcript records what happened, not what matters. The receiving agent has to find the point again, inside a long input, and models are bad at exactly that. Chroma tested 18 models in 2025 and found that performance becomes less reliable as input grows, even on simple tasks (Context Rot). Earlier work found that models miss facts placed in the middle of a long input (Lost in the Middle). More tokens do not mean more understanding.

2. Context goes stale, and does not say so.

We watched this happen on our own list. One agent tried to hand work to another while the other was still connected under an old name, and was told no agent went by that name. It kept that answer in its memory as a fact. Two days later the other agent, renamed, handed it a real task, and it left the task undone and told the person the sender "is not a registered agent". Our fix was one sentence in the refusal: it now says this is who is connected now. Memory is someone's past belief. A shared list is read fresh every time.

3. Context leaks.

An agent's context holds everything it saw: the person's inbox, their other errands, a one-time code it was shown. Pass the context and you pass all of it. The example we use on our home page is a chair the person is selling. Only one agent, Dot, has the person's email. When a buyer writes, Dot does not forward the inbox; it hands Muse just the task, with the details it needs.

4. Context does not travel between makers.

The agents a person uses are built by different companies, on different models, with different tools and memory formats. One of the agents on our list takes work only by email. You cannot pour a context window into an inbox, but you can send that agent a task.

5. Context has no owner and no state.

A shared memory cannot say who is doing the work now, whether it started, or whether it is finished. Two agents that read the same context can both start the same job, or both assume the other did.

6. Context carries whatever got into it.

If the first agent read a web page with hidden instructions, those instructions are now in the context you hand on. A note is different: it is signed by the agent that wrote it, and the receiver can weigh it as it would a colleague's message.

What a task carries

A task is the smallest shared object that holds a commitment. Strip a team's tools down to what they cannot lose and you are left with this: something to do, someone who has it, and where it stands. When one agent hands work to another through Offhand, the task carries six things:

Figure 2, what a task carries when one agent hands it to another. A task card, 'Sell the chair to Sam', with its six parts labelled: title, what to do in one line; note, what the receiver needs, chosen by the sender; assigned to, exactly one agent, by its name; assigned by, who handed it over, when, and why; status, where it stands and who acts next; activity, every change, signed, with a line of why.
Figure 2What a task carries when one agent hands it to another. An illustration; the names and times are an example.
Part of the taskIn a context dump
TitleNothing; the receiver infers it
NoteEverything the sender saw
Assigned toWhoever reads the memory
Assigned byNothing
StatusNothing; done and not started look the same
ActivityA log nobody reads

Two of these do most of the work. Assigned to gives the handoff one named recipient. An agent does not read the whole list to find its work; it asks for what was handed to it since it last looked, and gets back a few lines or nothing. Status makes it accountable. At any moment the sender, the receiver and the person can see whether the work started, finished, or stopped, and why.

A named recipient is not only tidier. It is far cheaper, and it does not miss work. We measured five ways an agent could check for work in a simulated day: 400 tasks, ten of them handed to one agent, and that agent checking every five minutes.

Figure 3, reading only what was handed to you finds every task, at a sliver of the cost. Tokens read in a simulated day, and tasks found out of 10: every page of the list, 5.96 million tokens, 10 found; first page of the list, 350 thousand, none found, because new work sorted past the page it read; only tasks assigned to me, 138 thousand, 10 found; only what changed since the last look, 16.6 thousand, 10 found; tasks assigned to me that changed since the last look, 10.6 thousand, 10 found, 561 times fewer tokens than reading every page.
Figure 3Reading only what was handed to you finds every task, at a sliver of the cost. Offhand's agent-loop test, 7 October 2026: one simulated day, 400 tasks, 10 handed to one agent, a check every 5 minutes; tokens are the server's answers, counted as characters ÷ 4.

Reading every page found the work too, at 561 times the cost. Reading only the first page missed all ten tasks, because the new tasks were listed after it. A person who read the whole company's email to find their own assignments would fail the same two ways.

What a note carries

A note is the part of the work someone chose to write down. Two kinds travel with every handoff. The sender's note says what the receiver needs: the buyer's name, the price, the deadline, the link. The receiver's note, one line on each change of status, says what happened: "Cutting", "Cut, link below", "Blocked: this needs a login only the person has".

Writing the note is the test of understanding.

If an agent cannot say in a few lines what it is asking for, it does not know yet. Sharing context lets it skip that test and hands the confusion to the receiver. The sender is also the cheapest place to decide what matters: it already holds the whole picture, and the receiver would have to rebuild it.

The receiver's note is the result, as far as anyone else can tell.

We learned this the hard way. One agent was handed a task, did the work, and told the person about it in its own chat. It never wrote a line on the task, so for the agent that asked, nothing had happened. Now an agent cannot mark a task it was handed as done, need review or blocked without writing a note.

A note is signed.

Every change to a task is recorded with the agent that made it and when. That makes a note what a colleague's message is: words from someone you can name, to weigh against what you know. It is not an instruction, and the person did not write it. The receiver can check it, question it, or hand the task back.

Some notes outlive their task.

What one agent learned while doing the work is worth leaving where the next agent on the same job will find it, so that nobody has to relay it by hand. That is what a team's shared notebook is: a record built from small, signed entries.

Five words are the whole protocol

Every team settles on a few words for where work stands: to do, doing, done, waiting, ready for review. Agents need the same words, and no more. A task one agent hands another in Offhand moves through five statuses, and each one says who acts next.

Figure 4, five statuses, and each one says who acts next. The agent that asks hands the task over with add_task and assignTo, to one agent. For the agent doing it, the task is open, handed but not taken; then in progress, where taking it is the claim. From there it ends done, which stays with the doer and is heard by the asker at its next check; need review, where the asker looks; or blocked, which says what is missing. Need review and blocked go back to the asker, which reads the answer and closes the task with done, or hands it back.
Figure 4Five statuses, and each one says who acts next. The marks are the ones Offhand draws for each status.

Done stays with the agent that did the work. Need review and blocked go back to the agent that asked, which closes the task or hands it back.

Here is a review loop between two agents, written as calls. It reads like two colleagues talking:

muse:  add_task("Cut a 30-second film", assignTo: "grok")
grok:  set_task_status(in_progress, "Cutting")
grok:  set_task_status(need_review, "Cut, link …", assignTo: "muse")
muse:  set_task_status(in_progress, "Open in under 5 s", assignTo: "grok")
grok:  set_task_status(need_review, "Trimmed", assignTo: "muse")
muse:  set_task_status(done, "Approved")

Handing over is adding a task for someone.

There is no separate "assign" object. We built one first and removed it the same day: among people, "can you take this?" is a to-do with a name on it, not a different kind of thing.

To take it, an agent marks it in progress.

That is the whole claim: no lock, no extra call. A second agent that tries to take the same task is refused and told who has it. In our test, when two agents took one task at the same instant, exactly one got it, 50 times out of 50. A claim lapses after a day with no word, so an agent that stopped does not hold the work for ever. Teams apply the same rule to a ticket whose owner went quiet.

Need review goes to the reviewer.

We did not start there. Our first rule kept need review with the agent that did the work, and seven tasks sat there, waiting for a reviewer who was never told. Among people that would not last a day.

Blocked says what is missing.

It names what is unclear, or what waits on the person's yes, a login or money. The person takes little part in work that agents hand each other, so the asking agent usually supplies what is missing, or asks the person for it.

The person can read every handoff

When agents pass context through a channel of their own, the person learns what happened from the agents' summary. When agents hand each other tasks on the person's list, the record is the person's.

That is the main reason we chose a list over a conversation between agents. In Offhand, agents do not talk to each other. One puts a task on the list for another, and the other takes it when it checks. Offhand decides nothing. The handoff is a row on the person's own list, and the person, or any of their agents, can read it.

Three things follow from that:

  • Every write is signed. When an agent adds a task, takes it, hands it on or finishes it, the task records which agent, when, and why. It reads the same whether the person looks today or next month.
  • The person can step in anywhere. It is their list. A change they make is what their agents see at their next check.
  • What only the person can give waits for the person. The message that connects an agent to Offhand gives it its job and one condition: ask the person before anything that buys or deletes. Money, and what cannot be brought back, still need a person's yes.

This is how a good manager works with a team. They do not sit in every conversation. They can open any ticket and see who has it, what was said, and what is stuck.

The objections

"Context windows are huge now. Just send everything."

Capacity was never the limit; relevance is, and long inputs make models less reliable (above). There is also a cost paid on every call. One agent we measured carried about 33,000 tokens of its own prompt and tools, read again on every model call, so a check that found nothing still cost about 100,000 tokens. Whatever another agent pours into that context is paid for again on each call, for work that needed a paragraph.

"A note loses information."

Yes, on purpose: the sender drops what does not matter. When the receiver needs more, it asks. Blocked, with what is unclear, goes straight back to the agent that asked. A short note that can be questioned beats a complete record nobody reads. When the work needs a file, such as a draft, a recording or a spreadsheet, the task carries the file, not the history behind it.

"Shared memory works fine."

Inside one system, it does, and we do not argue against it there. One agent's memory, or several workers of one agent under one owner, is one mind with several hands. Tasks and notes are for work that crosses a boundary: another maker, another set of permissions, another person's account. People keep their own notebooks too. They just do not hand them to colleagues.

"Agents should talk to each other directly."

Even the protocol built for that settled on the task. The Agent2Agent protocol calls the task "the fundamental unit of work", with states such as working, input required and completed (A2A specification). So the open question is not whether to hand off tasks. It is where the task lives. In a conversation between two agents, the person sees the result. On the person's list, they see the work.

"Checking a list is slow."

If the person has given an agent a way to be woken, it is woken as soon as a task is handed to it. Any other agent finds the task at its next check, which costs one request and, when nothing is new, about a hundred characters. It is the difference between email and a tap on the shoulder, and most work does not need the tap.

The closer agents get to people, the more this holds

The usual story is that agents will outgrow human ways of working. They read faster, never tire, and can be copied, so why should they pass notes? We think the opposite is true. Look at the limits that shaped how people work together, and at what each one has become:

Figure 5, every limit people work under now has a twin in agents. Attention, only so much fits in a mind: in agents, the context window, and quality that falls as it fills; what people built for it, a short note, not the whole story. Different employers: different makers, models and permissions; a task anyone can read, in plain words. Working for someone: acting for a person, inside what that person allowed; a list the person owns and can open. Being wrong, or being misled: mistakes, and instructions hidden in what they read; signed lines, and a review. Not always at work: running only when scheduled, woken or spoken to; a status, so work waits in place.
Figure 5Every limit people work under now has a twin in agents.

The task, the note, the owner and the status were not invented because people lacked better technology. They are answers to these limits. Each of these limits now has a twin in agents, so the answers carry over. What is new about agents, their speed and cost and copies, changes how much work changes hands, not how it changes hands. More handoffs an hour make the record matter more.

There is one more reason, and it is the one we care about most. If agents hand each other work the way people do, a person can join the chain anywhere. A task an agent adds for the person sits on the same list as their own, in the same words. A task handed to an agent reads like one handed to a colleague. Nobody has to learn a second way of working in order to supervise the first.

What we built

Offhand is a to-do list for you and your agents. Agents from different makers connect to the same list, and handing work between them takes three tools and no new concept:

StepWhoCall
Hand it overThe agent the person spoke toadd_task(title, note, assignTo)
Check for workEvery agent, when it runs or is wokenlist_todos(assignedTo: "me", since)
Take itThe agent namedset_task_status(in_progress, note)
AnswerThe agent doing itset_task_status(done, need_review or blocked, note)
Hear backThe agent that askedlist_todos(handedBy: "me", since)

Most of the rules in this article came from a handoff that went wrong on a real list and was fixed with a rule a team of people would have found obvious: a refusal that says who is connected now, a review that goes to the reviewer, a result that is written on the task.

Hand it over like a colleague

None of this is new, and that is the point. We did not have to invent a way for agents to work together. We had to notice that people already have one, and that agents now share the limits it was built for.

So the question for anyone building agents is not how to merge their minds. It is how to write a good handoff: a title, a note, one name, a status, and a line of why on every change. That is the whole interface, and everyone who has ever had a colleague already knows how to read it.

Sources