Businesses build custom agents because they need their data and workflows integrated into AI.
2
Domain-specific agents keep their own prompts, tools, message history, and execution loops, then communicate with a coordinator through ordinary language.
3
Small, focused agents can reduce context and model costs while limiting what each agent is allowed to do.
Summary
Justin Schroeder argues that useful AI systems should be built from many focused agents rather than one general agent loaded with tools, skills, and context. He compares the current pattern to inheritance in software: it works at first, then becomes harder to manage as more capabilities are added. A domain-specific agent has a narrow purpose, its own system prompt, tools, message history, agentic loop, file system, and sandboxed code execution. A coordinator can ask these agents to handle tasks such as checking Gmail, using Salesforce, creating a spreadsheet, or reviewing GDPR requirements. Schroeder says this design can cut token use, make smaller models practical, constrain permissions, and allow parallel execution. He is direct that this ecosystem is still mostly missing from public tools. He predicts more attention to domain-specific agents during 2026 and widespread multi-agent orchestration in 2027.
Custom agents exist because companies need their own data inside AI
Schroeder says businesses are building custom agents because they want their data properly integrated into AI. A real estate agency, independent insurance brokers, and Fortune 500 companies are all pursuing their own systems, even though general AI products are already widely available. He attributes this to the expected business gains from connecting AI to company information and workflows. The first attempt is often a custom agent, but the engineering burden is large. Teams must manage the agentic loop, provider differences, durable execution, validations, stop conditions, telemetry, and observability. A demo may work, while a dependable production agent remains difficult to build and operate.
Tools and skills add context, but they do not solve the whole integration problem
Schroeder describes MCP as a useful way to distribute tools into a general-purpose agent such as Claude or ChatGPT. He says MCP has not yet shown the same value for other parts of the agent stack. Skills are markdown documentation that can explain complex tasks, but research he cites shows that using many skills can make an agent substantially worse. His stack begins with a model and system prompt, then adds tools, skills, MCP, and conversation messages. Almost all of those layers become context. The prevailing approach therefore keeps expanding either the model or the context supplied to it.
Loading one agent with capabilities is inheritance, and it eventually loses value
The common design adds more attributes to an existing agent so it can perform more tasks. Schroeder compares this to inheritance in software. It works, which explains why tools and skills are useful, but it has diminishing returns as the context grows. Five skills may work well, while 100 or 1,000 skills create a different problem. The agent has to carry more information even when the current task needs only a small part of it. Schroeder uses the phrase "composition over inheritance" to introduce a design where capabilities are separate agents instead of extra layers attached to one general agent.
A domain-specific agent owns a narrow task and communicates with a coordinator
A Figma agent would have a system prompt written specifically for Figma, the relevant API knowledge, precise tools, and a small message history. It would have nothing unrelated to that task. Gmail, travel, and Google Sheets could each be separate full agents with their own histories and agentic loops. A coordinator communicates with them in English. For example, it could ask the Gmail agent for the latest email about a trip, learn that a Los Angeles trip is coming up, and then ask the travel agent to make bookings. Schroeder compares this arrangement to Apollo 11 teams, where specialists had defined responsibilities and only the tools they needed.
Focused agents can use fewer tokens and smaller models
Schroeder says StandardAgents regularly sees over 80% token efficiency for a given task, although the tasks need to be defined more clearly in advance. A coordinator can send the Gmail agent a request such as "get that last email from Debbie." The Gmail agent then needs its system message, its tools, and that request, rather than the entire surrounding conversation. He also says the approach makes small language models practical because they only perform selected tasks in a minimal context. In his comparison, DeepSeek V4 Flash is 137 times cheaper per task than Fable 5, assuming the smaller model can complete the assigned work reliably.
Narrow capabilities make permissions easier to control
Schroeder says current coding agents can do almost anything, so users often bypass permissions to make them useful. Smaller domain-specific agents have a narrower set of explicitly approved actions. They can still use permission dialogs, but their basic capability boundary is tighter. A Gmail agent does not need the same authority as a general coding agent. Schroeder says this distinction is easier for an IT department to accept because each component has a limited role. The architecture puts less responsibility in one broadly capable agent and reduces the number of actions any single component can take.
Separate execution environments make parallel scaling simpler
Each domain-specific agent can run in its own small execution environment. Schroeder says this makes it possible to parallelize agents and place them in the cloud without requiring a giant VPC. Thousands of instances could run at the same time across different regions. He is also clear about the current limitation: these agents do not yet exist publicly in a major way. StandardAgents works with them internally, but the wider ecosystem is still developing. He predicts a rapid increase in public discussion and frameworks for domain-specific agents through the rest of 2026, followed by a year of multi-agent orchestration in 2027.
An ideal agent includes tools, hooks, rules, storage, and sandboxed code execution
Schroeder expands the design beyond a model, prompt, and tool list. Tools can be ordinary functions, smaller prompts that call another model, or complete domain-specific agents. Hooks can inject information into the message history, such as the current time, or trigger side effects. Agent rules control turn limits and validation behavior. He says every agent should also have a sandboxed file system and a sandboxed code execution location, so it can write and run files without accessing the operating system at a higher level or exfiltrating data. These agents can be recursive, with Salesforce coordinating with Google Workspace, asset generation, legal review, GDPR, and OSHA agents.
"You can end up with all kinds of highly efficient, small little agents that are all working together, but maintaining small minimal context windows all the way through."29:49
Who should watch
You are building a company-specific agent and are running into context size, reliability, observability, or deployment problems.
Your system currently gives one general agent a growing collection of tools and skills, and you want a more modular architecture.
You need customer-facing AI with tighter permissions or lower model costs than a large general-purpose agent allows.
