Domain-specific agents: composition against the bloated agent | Leo Cavalcante

Kelly SikkemaTable of ContentsThere is a comfortable way to build an AI agent: take a good model, write a large system prompt, connect half a dozen tools, add a few MCP servers, drop in Markdown skills, inject conversation history, and call it a platform.<br>At first, it works.<br>It works the same way a huge base class works at first. It handles the happy path, looks impressive in the demo, and feels efficient because everything is in one place. Then the bill arrives: bloated context, open permissions, unpredictable cost, behavior that is hard to debug, and an agent that has to reread the whole world to execute a small task.<br>That is the problem domain-specific agents try to solve.<br>They start from an old software engineering idea: composition beats inheritance when the system grows. Instead of creating a universal agent that inherits tools, instructions, and responsibilities from every domain, you create smaller agents with clear boundaries and compose them through a coordinator.<br>This is not architectural aesthetics. It is a way to reduce context, cost, and error surface.<br>The bloated agent is the new God class<br>Every team building agents eventually hits the same temptation: add just one more tool.<br>Just one more Gmail integration. Just one more CRM query. Just one more skill for writing reports. Just one more MCP server. Just one more prompt rule. Just one more persistent memory. Just one more piece of history because it might be useful.<br>The agent keeps accumulating responsibility until it becomes a probabilistic God class.<br>The problem is not that those capabilities are useless. Many are necessary. The problem is that they live in the same execution space. The task &ldquo;get Maria&rsquo;s latest email&rdquo; travels alongside GitHub tools, compliance instructions, planning history, product docs, writing rules, shell commands, and whatever else has been placed in context.<br>That creates three costs.<br>The first is financial. Irrelevant tokens are still paid tokens.<br>The second is cognitive. The more the model sees, the more plausible paths it can invent.<br>The third is operational. When something goes wrong, it becomes hard to know whether the error came from the tool, the prompt, memory, model choice, history, or the interaction between all of them.<br>A skill is not an agent<br>Skills are useful. Tools are useful. MCP is useful. The mistake is thinking any of them replaces a complete operational unit.<br>A skill is usually instruction. It teaches the agent how to do something. A tool executes an operation. An MCP server distributes tools and resources. All of that still usually lands inside the same agent, with the same history, the same identity, the same budget, and the same context window.<br>A domain-specific agent is different.<br>It has its own objective, prompt, tools, permissions, limits, evals, and telemetry. It is not a documentation file inside a larger agent. It is an executor with a contract.<br>A Gmail agent should not know how to scale Kubernetes. A billing agent should not be able to edit a repository. A PR review agent should not apply customer credit. That separation feels obvious in traditional systems, but it often disappears once we put a model in the center.<br>The model should not be an excuse to throw away architecture boundaries.<br>Composition changes the reasoning unit<br>The practical difference shows up in the flow.<br>In the monolithic design, the user asks:<br>Find Maria&rsquo;s latest email and create a task in Notion.

The main agent receives the request, rereads the history, sees every available tool, decides to use Gmail, then Notion, maybe checks something else, maybe loads instructions that do not matter, and continues.<br>In the composed design, the coordinator splits the work:<br>calls an email agent with a narrow task;<br>receives a structured response;<br>calls a Notion agent with another narrow task;<br>returns the result to the user.<br>The important detail is that the email agent does not need to receive the whole world. It receives the specific request, its domain prompt, and its tools. The Notion agent does the same. Context stops being a global dumping ground and becomes local input.<br>That changes the economics of the system.<br>The coordinator can keep using a stronger model to interpret intent, split work, and decide when to stop. Domain agents can use smaller models, smaller prompts, and narrower tools. In many cases, they do not need to be brilliant. They need to be consistent inside a well-designed task.<br>This is the part many agent discussions miss: not all intelligence needs to live in the same place.<br>Token savings are a consequence, not the goal<br>Justin Schroeder from StandardAgents argues that domain-specific agents can bring large token-efficiency gains because each agent works with a much smaller context. The idea is intuitive: if a task only needs Gmail, it does not make sense to pay for the model to process GitHub, Sheets, Slack, shell,...