Your AI agent is drowning in its own context. Give it a team.

You ask an agent to research three options and recommend one.

It gathers facts. Compares notes. Second-guesses itself. All of that lands in its context window.

Then it has to write the answer, with its attention split across everything it tried along the way.

The agent isn't too dumb. It's too cluttered.

If you've built anything agentic, you've hit this ceiling. Here's how subagents fix it, and how we run them in ByteChef, an open-source workflow automation and AI agent platform built on Java and Spring.

Two problems, one fix

The Spring AI team names both problems in their subagent post:

• Context pollution. Intermediate steps cloud the main agent's reasoning.
• The generalist bottleneck. One prompt tries to be good at every kind of work.

The fix is delegation. The main agent becomes an orchestrator. It hands focused jobs to subagents and keeps only what they report back.

Each subagent works in its own context, with its own instructions, model and tools. Its mess stays with it.

The example: research, then write

The Research and write with subagents template has three steps, with a small team inside the agent:

1. New Chat Request: a message arrives in the workflow chat.
2. AI Agent: the orchestrator. It runs on Claude Sonnet with Chat Memory for follow-up questions. Its Tools slot holds a Task Tool, and the Task Tool holds two Subagents.
3. Reply: the answer goes back to the chat.

The orchestrator's system prompt tells it not to do the work itself:

You are an orchestrator. Do not answer research questions yourself. Delegate fact gathering to the researcher subagent, then pass its findings to the writer subagent, and return the writer's answer. 

The two subagents split the work by cost and quality:

Their system prompts are just as short:

# researcher You are a fast, precise researcher. Collect the key facts needed to answer the task. Return 5 to 10 short bullets with no introduction and no conclusion. If you are unsure of a fact, say so. # writer You turn research findings into a clear answer for Java developers. Short sentences, concrete, no marketing language. End with a one-line recommendation. 

Research is many small, factual steps, so it runs on a fast, cheap model. The answer is what the user reads, so it gets the stronger one. The orchestrator only coordinates.

How delegation works

The Task tool comes from the spring-ai-agent-utils library, which ByteChef ships. When a message arrives:

1. The orchestrator sees a catalog. The model gets a tool called Task. Its description lists every subagent by name and description. That's all the orchestrator knows about them, so the description decides who gets which job.
2. It delegates. The orchestrator calls Task with a subagent name and a prompt it writes for that job, for example "Compare Java 21 and Java 25 for a Spring Boot service".
3. The subagent works alone. ByteChef builds a fresh chat client with the subagent's own model and tools. Its instructions become the system prompt, and the orchestrator's prompt becomes the user message. It doesn't see the chat history or the orchestrator's other work.
4. Only the result comes back. The subagent's final text is the tool result. Whatever it did along the way stays in its own context.

In this template that means two calls:

orchestrator -> Task(researcher, research prompt) returns short bullets -> Task(writer, prompt with those bullets) returns the final answer 

The orchestrator's context holds two short tool results, not the work behind them.

Here's the first Task call from a real test run, in the AI Agent's Logs tab. The orchestrator wrote a research-only prompt, and the researcher's findings came back as the tool's output.

There's a second tool too, TaskOutput. The library lets the orchestrator start a subagent in the background and collect its result later, so independent jobs can run at the same time.

Spring AI vs. ByteChef setup

ByteChef runs Spring AI's TaskTool and TaskOutputTool, so the delegation model is the same. What changes is where you define the team:

On the canvas, you add the Task Tool to the AI Agent's Tools slot from the AI Agent Utils component, then add one Subagent per team member. Each subagent has three fields:

• Name: the identifier the orchestrator uses, such as researcher.
• Description: when to delegate to it. Write it like a job posting.
• Instructions: its system prompt.

Two rules are worth knowing:

• Models fall back, then fail. A model on the Task Tool is the default for every subagent without its own. If neither has one, the run stops with an error telling you to attach one.
• Tools don't fall back at all. A subagent can't borrow the orchestrator's tools. It gets exactly what you attach. The template's subagents have none, so they work from their model's knowledge.

Workflow or subagents?

We've built orchestrator-workers before as a workflow pattern. There you lay out each step and wire the flow yourself. The Task Tool is the in-agent version: you define the team, and the agent decides at run time who does what, and in what order.

Use a workflow when the steps are fixed. Use subagents when the agent should plan the split itself.

Try it

You need an Anthropic API key.

1. Open the template and add it to a project.
2. Add your Anthropic connection to all three models: the orchestrator's and one on each subagent.
3. Open the chat and ask something that needs research first:

Should our Spring Boot service move from Java 21 to Java 25 this year? 

The orchestrator should call researcher first and writer second. Ask a follow-up and Chat Memory keeps the conversation going, while each subagent call still starts from a clean context.

To watch the delegation, test the agent in the editor and open the tool-call cards. Each Task call shows which subagent ran, the prompt it got and what it returned.

If the orchestrator skips a subagent or calls the wrong one, its description is usually too vague.

Where to take it

• Give the researcher real sources. Attach a web search or HTTP tool to it. Only the researcher can browse, and the pages it reads never reach the orchestrator.
• Add a reviewer. A third subagent on a strong model checks the writer's answer against the research bullets and lists problems only.
• Use one default model. Put a model on the Task Tool and remove the subagents' models. Keep one on a subagent only when it needs something different.
• Mix with skills. One orchestrator can have both a Task Tool and the Skills Tool: skills for procedures, subagents for focused work in a clean context.

Wrapping up

An agent gets better by doing less itself.

Delegation isn't mainly about speed. It keeps each context clean and each prompt focused. The messy middle of every job happens somewhere else, and only the answer comes back.

Got an agent struggling with a job that's really three jobs? Import the template, ask it a question that needs research, and watch it hand the work out.

This is Part 4 of our AI Agentic Patterns series. Part 1 covered Agent Skills, Part 2 covered asking the user, and Part 3 covered todo lists. If you like where ByteChef is going, a star on GitHub helps a lot.

Originally published on the ByteChef blog.