The Agents-as-Tools Pattern

What You Will Learn

How a parent invokes a specialist through a tool interface.
What the specialist hides.
When bounded delegation is safer.

Module 12 closed by naming this pattern directly as the alternative to a handoff: bounded delegation that never gives up ownership. This module is that alternative, in full — and it comes with genuinely rich, real, comparative evidence across multiple named production systems.

The architecture

Main Agent
    │
    ├── Search Tool
    ├── Database Tool
    └── Research Agent
             ↑
         exposed like
           a tool

From the main agent’s perspective, Research Agent looks exactly like Search Tool — call it, get a result back, keep going. What’s actually happening underneath that single call is a full agent loop, entirely hidden.

The definitional distinction worth knowing

This is worth stating exactly, because it’s a genuine, meaningful line, not a stylistic choice. “MCP tools extend what an agent can do in the world, subagents extend what an agent can think — by delegating subtasks to specialized agents whose reasoning is better suited to particular problem domains.” Each subagent is a genuine, first-class agent — its own persona, its own system prompt, its own tool access — not merely a subroutine. “The orchestrator need not know the internal implementation of the subagent — only its identity and the kinds of tasks it handles well.” (SemaClaw: Harness Engineering, arXiv)

That last sentence is the whole pattern’s real value, stated precisely.

Three-way decision test

This is worth knowing exactly, because it’s more precise than a simple “agent versus handoff” choice — real production guidance names a genuine third option. “Can that work be delegated as a clearly bounded specialist task? Should the original agent remain responsible for the overall result? If the answer to these questions is yes, the agent-as-a-tool pattern is likely a good fit. If delegated operations can be captured in predefined logic, then just opt for a regular function tool.” (Towards Data Science, Using Agents as Tools)

Worth holding this precisely: the real choice isn’t binary. If the task’s logic is genuinely knowable and deterministic, a plain function tool is correct and cheaper — no agent needed at all. If it’s bounded but requires genuine reasoning, this pattern fits. If ownership itself needs to transfer entirely, that’s Module 12’s handoff instead.

Concrete scenario

It’s worth seeing this decided against a genuine example. A family has a 10-hour layover in Munich and wants to leave the airport, sightsee, and eat well without jeopardizing their connecting flight. (Towards Data Science)

Run the three-way test: is this a clearly bounded specialist task the main planning agent should stay responsible for? Genuinely yes — a “local activities” specialist can reason about transit time, opening hours, and proximity to the airport, while the main agent stays in charge of the overall itinerary and flight-timing constraint. Could this be captured in predefined logic instead? No — matching sightseeing options to a specific, variable layover window and traveler preferences genuinely requires reasoning, not a lookup table. This is the pattern’s genuine sweet spot.

Comparative source-code analysis across five named products

This is worth the deepest attention in this module, because it’s genuinely rare, rigorous evidence — real research examining the actual source code of five different production coding agents to see how each one really implements this pattern.

Codex CLI gives the LLM full control over delegation, exposed as a genuine suite of tools: spawn_agent, send_input, resume_agent, wait, and close_agent. Depth is limited by an explicit agent_max_depth setting, and collaboration tools are disabled at maximum depth specifically to prevent unbounded recursion — a direct, concrete implementation of the bounded-loop discipline this course has argued for since Module 7.

Cline offers simpler tool-based delegation through new_task and use_subagents.

Gemini CLI runs sub-agents through a LocalAgentExecutor — a genuinely separate ReAct loop with its own turn limits and deadline timer. It has a uniquely thoughtful detail worth knowing precisely: a recovery phase, giving the sub-agent one final turn to produce output when its deadline actually expires, rather than simply discarding whatever work was in progress.

Prometheus delegates implicitly through subgraph nesting rather than explicit spawning calls.

(Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures, arXiv)

