The Future Is Domain-Specific Agents: Composition Over Inheritance

Here is the short version, so you can decide if the rest is worth your time. The dominant way teams build custom agents today is to take one big general-purpose agent and keep bolting tools, MCP servers, and skills onto it until it can theoretically do anything. That approach is inheritance, and like deep inheritance in code, it eventually collapses under its own weight. The alternative is composition: dozens of small, isolated, domain-specific agents that each know one thing well and talk to a coordinator in plain English. It is more efficient, cheaper, and far more secure.

This is the argument Justin Schroeder lays out in his talk on the future of agents. Schroeder is the creator of open-source projects like ArrowJS and Dmux, and he now works at a stealth company called Standard Agents that has been building a domain-specific agent ecosystem, so this is coming from someone with hands on the actual machinery. He opens with a comparison to the Industrial Revolution and a definition worth pinning down first, because most confusion about agents starts with a fuzzy definition.

What is an agent, actually?

Schroeder's definition is the cleanest I have heard: an agent is deterministic software that harnesses the non-deterministic results produced by models in pursuit of some objective. That is the whole thing. The model is the unpredictable part. It might say the right thing, it might hallucinate, it might phrase the same answer three different ways. The agent is the predictable scaffolding around it: the code that decides what to feed the model, what tools it can reach, how to validate what comes back, and what to do next. (He notes the agent-versus-harness distinction is pedantic, so treat the two as the same thing here.)

Hold onto that framing, because it explains why the industry keeps tripping over the same problem. When people try to make one agent do everything, they are asking the deterministic wrapper to babysit a non-deterministic core across a huge, sprawling surface area. The wrapper gets thinner and the core gets asked to do more. That is the wrong direction. And if the era really is an Industrial Revolution for intelligence, the agent is the machine that harnesses it, which means the design of that machine matters enormously.

Why is building custom agents so painful right now?

Almost everyone is trying to build custom agents. Not just Fortune 500 companies, but the real estate agency down the street and the independent insurance broker. The reason is always the same: integration. Businesses want their private data, their CRM, their inbox, their Figma files, their database, properly wired into AI, because they believe that leverage translates into real gains. Building a custom agent is the obvious first path they find.

The trouble is that robust agents are genuinely hard. You have to babysit the agentic loop, handle provider abstractions, add durable execution so a fault can resume, and layer in validations and stop conditions. Most homegrown agents work as a demo and not much more. IT departments end up pulling their hair out, because there is no defined, agreed-upon way to build one yet. Schroeder names four walls teams hit, and three of them should sound familiar.

Three of those four are the exact words we use for good software architecture. That is not a coincidence. The agent problem is a software design problem wearing an AI costume, and the same principles that keep large systems sane apply here too.

Inheritance: how MCP and skills got us here

After the custom-agent dream sours, teams retreat to a safer-sounding plan: forget building agents, just use the Model Context Protocol to shove our data into a big pre-existing agent like Claude or ChatGPT. And MCP does work. But look closely at what it actually delivers. Across the capabilities MCP clients could support, only one column is filled in all the way down: tools. MCP has become, in practice, a de facto tool-distribution mechanism. It is good at getting your tools into someone else's agent, and it has not yet proven great at much else.

And tools alone are not enough. As Schroeder puts it, we did not land a man on the moon by handing one guy a giant pile of tools. So teams reach for skills next. A skill is fundamentally a markdown file that acts as documentation, and skills are genuinely useful, but there is published research showing that once you install very many of them, the agent gets substantially worse. Documentation helps the astronaut; it is not the thing that flies the rocket.

Stack it all up and you get the real agent runtime: a model at the base, then a system prompt, then tools, then skills, then MCP, then the full message history on top. Look at that stack and notice that almost all of it is context. Every skill, every tool description, every MCP server lands in the same finite context window the one big agent drags through every single call.

Schroeder's word for this pattern is inheritance, and the analogy is precise. In object-oriented code, inheritance means an object absorbs more and more attributes so it can do things it previously could not. That is exactly what adding skills and MCP servers to an agent does. And inheritance genuinely works, which is why these setups exist. But there is an old saying, as old as time: composition over inheritance. Five skills is fine. A hundred is worse. A thousand hits hard diminishing returns, and everyone understands that implicitly.

Every tool you add to a single agent inflates its context window and buys you diminishing returns. The bigger the agent gets, the worse each new capability performs.

The failure mode is concrete. A model has a finite attention budget. Cram fifty tools and their instructions into one context and the model spends more of that budget just figuring out which tool it needs and how not to misuse the other forty-nine. Accuracy drops, token cost climbs, and every request pays the full tax of the entire toolset even when it needed one tool. This is the same lesson behind context engineering: context is a scarce resource, and filling it indiscriminately is how you make an agent dumber.

Composition: tiny agents that talk in plain English

The alternative is the oldest good idea in software design. Instead of one agent that inherits every capability, you build many small agents that each own one domain, and you compose them. Take Figma. Rather than adding Figma tools to your main agent, you build a tiny Figma agent whose entire system prompt is written to be a Figma expert. It knows the API, the right places to click, the actions to take, and it carries only the precise tools it needs for that and nothing more, plus a small message history about the Figma work at hand.

Crucially, each of these is a full agent, not just a little server with tools bolted on. It has its own system prompt, its own tools, its own message history, its own agentic loop. Above them sits a coordinator, and here is the part that makes it click: the sub-agents communicate with the coordinator the way humans do, in plain English. The coordinator thinks “I should check my mail for anything about a trip,” asks the Gmail agent, gets back “there is a trip to Los Angeles this weekend,” and then hands that to the travel agent to make bookings. The messy domain complexity stays sealed inside each small agent. The coordinator stays thin.

