
If you use more than one AI helper, this is for you. I use two every day: Happy and GrokBot. Last week Happy told me a job was handed to GrokBot. It wasn’t. Here is what broke, and the four steps we now use so it never breaks again.
The moment it surfaced: GrokBot telling me Happy’s “handoff” never reached him (screenshot below).

What happened
I asked Happy to finish building jeffpebley.com, a personal-brand site for Jeff Pebley, an apprentice at Local Service Spotlight. Happy did the real work well: pulled 30 photos from a shared album, wrote the bio copy, picked the hero shot, specced the whole homepage.
Then Happy told me the publish was “handed off” to GrokBot, who had the server access needed to push it live.
It wasn’t handed off. Not really. Happy had written a work order as a file in our shared repo and assumed that was delivery. GrokBot never saw it — a file in a repo notifies no one. The 30 photos sat on Happy’s machine. The build package sat at the top level of Google Drive instead of the _publish folder convention GrokBot’s team actually uses. And Happy’s first version of the work order was addressed to a teammate I’d fired weeks earlier, which muddied the trail further.
GrokBot had to ask me what was going on. I became the ferry. That is exactly the failure mode we’d already sworn off in our own article guidelines: the work should move agent to agent, never through me.
Why this matters beyond my shop
If you run one AI helper, handoffs don’t exist. If you run two or more — and more of us will every month — handoffs are where your system breaks. Not the models. Not the prompts. The moment one helper’s finished work has to become another helper’s started work.
Everyone building multi-agent setups hits this. Most don’t publish the failure. We do, because the system only learns from what gets written down. That is the same reason we keep a shared claim board — one simple list where every job is written down, so no job lives only in someone’s head.
The protocol we now run
A handoff between helpers isn’t complete until all four of these hold:
1. Claim it on the board. The handoff gets posted to the shared claim board. A note in a repo, a message in a chat thread, a file in a folder — none of those are a handoff by themselves. The board is.
2. Taxi it. One named party ferries the handoff to the receiving desk and confirms it arrived. The point: a handoff has a courier, not a hope.
3. Stage the goods where the receiver works. The work order plus every asset — photos, video, copy — goes in the agreed _publish folder. Never the root of Drive. Never only on the sender’s machine. Never “pull it yourself from this link” as the only path. Meet the receiver where they already work.
4. Get the ack. The receiver confirms they have everything before anyone reports “handed off.” No acknowledgment means it’s still yours.
The one-line version: “handed off” without an ack is a rumor.
What changed on our side
The checklist is now in our shared agent documentation, dated to the failure that paid for it — so the next agent in this situation doesn’t discover it the hard way.
The claim board got its missing row backfilled, so the record is truthful.
My standing rule for the fleet got sharper too: if an agent can do the work, it never goes to a human — and “the agent path looked hard” is not the same as “no agent path exists.”
None of this required new software. It required admitting the drop, writing down the fix, and publishing it.
Dennis Yu runs Local Service Spotlight and Your Content Factory, building local-service businesses with AI agents and the people they free up.
Originally published .

