In this post, I want to review what kinds of delegation of tasks by AI agents to other AI agents exist. THis is based on my experience with building AI harnesses and observing how other people build their own harnesses.
Most basic architecture - just a loop
Simplest AI agent harnesses are built as a loop. The main AI agent receives a prompt, sends it to LLM, gets a response. If a response contains a request to call some tool, then the main AI agent calls that tool, gets a result, appends this result to the context, and sends it back to LLM. This loop continues until a LLM response does not contain any request to call a tool. Then the main AI agent returns the final result to the user.
This approach works well for simple tasks, but it has an important drawback - each request to LLM costs tokens and when context grows tool requests become too expensive. A delegation of subtasks is one of the solutions to this problem.
Why delegation is important
Delegation of tasks does a couple of practical things:
- Tokens usage can be decreased. Growing context size + increasing number of LLM rounds is a big problem for AI harnesses. Delegation allows to decrease both of them. As a result, the cost of running an AI harness can be decreased significantly.
- Subagents can execute tasks in parallel. This allows to get a result faster.
Apart of quick practical benefits, delegation of tasks is also a good design pattern. It allows to build more complex AI harnesses with multiple agents working together.
- It allows the main AI agent to focus on higher-level decision-making and strategy.
- It enables specialized agents to handle specific tasks more efficiently and effectively.
- Tools access can be provided only to specialized agents, which allows to decrease number of tools available to the main AI agent, decrease context size and a chance of mistakes of tools selection.
Kinds of subagents
There are several kinds of subagents depending on their integration with the main AI agent. I would split all this in two groups:
- subagents are running as part of same harness as the main AI agent. I call them "internal subagents".
- external subagents running outside of the main AI harness and are called over some protocol - "external subagents".
At this point i have to say i am not sure about terminology. Do we have to say "subagent" or just "agent"? If it is "agent" then how to different it from the main AI agent? I will use "subagent" for now, but it is not final decision.
Internal agents
Anybody who uses modern AI harness for coding like Copilot, Codex, or Claude Code can see this kind of agents all the time. UI usually shows it as a subtask started and the chat waits for a response to continue.
There are two types of internal subagents:
-
- Defined specialised agents. Often defined as some markdown file like "AGENT.md" and describes instructions how to execute a task on call. Some AI harness allow to assign list of tools, tools servers, a model and some other settings. When this agent is called it is executed in same physical environment as the main AI agent but with custom instructions, tools access etc.
-
- Dynamic agents. Some AI harnesses allow to create a subagent on the fly. This kind of agents usually has all the same capabilities as the main AI agent, but receives a prompt and processes it without all the prior context, all it knows is inside a prompt. Usual reason to run this kind od agent is when multiple tools calls are expected but context size is too big for multiple repeat calls to LLM then better to gather isolated pack of context and do all that calls in separated environment.
Interesting, when most people say something like "I created agents doing this and that" they usually mean internal defined subagents. They create multiple md files inside their projects in a format supported by their primary harness and this is called "the team of agents"
External agents
External agents are not so popular, but they are very useful. I am not sure if we can separate types of external agents, but i would say there are two main types:
-
- Agents living on same machine and called as CLI
-
- Agents living on remote machine and called over network with some protocol
Simple example of external agent is when your openclaw calls the claude code to do some coding task. Both are on the same machine, Openclaw is the main agent and Claude Code is the external subagent. In my personal experience i have some skills in my VSCode github copilot env where i ask to run some tasks using CLI copilot (both are copilot but technically they are different apps). Also i had a set when vscode github copilot was calling claude as CLI to do some work.
Most of AI coding assistant harnesses have a single prompt mode, like
copilot -p "Please create a new file with the following content: 'Hello, World!' and save it as hello.txt in the current directory."
It is easy to use them for delegating from other AI harnesses.
More complex setup is when your main AI agent is on one machine and the subagent is on another machine. Even somewhere in the clouds, you only have network access to it. For this kind of delegation I do not see a widely accepted approach.
Simplest way to connect this kind of subagent is to use MCP layer for transport. The reason is simple, most of AI harness support MCP. An agent is presented in the main agent as a tool and can be called over MCP.
I have described this approach recently in my blog Communicating AI Agents. It is based on the idea that your main AI agent can delegate tasks to another AI agent which lives on the machine where the knowledge base is stored. This subagent can read and write files in the knowledge base and return results back to the main AI agent.
Alternative way could a just a common REST API. Details can be presented to the main agent as a skill or instructions with details on how to call that API. In general, implementation is the same, just common http istead of MCP protocol.
Main agent executes a request to some server - That server is just minimal wrapper which reads a prompt and executes a CLI with that prompt, waits for a response and returns a result.
This way of delegating is supported well in DMJBot. This AI harness supports "MCP interfaces", one of interfaces is the "agent" which means a MCP server must implement two tools: run_agent and task_cancel. Any CLI tool (including any agentic tool) anywhere can be wrapped in this way and presented to the main harness as a subagent.
Conclusion
Task Delegation in AI Harnesses
One of the most important architectural patterns in AI harnesses is task delegation—allowing one AI agent to hand off part of its work to another agent.
In this post, I'll look at the different delegation patterns I've encountered while building AI harnesses and observing how other developers design theirs. There is still no universally accepted terminology in this area, so I'll use the terms that make the most sense to me.
The simplest architecture: a single execution loop
The simplest AI harness consists of a single loop.
- The main agent receives a user prompt.
- It sends the prompt to the LLM.
- If the model requests a tool, the harness executes it.
- The tool result is appended to the conversation.
- The updated context is sent back to the LLM.
- The process repeats until the model returns a final answer without requesting another tool.
This architecture is remarkably effective for simple tasks and is how many first-generation AI agents are implemented.
However, it has one major weakness: every interaction with the LLM becomes more expensive than the previous one.
Each tool call increases the conversation context, which means:
- more input tokens are sent with every request,
- more LLM inference rounds are required,
- latency increases,
- and overall cost grows rapidly.
For anything beyond simple workflows, this approach doesn't scale well. Task delegation is one of the best ways to solve this problem.
Why task delegation matters
Delegation has two immediate practical benefits.
Lower token usage
The biggest operational cost of an AI harness is usually the repeated exchange of an ever-growing context with the language model.
Instead of forcing the main agent to carry every piece of information through every reasoning step, a delegated agent can receive only the context it actually needs. The subagent performs its work independently and returns only the result.
This dramatically reduces both context size and the number of expensive LLM calls made by the primary agent.
Parallel execution
Independent subtasks can run simultaneously.
Instead of waiting for one investigation to finish before starting the next, several agents can work in parallel, significantly reducing overall execution time.
Delegation is also good architecture
The advantages go beyond performance.
Delegation naturally encourages modular system design.
A main agent can concentrate on planning, orchestration, and decision-making while specialized agents perform focused tasks.
This separation has several benefits:
- the main agent remains simpler;
- specialized agents can be optimized for specific jobs;
- each subagent can use different prompts, models, or tool sets;
- only the agents that actually need certain tools receive access to them.
Restricting tool access also reduces context size and decreases the likelihood that the main agent chooses the wrong tool.
Types of subagents
From my perspective, subagents fall into two broad categories:
- internal subagents, which run inside the same AI harness as the main agent;
- external subagents, which run outside the harness and communicate over some interface.
I'm not entirely convinced that subagent is the correct term. Perhaps they're simply agents. But if every component is called an agent, we still need a way to distinguish the primary orchestrator from the workers. For now, I'll continue using subagent.
Internal subagents
Anyone who has used modern AI coding assistants such as Copilot, Claude Code, or Codex has probably encountered internal subagents.
Typically, the interface displays something like "Running subtask..." while another agent works in the background before returning control to the main conversation.
I see two common varieties.
1. Predefined specialized agents
These agents are explicitly configured ahead of time.
Many AI harnesses define them using configuration files such as AGENT.md or similar formats. Besides instructions, they may specify:
- available tools,
- MCP servers,
- preferred models,
- execution limits,
- and other configuration.
Although these agents run in the same process or environment as the main agent, they operate with their own instructions and capabilities.
When people say they have built "a team of AI agents," this is often what they mean: a collection of predefined specialist agents inside a single harness.
2. Dynamic agents
Some harnesses can create agents on demand.
Instead of selecting a predefined configuration, the harness simply spawns a fresh agent with a carefully prepared prompt.
The key advantage is isolation.
The dynamic agent starts without the accumulated conversation history. It receives only the information required for its task.
This is especially useful when a subtask requires many reasoning steps or multiple tool calls. Rather than polluting the main conversation with intermediate work, the dynamic agent performs the entire operation independently and returns only its final output.
External subagents
External agents execute outside the main harness.
I would divide them into two common patterns:
- agents running locally and invoked via the command line;
- agents running remotely and accessed over the network.
Local CLI agents
A simple example is using OpenClaw to invoke Claude Code for a coding task.
OpenClaw acts as the orchestrator while Claude Code becomes the delegated worker.
I've used similar setups myself. For example, I have Copilot Skills in VS Code that invoke the Copilot CLI for particular tasks. I've also experimented with GitHub Copilot delegating work to Claude Code through its command-line interface.
Most coding assistants already support single-prompt execution, for example:
copilot -p "Create a file named hello.txt containing 'Hello, World!'."
Because of this interface, integrating them into another AI harness is surprisingly straightforward.
Remote agents
The more interesting case is when the delegated agent runs on another machine.
Perhaps it's on a dedicated server, inside a company network, or in the cloud. The orchestrating agent communicates with it only through the network.
Unlike local delegation, there doesn't yet seem to be a widely accepted architecture for this.
One practical approach is to expose the remote agent through an MCP server.
The reason is simple: many modern AI harnesses already support MCP. The remote agent appears as just another tool, allowing the main agent to delegate work without knowing how that agent is actually implemented.
I recently described this pattern in my post Communicating AI Agents. There, the delegated agent runs next to a knowledge base. Because it has local access to the files, it can efficiently read, modify, and organize information before returning only the final result to the orchestrator.
Another perfectly valid approach is a conventional REST API.
The implementation is often almost identical. Instead of exposing an MCP tool, the server exposes an HTTP endpoint. The request contains a prompt, the server launches a local CLI agent, waits for completion, and returns the response.
Conceptually, the architecture is the same. The only real difference is the transport protocol.
This style of delegation is built directly into AI harness tool DMJBot (which is a personal AI assistant harness).
DMJBot supports MCP interfaces, one of which is the agent interface. An MCP server implementing this interface exposes two tools: run_agent and task_cancel
This makes it possible to wrap virtually any command-line AI tool—even one running on another machine—and present it to the main harness as a delegated agent.
The orchestrator doesn't need to know whether it's talking to Claude Code, GitHub Copilot, another DMJBot instance, or some entirely different AI system.
As long as the interface is implemented, they're all just subagents.
Conclusion
As AI harnesses become more sophisticated, a single monolithic agent becomes increasingly difficult to scale.
Task delegation addresses several problems at once. It reduces token usage, enables parallel execution, limits unnecessary context growth, isolates specialized work, and encourages modular system design.
I suspect that future AI harnesses will rely less on one all-knowing agent and more on networks of specialized agents collaborating with each other. The remaining challenge isn't whether delegation is useful—it's establishing common protocols and conventions that allow these agents to work together regardless of who built them.