This is, almost literally, how we got to the moon: teams of experts, each brilliant at one thing, coordinating in English. The flight controller at his console had one brain (the model), the specific tools on his dashboard (not every tool, just his), and his mouth to communicate (the messages). It is a form of biomimicry for the agentic world, and it maps cleanly onto treating agents like microservices: small, single-responsibility units with clean interfaces, composed into a larger system rather than fused into a monolith.

The numbers: why composition is dramatically cheaper

The efficiency case is where this stops being a design-taste argument and becomes a budget argument. Standard Agents reports regularly seeing over 80% token efficiency for a given task, and it follows directly from the architecture. When the coordinator asks the Gmail agent to “get that last email from Debbie,” the totality of that agent's context is its system message, its tools, and that one request. It performs a targeted, specialized thing without dragging the entire surrounding conversation along.

There is a second multiplier stacked on top. Because each agent is narrow, it does not need a frontier model. Schroeder's example: DeepSeek V4 Flash versus Fable 5. On a per-task basis the small model comes out roughly 137 times cheaper. The catch he is honest about: if the cheap model fails the job over and over, those savings evaporate and the experience gets miserable. Domain-specific agents fix exactly that, because the small model is not asked to do everything, only the narrow tasks picked for it, which it can execute faithfully on a minimal context. Route narrow work to small language models, and even to non-language models like diffusion image generators, and the per-task cost drops through the floor.

Why this got urgent in 2026

For years the industry assumed the cost of intelligence only ever falls. That trend reversed in 2026. Schroeder tracks token prices, and even after adjusting for the IQ you get per token, prices are up about 29% just halfway through the year. Ignore the quality adjustment and raw token prices are up roughly 76%, nearly doubling, and the year is not even over. A memory crunch and other supply pressures are driving it.

Rising token costs do not mean you should keep paying 137 times more for something a small domain-specific agent can do just as well. It means the opposite.

There is a second forcing function: putting AI in front of actual customers. You cannot put a frontier model like Fable 5 in front of a customer unless that customer has enormous lifetime value, because the economics simply do not work. To ship customer-facing AI at scale you need high efficacy and low cost at the same time, and that is precisely the gap domain-specific agents are built to fill.

The part that matters most: security

Cost gets the headline, but the security argument is the one that should change how you build. Right now everyone is flying close to the sun, bypassing permission dialogs left and right, because a big coding agent can do anything, so we let it do everything. When you hand one giant agent access to your email, your database, your files, and your payment system all at once, you have created a single actor with unrestricted reach. If it is manipulated by a prompt injection, or simply makes a bad call, it can do damage across every system it touches.

A domain-specific agent has a capability ceiling baked into its design. The Figma agent physically cannot send email or drop a database table, because it was never given those tools. You are not trusting it to behave. You made misbehavior impossible.

This is designing the error out of existence rather than guarding against it. Each small agent gets the narrowest possible set of permissions for its one job, so the blast radius of any single agent is bounded by construction. You can still have permission dialogs, but you are opting into a far more controlled ecosystem, the kind that lets Doug in IT actually sleep. It echoes the tradeoffs in the multi-agent versus single-agent debate. And because each agent is its own small execution environment, the scaling characteristics are excellent: you can parallelize thousands of instances across regions without a giant shared footprint.

The ideal agent, dreamed all the way down

Schroeder's forward view is that this stops being a clever pattern and becomes the default. His prediction: through the end of 2026, talk of domain-specific agents and the frameworks around them accelerates rapidly, and 2027 becomes the year of multi-agent orchestration. He was validated almost immediately when Vercel shipped Eve, a framework pitched to “build a company brain, personal assistant, or domain-specific agent,” the exact term he had been pushing into the void.

The architecture he sketches goes deeper than most people picture. Start with the tool layer and break it apart. A tool can be a plain function (write a file to disk). It can be a prompt, a small sub-prompt that itself calls an LLM, so your main agent running on GLM 5.2 can fire off Nano Banana just to generate an image. Or a tool can be a whole other agent. Add hooks that mutate or inject state (the classic trick: tell the model the current time by injecting a fake message and reply into the history), plus agent rules governing turn limits and validation. Bundle all that and you have an agent, but it is still missing two primitives.

Now make the agent-as-tool recursive. A coordinator calls a Salesforce agent that knows your instance and credentials inside out. The Salesforce agent talks to a Google Workspace sub-agent to build a spreadsheet of your top salespeople, then to an asset-generation sub-agent (Nano Banana, an SVG generator, its own QA) to produce visuals. The coordinator also keeps a legal-team agent to check the work, which itself delegates to a dedicated GDPR compliance agent for European customers and an OSHA compliance agent for the rest, precisely so nobody carries 45 megabytes of GDPR context they rarely need. Agents calling agents calling agents, every one of them holding a small, minimal context window the whole way down.

Whether the calendar lands exactly on 2027 is beside the point. The structural argument holds. This is the same path software architecture already walked, from monoliths to services, pushed by the same forces: cost, blast radius, and the simple fact that no one can reason about a component that tries to do everything. If you want the fuller version of where this goes, it rhymes with compound AI systems, where agents orchestrate other agents as a matter of course.

So what should you actually do?

If you are building an agent today and the instinct is to keep adding tools until it can handle every case, treat that instinct as a warning sign. The moment you feel the context bloating and the accuracy sagging, you are watching inheritance fail in real time. The fix is not a bigger model or a longer prompt. It is to split the agent along its domains and compose the pieces back together.

The lazy, correct answer keeps winning. The best agent is not the one that can do everything. It is the smallest one that does its job, composed with a dozen others just like it.