How to use subagents in AI coding with Amp

I recently watched a presentation by Sourcegraph’s Thorsten Ball, in which he mentioned something that I’ve heard is gaining traction in recent times when it comes to AI coding: subagents. If you've been using any type of AI coding tool in the last while, you've probably run into the dreaded context window problem. You know the drill - you're deep into a chat/session, the agent reads a bunch of files, runs some bash commands that produce tons of output, and suddenly you're hitting context limits and need to move to a new chat or your context gets compacted, losing some of its viability. As Thorsten puts it in his talk: "Some tokens are more important than others, and some tokens are just garbage, and they fill up."

That's where subagents come in. They fundamentally change your relationship with the context window by giving you a "multiplication of context windows." Instead of everything ending up in your main conversation, you get fresh context windows for each task. Of course, there are pros and cons to this and some nuances that potential users of subagents should be aware of. In this post, we will cover the basics and how to use subagents in AI coding workflows.

What exactly are subagents?

A subagent is essentially a mini-Amp that the main agent can create to handle specific tasks. When Amp determines that a task would benefit from independent execution, it can spawn one or more subagents to work on different pieces simultaneously.
Here's what makes this powerful: each subagent operates with its own context window. All the back-and-forth debugging, failed attempts, and iterative improvements happen in that subagent's isolated space. Your main conversation only sees the final results, keeping things clean and focused.

The main agent can also spawn multiple subagents simultaneously, enabling true parallel development workflows that would be impossible with a single-agent approach.

The context window garbage problem

Before diving into practical applications, it's worth understanding the core problem subagents solve. Every user message you send, every assistant response, every tool call, and every tool result ends up in your context window.

This becomes problematic when agents go off track. Maybe the agent reads too many files, runs bash commands that produce a lot of output, or gets stuck in a debugging loop. Soon, you'll see "context window limit reached" or copy important parts to a new conversation.

With subagents, all those "garbage tokens" that accumulate during these processes remain in the subagent's isolated context window. Only the final, useful result gets returned to your main conversation. You can have a subagent consume 50k tokens debugging something, but your main thread only sees the clean summary.

When should you use subagents?

Subagents work best when you can break a complex task into independent pieces. They're particularly valuable for:

• Multi-file refactoring projects: When you need to apply the same changes across multiple files, each subagent can handle a subset without interfering with others.
• Unrelated bug fixes: If you have several bugs in different modules, subagents can tackle each one independently, preventing context contamination between different problem domains.
• Parallel feature development: Large features often have components that can be built simultaneously - database schemas, API endpoints, frontend components, tests, documentation.
• Token-intensive tasks: Anything that involves lots of iteration, file reading, or analysis that would otherwise consume your main context window. However, subagents do have limitations. They can't communicate with each other, and you can't guide them mid-task. Once spawned, they work independently until completion. This makes them less suitable for exploratory development, where you need ongoing input and iteration.

Beyond basic subagents: The Oracle

Amp takes the subagent concept further with something called "the oracle" (all lowercase). The Oracle uses OpenAI's GPT-5 model, providing a different context window with a different quality because a different model fills it.

While GPT-5 is slower and more expensive than Claude Sonnet 4, it excels at complex reasoning tasks. The Oracle runs in its own isolated context window, performing deep analysis without consuming your main thread's tokens. You get GPT-5's reasoning power running in a separate context window.

This creates interesting possibilities for combining different models—using Claude's speed for implementation while leveraging GPT-5's reasoning power for complex analysis, all within the same workflow but in separate context windows.

Real examples from practice

Let me walk through some actual examples that demonstrate how subagents work in practice.

Code search with the search agent

One of the most common use cases is searching through your codebase. Instead of having the main agent read through dozens of files looking for something specific, you can delegate this to a search subagent:
Where do we check the authentication headers in the server? Use the search agent.

Here, the main agent spawns a search subagent with its own context window. This subagent uses grep, searches through multiple files, reads different portions of files, and might consume 30k+ tokens doing the investigation. But when it's done, only the final answer comes back to your main conversation—maybe just a few hundred tokens explaining where the authentication logic lives.

Bulk file operations across multiple files

Another powerful pattern is distributing file operations across multiple subagents. Thorsten demonstrated this by removing comments from his blog posts:

Use five subagents to remove comments from the files in posts/

The main agent automatically counted the number of files in the posts directory, then distributed them across five subagents. Each subagent worked independently to edit files without affecting the main context window. Even though it processed 24 files, including all the reading, editing, and potential error handling that entails, it used only 9% of the main context window.

As Thorsten notes: "If you've done anything with agents, you know that they sometimes fail to edit files or they fail to run Bash commands or something, and they run into errors, and it sucks up tokens, and it's frustrating. And you can actually shove this sometimes into subagents, and the subagents will do the dirty work."

Advanced subagent patterns

Based on these core patterns, you can apply subagents to more complex scenarios:

The distributed refactoring pattern
Use subagents to refactor our API error handling. Assign different route groups to different subagents so they can work in parallel.

The research and analysis pattern
Analyze our database performance issues. Use separate subagents to check the slow query logs, analyze index usage, and review the connection pooling configuration.

The validation and testing pattern
After these changes, use subagents to: run the full test suite, check for performance regressions, and validate API documentation is current.

Best practices for subagent success

• Be specific about scope: Each subagent needs a well-defined, independent task. Vague instructions lead to poor results since you can't guide them during execution.
• Ensure true independence: If tasks require constant coordination or shared intermediate results, you're better off using the main agent.
• Plan for integration upfront: Think about how the pieces will fit together and mention any integration concerns in your initial prompt.
• Use for token-heavy work: Subagents are perfect for tasks involving lots of iteration, testing, or analysis that would otherwise consume your main context window.

When to stick with the main agent

Don't use subagents for:

• Exploratory development requiring ongoing guidance
• Simple, single-file changes that don't benefit from parallelization
• Tightly coupled changes that need constant coordination
• Tasks where you need to provide input or direction during execution

How to encourage subagent usage within Amp

Amp can decide to use subagents automatically, but you can encourage their use by:

• Explicitly mentioning "subagents" in your prompts
• Breaking complex tasks into clearly parallel components
• Using phrases like "use separate subagents to..."
• Describing work that would benefit from parallel execution

Some example prompts that work well:

Use subagents to convert these 6 JavaScript files to TypeScript, one subagent per file.

Fix these three unrelated bugs using separate subagents so the debugging sessions don't interfere with each other.

Use subagents to: set up the CI/CD pipeline, configure monitoring and alerting, and update deployment documentation.

Looking ahead: What else can we build?

The multiplication of context windows opens up fascinating possibilities. What if we could merge information from one context window into another? Can we freeze them and reuse them? Should we be able to split them and reuse only parts of them?

Maybe we could have fixed context windows that are always cached and reused across the same codebase. There's still a lot of unexplored territory here - most of it won't work, but some of it might be magical.

Making the most of parallel development

Subagents represent a fundamental shift in how we can approach complex development tasks. Instead of working through everything sequentially and managing complex context in a single thread, we can coordinate teams of specialized agents working in parallel.

The key to success is recognizing when a task can be broken down into truly independent pieces and being explicit about what you want each subagent to accomplish. When used effectively, subagents can dramatically speed up development while keeping your main conversation focused and manageable.

Start experimenting with subagents on your next multi-component feature or refactoring project. You'll quickly discover how powerful it is to have multiple specialized agents working on your behalf while you coordinate the overall strategy.