A genuinely important, shared observation across these implementations: “Because delegation flows through the same event stream as all other actions, it is automatically captured in the agent’s history and subject to the same condensation and replay mechanisms.” This is worth connecting directly to Module 12’s own finding that a handoff is implemented as a genuine tool call — the same design discipline shows up again here, independently, across multiple real products.

Confirmation beyond Python

It’s worth knowing this pattern’s reach extends genuinely beyond any single language ecosystem. Spring AI, a real, current Java framework, ships a Task tool — “a portable, model-agnostic Spring AI implementation inspired by Claude Code’s subagents” — enabling specialized subagents to handle focused tasks in dedicated context windows, returning only essential results to the parent. (Spring AI Agentic Patterns, Spring.io Engineering Blog)

A separate, real framework, OpenHands’ Software Agent SDK, implements the same pattern entirely as a user-defined tool — sub-agents run as independent conversations inheriting the parent’s model configuration and workspace context, with blocking parallel execution the parent spawns and monitors until completion. (The OpenHands Software Agent SDK, arXiv)

This is worth taking as direct, current confirmation of Module 1’s pattern-versus-framework thesis one more time — the same architectural idea, implemented independently in Python coding agents, a Java framework, and an entirely separate SDK, none of them copying each other’s code, all converging on the same shape because the underlying problem is genuinely the same.

Why hiding the internal loop matters

This is worth stating precisely, not just as a convenience. “This keeps context windows focused — preventing the clutter that degrades performance.” (Spring.io)

The main agent’s context never accumulates the specialist’s intermediate search queries, false starts, or tool-call retries — it only ever sees the final, distilled result. This is directly Module 6’s token-efficiency argument from Plan-and-Execute, now applied specifically to agent-as-tool delegation: the parent’s context stays lean precisely because the specialist’s internal mess never has to leave the specialist’s own context window at all.

Theoretical nuance worth knowing

It’s worth knowing this pattern sits in an honestly contested academic space, briefly. In the formal, Wooldridge tradition of multi-agent systems theory, the load-bearing properties of a genuine multi-agent system are autonomy, local views, and decentralization. Under that strict test, “a supervisor who retains full control over specialists is only weakly multi-agent” — it uses multiple model instances, but the decision structure remains centralized.

Anthropic’s own production framing takes a looser, pragmatic line: multiple LLMs autonomously using tools in a loop, working together — which fits deployed systems better, even if it’s less strict academically. (Multi-Agent in Production in 2026, Medium)

This is worth a brief, honest mention rather than a deep detour: whether agents-as-tools “really counts” as multi-agent depends on which definition you’re using, and real production teams have largely settled on the pragmatic one, not the strict academic one.

It’s worth noting why this matters practically, not just academically: a team debating whether their architecture “counts” as genuinely multi-agent is usually asking the wrong question. The genuine engineering question this module has actually answered — is this task bounded, does the caller stay responsible, does it need real reasoning rather than fixed logic — doesn’t depend on resolving that academic label at all.

What this looks like in code

Before reading the syntax, follow the execution flow: identify the incoming state, the component making the decision, the function doing the work, and the condition that returns a result or stops the loop. The code is a small teaching model of the pattern, not hidden framework magic.

from agents import Agent, Runner

research_agent = Agent(
    name="ResearchSpecialist",
    instructions="Research a topic thoroughly and return a concise, cited summary.",
)

main_agent = Agent(
    name="MainAssistant",
    instructions="Help the user with their request, using tools as needed.",
    tools=[
        research_agent.as_tool(
            tool_name="research_topic",
            tool_description="Delegates deep research on a topic; returns a summary.",
        ),
    ],
)

Notice research_agent.as_tool(...) — the entire pattern in one line. From main_agent’s perspective, calling this is indistinguishable from calling any other tool: it takes an input, and it returns a result. Everything the research specialist actually does internally — however many searches, however many iterations — stays fully contained inside that one call.

Applying this to a concrete scenario

