How to Hand Off Work Between AI Agents Without Anything Running Twice
Managing AI agents in real operations includes moving a job from one agent to another. The job's contract lives in a record both agents read, the new agent proves its routines are live, and the old copies are deleted the same day.
Managing AI agents in real operations includes a moment most guides skip: the job moves from one agent to another. Here is how to hand that work over cleanly. Keep the job's contract in a record that lives outside both agents. Have the new agent recreate the routines as its own and confirm they are live. Then delete the old copies the same day, so nothing runs twice.
I did this on October 1 with the agent work behind this publication. One agent had been running seven recurring routines for the site, from twice-weekly editorial research to a weekly journey-log update. Ownership moved to a different agent that already runs my other site. Here is what that handoff needed, and why.
The job outlives the agent
The most useful rule in my records is one line: the agent running a job is an adapter plugged into the job's record. Swap the adapter and the job keeps going.
In practice, that means the job's contract lives in the operating record, which both agents read. Neither agent's memory or configuration holds it. The record says what the work is, who owns the outcome, what the work may and may not do, and which approvals exist. Any authorized agent can pick it up from there, using the same contracts and the same owner.
If the contract lives inside one agent's instructions, the handoff becomes an archaeology project. You end up reverse-engineering what the old agent was doing from its outputs. The Agent Operating Record piece covers what that record should hold.
What the handoff note covered
The outgoing agent wrote a handoff note. It had five parts, and I would keep all five:
- Where the work lives and how it ships. The repository, the host, and the fact that merging to the main branch deploys production.
- Positioning, and what must stay out. What the site is for, plus a short list of things that must never appear in public copy. Those include private repository names, commit identifiers, deploy fingerprints, parked offers, and anything fabricated.
- Every routine, with its schedule and spec. A table of all seven routines, plus a pointer to the spec they run from.
- Open decisions and gaps the owner owes. Questions only I can answer, listed as mine.
- Sources. Where the record lives, and where the local snapshots are.
The most valuable lines in it were the honest ones. The registrar and renewal date were marked "not verified by me." Analytics access was flagged as the biggest gap. The search and analytics APIs had been unreachable for weeks, so every audit since had been blind. A handoff that admits what it doesn't know saves the next agent from treating a guess as a fact.
Recreate, confirm, then delete the same day
The sequence for the routines was explicit. The new agent recreates them as its own. It tells the old agent they are live. The old agent deletes its copies that same day. It keeps none.
The order matters. If you delete first, there is a gap where nothing runs. If you never delete, both copies run. Two agents then research the same topics, draft competing notes, or both try to update the same page.
The failure on the other side is just as quiet. In September, a weekday routine in my records still named a scheduled job that had been deleted. Anyone reading the record would have looked for the work in the wrong place. The fix was to rebind the record to the runtime that actually ran it. Scheduled Agents Need Runtime Reconciliation covers that check in detail.
Carry the rules that keep routines quiet and honest
Two rules came along with every routine.
Stay silent when there is nothing worth surfacing. Each routine reports only when a candidate passes every check. Otherwise it records its evidence privately and stays quiet. Through late September, the research and drafting routines stayed silent on most runs, because nothing new cleared the bar. That silence is information. It means the checks ran.
Don't bring back what was consumed or rejected. The routines keep a list of ideas I skipped and ideas already published. They match new candidates against that list by problem, thesis, and proof, not by title. That way a skipped idea doesn't come back under a new headline. A new agent that misses this list is likely to re-propose last month's rejected work with a fresh title.
Approvals do not transfer by vibes
An approval belongs to the job's record, and it covers the scope it names. Nothing more.
For this publication, my standing preference is to merge and ship editorial work, so I review it on the live site. That preference covers editorial work only. New commercial pages, navigation changes, redirects, removing pages, and de-indexing still need my explicit OK.
For anything that goes out under my name, the rule is stricter. Nothing is sent until I sign the exact message and version. A changed recipient, subject, body, link, or attachment needs a new approval. Permission to deploy a repository approves that repository work. It approves no sends, spend, or outreach.
Write these into the record before the handoff. The new agent should inherit the boundaries along with the schedule. The Send Gate piece goes deeper on the approval point itself.
When the records disagree, name the conflict
The handoff also carried one honest conflict. One record listed a page as active. A more recent note from another agent said it was retired. The handoff did not pick a winner. It said which source looked more current and that I should confirm before anyone changed or removed the page.
That is the right move for an agent. Name the conflict, say which source looks newer, and leave the decision with the owner.
A handoff checklist
Before the old agent stops:
- The job's contract lives in a record both agents can read.
- The handoff note lists where the work lives, what must stay out, each routine and its schedule, open decisions, and sources.
- Every unverified item is marked as unverified.
- The consumed and rejected list travels with the routines.
- Approval boundaries are written in the record, with their scope.
During the switch:
- The new agent recreates each routine as its own.
- The new agent confirms each routine is live.
- The old agent deletes its copies the same day.
- The record points at where each routine actually runs now.
After the first cycle:
- Each routine ran once, and either reported something real or stayed silent with its evidence recorded.
- Nothing ran twice.
One thing to do this week
Pick one recurring job an agent runs for you. Ask whether another agent could take it over tomorrow from the record alone. If the answer depends on something only the current agent knows, write that down in the record now.
Setting up this kind of operating layer for a team is part of the AI enablement work I do through DataSaa. If that would help, email me at rick@datasaa.com.
Frequently asked questions
How do you hand off work from one AI agent to another?
Keep the job's contract in a record outside both agents: what the job is, its schedule, what it may and may not do, and what is still unverified. The new agent reads that record and recreates the routines as its own. It confirms they are live, and the old agent deletes its copies the same day so nothing runs twice.
What should an AI agent handoff document include?
Where the work lives and how it ships, what must never appear in the output, each recurring routine with its schedule and spec, the approval boundaries, the decisions the human owner still owes, items the outgoing agent could not verify, and work already consumed or rejected so it is not brought back.
Does an approval carry over when a job moves to a new agent?
Only the approval that was written into the job's record, and only for the scope it names. Permission to publish editorial work does not cover new commercial pages, outreach, or spend. A send approval covers one exact message and version; a changed recipient, subject, body, link, or attachment needs a new approval.
Why should an AI agent routine stay silent when it has nothing to report?
A routine that always reports trains the owner to stop reading. When routines only speak when something passed every check, each message carries a decision, and a quiet week means the checks ran and found nothing worth the owner's time.
What goes wrong most often in an agent handoff?
Two things. Old and new copies of a scheduled job both run, so work is duplicated or contradicts itself. Or the record still points at a job that was deleted, so it shows the work as scheduled when nothing is running.