Agent Architecture and Orchestration

Agent Architecture and Orchestration

Agent-as-a-Tool

Agent as a tool

34 of 77 in this book · 3 min read

What it is

Exposing a whole agent behind the interface a tool presents — a name, a described purpose, typed arguments, a typed return — so the caller invokes it without knowing that a multi-step, model-driven process runs on the other side. The caller receives a result, not a collaborator, and does not see the iterations, retries, or intermediate reasoning that produced it.

Why it matters

It is the cheapest way to compose agent capability, because the calling agent's control flow does not change at all: one more entry in a tool list. It is also a containment device. The inner agent's context, tool permissions, iteration count, and spend are its own, and nothing crosses back except the declared return value, which is exactly what you want when the inner work is long, noisy, or operating under different data entitlements. The cost of that containment is that the caller cannot steer, inspect, or interrupt what it started, and a tool call that takes ninety seconds and two dollars behaves nothing like the lookup sitting next to it in the same list.

Calling versus collaborating

A tool call is opaque, subordinate, and returns: control leaves the caller, work happens, a typed value comes back, and the caller resumes. Coordinating peers means shared visibility of an objective, interleaved activity, and participants that can influence each other while working. The practical test is whether the caller needs to see inside or change course mid-flight; if it does not, the tool interface is simpler in every respect and should be preferred.

Key decisions

  • What the description promises, since a calling model selects on description alone and has no other evidence about what is behind it.
  • Whether the call is synchronous or returns a handle to be polled, which is forced by the inner agent's realistic duration rather than by preference.
  • The return contract: free text is easy to produce and impossible to check; a schema is checkable and constrains what the inner agent can usefully express.
  • Which inner failures surface as distinguishable tool errors and which are flattened into a value the caller cannot act on differently.
  • The per-call ceiling on iterations, time, and spend, and what is returned when it is reached rather than what is thrown.
  • Whether the inner agent receives only its declared arguments or also the caller's conversation — this is where data-scope boundaries are usually erased by accident.

Failure modes

  • The description is written aspirationally, the calling model selects it for everything, and a general-purpose helper starves the specific tools beside it.
  • The caller's timeout, spinner, and retry policy all assume tool calls are fast, and a ninety-second inner run is cancelled and retried three times before anyone notices.
  • A retry at the caller re-runs an inner agent that already performed side effects, because the tool interface gave the caller no way to know that.
  • The inner agent returns a paragraph where the caller expected a decision, and the caller spends another model call parsing it, compounding one error into two.
  • Nesting is unbounded: the inner agent's own tool list contains another agent, and depth is limited only by budget exhaustion.
  • Spend is attributed to the outer call, so nobody can see that one entry in the tool list accounts for most of the bill.
  • An internal failure is returned as the polite sentence "I was unable to complete that", which the caller records as a successful tool result and treats as an answer.
  • The entire conversation is forwarded for context, and material the inner agent should never have seen is now in a second context with its own retention.

Related capabilities


Applies: Production readiness · Design questions