It’s worth running this module’s three-way test against your Multi-Agent Systems coursework’s own recurring legal-contract pipeline, since it clarifies a genuine architectural detail that pipeline’s earlier treatment left somewhat implicit.

The Planner assigning a checklist item to an Executor: is this a bounded specialist task the Planner stays responsible for? Yes. Could it be captured as predefined logic instead? No — reading an unfamiliar clause and comparing it against policy genuinely requires reasoning, not a fixed lookup.

This is precisely Agents-as-Tools, not a handoff — the Planner never actually stops owning the overall contract review, and the Executor’s own internal work (however many passes it takes to extract and compare a clause) never needs to surface in the Planner’s own context beyond the final comparison result. Framed this way, the Executor is functionally being called exactly the way research_agent.as_tool(...) is called above — a full agent loop, hidden behind what the Planner experiences as a single, bounded call.

Interview-relevant framing

Q: When would you choose agents-as-tools over a plain function tool for the same task?

Ans: When the task is genuinely bounded — the calling agent should stay responsible for the overall result — but its internal logic can’t be captured as predefined, deterministic code. If the steps really are knowable in advance, a plain function tool is cheaper and simpler; no agent overhead needed. The real production test is precise: can this work be delegated as a clearly bounded specialist task, and should the original agent remain responsible for the overall result? Both yes points to this pattern specifically.

Q: How does exposing an agent as a tool actually simplify the parent agent’s context?

Ans: The specialist’s entire internal loop — every intermediate search, every false start, every retry — stays inside the specialist’s own context window and never reaches the parent. The parent only ever sees the final, distilled result, the same way it would see the return value of any other tool call. This is directly why Spring AI’s implementation frames it as keeping context windows focused — the clutter that degrades performance simply never crosses the boundary into the coordinating agent’s context.

Q: What real differences exist across production implementations of this pattern?

Ans: Real source-code analysis across five named coding agents found genuinely different mechanisms for the same underlying idea. Codex CLI gives the LLM explicit spawn and control tools with a hard depth limit to prevent unbounded recursion. Gemini CLI runs each sub-agent as a separate ReAct loop with its own deadline timer, uniquely including a recovery phase that gives the sub-agent one final turn before a deadline cuts it off rather than discarding in-progress work outright. The pattern is consistent; the specific reliability engineering around it genuinely varies.

Common Misconception

Incorrect idea: An agent exposed as a tool behaves like a deterministic function.

Why it is incorrect: Its interface may look simple, but it can plan, call tools, consume many tokens, and return probabilistic results.

Key takeaways

Agents-as-Tools hides a specialist agent’s entire internal loop behind a simple call-and-return interface — the calling agent sees only identity and result, never implementation.
The real, precise decision test is three-way, not binary: predefined, deterministic logic warrants a plain function tool; a bounded task requiring genuine reasoning with the caller staying responsible warrants this pattern; genuine ownership transfer warrants Module 12’s handoff instead.
A real source-code comparison across five named coding agents (Codex CLI, Cline, Gemini CLI, Prometheus) found genuinely different implementation mechanisms for the same underlying pattern — including Codex CLI’s explicit recursion-depth limit and Gemini CLI’s unique deadline-recovery phase.
This pattern’s reach genuinely extends beyond Python — Spring AI (Java) and OpenHands’ SDK both implement it independently, converging on the same architecture because the underlying coordination problem is the same regardless of language.
Hiding the internal loop has a real, measurable benefit: the parent agent’s context stays lean because a specialist’s intermediate mess never has to leave the specialist’s own context window.
A genuine academic nuance exists — strict multi-agent theory (Wooldridge) would call a fully-controlled specialist “only weakly multi-agent,” while real production teams have settled on Anthropic’s looser, pragmatic definition instead.

Module 14 shifts from single-role delegation to processing genuinely large volumes of independent data at scale, drawing directly on the distributed-computing lineage this pattern’s name comes from: Map-Reduce.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026