AI Agents: Tools or Sub-Agents to Avoid Complexity

Understanding the Choice Between Tools and Sub-Agents for AI Agents

In the development of artificial intelligence agents, it is crucial to determine whether a feature should be implemented as a tool or a sub-agent. This choice can significantly impact the efficiency and simplicity of the agent's architecture.

Key Points Addressed

• Definition and distinction between tools and sub-agents.
• Criteria for choosing between a tool and a sub-agent.
• Application of a simple decision-making framework to avoid over-engineering.

Introduction to the AI Agent Dilemma

When building an AI agent, a critical moment inevitably arises: how to accomplish a specific task? This could involve calling an API, querying a database, or performing a calculation. The question then becomes whether this task should be handled by a tool that the agent uses directly or by a sub-agent that processes it autonomously.

Making the wrong choice can lead to an overloaded agent, trying to manage too many tasks in a single context. Conversely, opting for a sub-agent can add coordination costs, additional calls to language models, and debugging complexity that could have been avoided with a simple function.

This article explores the concepts of tools and sub-agents, their respective places in the architecture of AI agents, and how to make the right choice every time.

Definition of Tools

A tool is a function that the agent uses to interact with external systems, allowing it to perform actions beyond its built-in knowledge. In practice, tools often take the form of functions, API calls, database queries, searches, or file operations, accessible via a defined interface.

Here’s how a typical interaction with a tool unfolds:

• The model receives a task and identifies the need for external information or action.
• It generates a structured call to the tool with the required arguments.
• The application executes the tool and returns the result.
• The result is integrated into the conversation, allowing the model to continue its reasoning and decide on the next steps.

The key distinction is that tools do not have reasoning capabilities. They execute predefined operations and return data. It is the model that manages planning, interpretation, and decision-making around these operations.

Tools are the primary means for agents to interact with the outside world. They can query a database, call an API, perform web searches, read files, carry out calculations, or trigger workflows. Since they execute code rather than using another language model, they are generally fast, deterministic, and less costly compared to creating a sub-agent.

Definition of Sub-Agents

A sub-agent is a distinct instance of a language model that receives a task, processes it independently, and returns a result to the main agent. Unlike tools, sub-agents execute their own reasoning loop, potentially in multiple steps, and can make their own tool calls.

From the perspective of the main agent, calling a sub-agent resembles calling a tool: a task is sent, and a result is obtained. However, the difference lies in the intermediate process. A sub-agent executes its own logic, and the main agent only receives a summary of the final result.

Comparison Between Tools and Sub-Agents

• Tools: They execute predefined code. Sub-agents: They execute complex reasoning.

| Aspect | Tools | Sub-Agents | |-------------------------|--------------------------------|-----------------------------------| | What executes | Your code | Another language model | | Context window | Shared with the main agent | Separate, isolated | | Reasoning | None; deterministic execution | Multi-step reasoning loop | | Error handling | Structured returns, retries | Managed internally or reported | | Cost | Execution cost only | Additional calls to models | | Latency | Low; a function call | Higher; complete inference cycle | | Visibility | Complete; result in context | Partial; summary only | | When it breaks | Schema error, API failure | Hallucination, loss of context |

The distinction in the context window is crucial. When an agent calls a tool, the result is integrated into the same context where the agent is actively reasoning. In contrast, a sub-agent starts with only the information passed by the main agent.

When to Favor a Tool

Tools are preferable when the operation is well-defined, deterministic, and does not require complex reasoning.

• External API calls: Retrieving a user record, posting on Slack, or querying a database are purely execution tasks.
• Data transformation or validation: Executing a regular expression, formatting a date, calculating a hash, or converting units.
• File operations: Opening a file, writing output, checking for file existence.
• Searches: Semantic searches, SQL queries, web searches.

The practical test: if the behavior can be written as a Python function with typed inputs and outputs, and does not require complex reasoning, it should be a tool.

When to Opt for a Sub-Agent

Sub-agents are useful when the task requires multi-step reasoning, when the intermediate work could clutter the main agent's context, or when tasks can be executed in parallel.

• Tasks with complex intermediate steps: "Analyze the competitive landscape for X" requires deciding what to search for, reading the results, synthesizing information, and producing a structured summary.
• Parallelized work: Processing k documents independently is faster with k concurrent sub-agents than sequentially.
• Sub-tasks with specific tools: A code-writing sub-agent needs specific tools, just like a research sub-agent.
• Reducing contextual noise: A sub-agent can isolate complex work and return only the final conclusion.

Decision-Making Framework for Choosing Between Tool and Sub-Agent

The decision often hinges on three essential questions:

1. Nature of the task: Is it primarily execution or reasoning?

   • Well-defined tasks with predictable inputs and outputs are suited for tools.
   • Tasks requiring exploration and analysis are better suited for sub-agents.

2. Importance of intermediate work: Is it crucial for the main agent?

   • Tool results are often small and directly usable.
   • Tasks generating a lot of intermediate work benefit from a sub-agent to isolate that work.

3. Independence of the task: Can it execute independently?

   • A tool integrates into the main agent's workflow.
   • A sub-agent is preferable for tasks that can be delegated or executed in parallel.

Avoiding Over-Engineering

A common mistake is introducing sub-agents before they are necessary. While a sub-agent can simplify an architecture, it also adds complexity. Each sub-agent introduces a new context window, an additional reasoning loop, and data transfer between components, increasing latency and costs.

In many cases, a well-designed tool is sufficient. If a task can be accomplished by a simple API call, a database query, or a search, adding a separate agent may create more overhead than value.

As a general rule, start with a single agent and a limited set of well-designed tools. Only introduce sub-agents when they solve a specific problem that tools cannot handle cleanly, such as isolating large amounts of intermediate work.