Handoff or Agent-as-Tool? The Data Assistant's Supervisor Gave Away the Conversation and Never Got It Back

An analyst asks the data assistant: "Compare churn by region for Q3, then draft two slides I can show on Monday." The supervisor agent sees a SQL question, hands the conversation to its SQL specialist, and the specialist returns a clean table. Then the analyst types "great, now the slides", and the SQL agent, which has no slide tool and no idea slides were ever part of the plan, answers with a paragraph of bullet points pasted into chat.

Nothing crashed. The supervisor simply gave the conversation away and had no way to get it back. That one choice, handoff versus agent-as-tool, is the first real decision in any multi-agent setup, and it is usually made by accident.

Two ways to bring in a specialist

Both patterns start the same way: a general agent decides a specialist should do some of the work. They differ in who holds control afterwards.

Handoff. Control transfers. The specialist becomes the active agent: it reads the conversation, replies to the user directly, and receives the user's next message. The supervisor is out of the loop until something explicitly transfers control back.

Agent-as-tool. The specialist is called like any other function. The supervisor sends it a task, the specialist runs its own loop, and returns a result. The supervisor reads that result, decides what to do next, and is the one who talks to the user.

Handoff:
  user -> supervisor -> [transfer] -> sql_agent -> user -> sql_agent -> ...

Agent-as-tool:
  user -> supervisor -> call sql_agent("churn by region, Q3") -> table
       -> supervisor -> call slide_agent(table, "two slides") -> deck
       -> supervisor -> user

On a whiteboard these look like the same arrow. In a running system the difference shows up exactly one message after the specialist finishes.

🔍 What went wrong in the churn request

Walk the handoff version step by step:

1. The supervisor reads the full request, including "then draft two slides".
2. It transfers to sql_agent. Depending on how the handoff is built, the specialist gets either the whole history or a short task note. Either way, the plan ("SQL first, slides second") lived only in the supervisor's reasoning, and that reasoning did not travel.
3. The SQL agent answers the question it was built for. From its point of view, the job is done.
4. The user's next message arrives at the SQL agent, because that is who now owns the conversation.
5. The SQL agent has no slide tool and no transfer-back tool, so it does the only thing left: it improvises.

The bug is not in either agent. It is in the shape of the system: a multi-step task was routed through a pattern that assumes the specialist owns everything that happens next.

The question that decides it

Ask one thing before wiring a specialist in:

Who should answer the user's next message?

If the honest answer is "the specialist, for a while", that is a handoff. If the answer is "the supervisor, because there is more work after this", that is agent-as-tool.

A few follow-up checks make the call easier:

• Is the specialist's output a value or a conversation? A table, a list of matching records, a summary: those are values, and a value should come back to whoever asked for it. A refund dispute, a troubleshooting session, a back-and-forth about requirements: those are conversations, and a conversation goes better with the agent that actually has the tools for it.
• Are there steps after the specialist? If yes, the supervisor needs the result in hand to continue. A handoff leaves that result stuck inside someone else's turn.
• Does the specialist need the user's exact words? Handoffs usually carry the history along. A tool call carries only what the supervisor writes in the task, which is lossy. If tone, a specific complaint, or a pasted error message matters, a handoff preserves it more faithfully.
• Do the agents need different permissions? A handoff swaps the whole tool set. That can be a feature: the billing specialist gets refund tools only while it holds the conversation, and the general agent never sees them.

✅ Quick decision table

The last row is the safe default for beginners: agent-as-tool keeps one agent responsible for the whole request, so nothing can fall between owners.

If you do hand off, build the way back

Handoffs are the right choice often enough that "never use them" is bad advice. The fix for the churn failure is to make the return trip as deliberate as the departure:

def handoff(target, task_note, remaining_plan):
    # The plan travels with the conversation, not just in the supervisor's head
    target.context.append(
        f"Your part: {task_note}\n"
        f"Still to do after you: {remaining_plan}\n"
        "When your part is done, call transfer_back with your result."
    )
    target.tools.append(transfer_back)
    return target

Two changes do most of the work:

1. Send the remaining plan, not just the task. The specialist does not need to do the slides, but it needs to know slides exist so it does not treat the user's next message as a fresh request.
2. Give every handed-off agent a transfer_back tool whose description says exactly when to use it: "Call this when your part of the request is finished or when the user asks for something outside your tools." Without that tool, a specialist that hits the edge of its abilities has no move except improvising.

⚠️ The cost each pattern quietly adds

Neither pattern is free, and the costs land in different places.

Agent-as-tool grows the supervisor's context: every specialist result flows back into it. Ten raw query results with a few hundred rows each will crowd out the original request. Have specialists return a trimmed result plus a pointer to the full data rather than the full dump.

Handoff grows the specialist's context instead: it inherits a history full of material it does not need. A SQL agent reading twenty turns of small talk before the actual question is paying for every one of those turns, and may latch onto an early, abandoned version of the question.

The takeaway

A handoff is a transfer of ownership; agent-as-tool is a request for a result. Pick by asking who should answer the next message, default to agent-as-tool whenever more work follows the specialist, and when you do hand off, send the rest of the plan along with a clear way home. The analyst asking for slides should never be the one who discovers your orchestrator has no return path.