AI Engineer World's Fair 2026
The Future Is Domain-Specific Agents
Read the talk
The Future Is Domain-Specific Agents
Small agents with their own tools, context and execution rules offer a way to integrate business systems without making one general-purpose agent responsible for everything.
From a talk by Justin Schroeder
Before you start: Familiarity with model prompts, tool calls and conversation history will help; no particular agent framework is required.
Machines for harnessing intelligence
The Industrial Revolution turned energy into useful work through machines. What plays the equivalent role when the resource is intelligence? For Justin Schroeder, the answer is agents: software that puts model intelligence to work toward an objective. Schroeder works at Standard Agents, described in the recording as still largely in stealth, and builds projects including dmux, a multiplexer for coding agents, and ArrowJS, a UI framework he likens to React for the agentic era. His opening analogy frames AI as an accelerated industrial transition: agents become the machinery through which intelligence is used.
Recognizing an agent is easier than defining one. Developers can name examples while disagreeing about what belongs in the category. Schroeder adopts an operational definition: an agent is deterministic software that harnesses nondeterministic model results in pursuit of a desired objective. The model supplies uncertain outputs; the surrounding software organizes their use. For this discussion, agent and harness refer to that same package. The distinction matters less than the software responsible for turning model responses into useful action.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The business problem is integration
Claude, Codex, OpenClaw and Hermes may be familiar names to agent developers. Schroeder suspects an ordinary office worker would recognize far fewer—and might not describe even Claude as an agent. Yet he encounters custom-agent projects everywhere: a neighborhood real estate agency, independent insurance brokers and Fortune 500 companies. Familiarity with agent terminology is not a prerequisite for wanting one.
Why build custom software when ChatGPT and open-source models already make AI widely available? Access to intelligence does not integrate a business’s data and workflows. Businesses want AI to operate with their information, inside the processes where better decisions or faster execution would produce value. Building a custom agent is an obvious route to that integration, even when the business has little interest in becoming an agent-platform developer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A working demo leaves most of the engineering unfinished
The first difficulty is the agentic loop: orchestration must correctly carry a task through model responses, tool calls and subsequent decisions. Provider differences add another layer; Schroeder points to the Vercel AI SDK as useful help with those abstractions. Durable execution must recover after faults, while validation and stop conditions determine which actions are acceptable and when execution should end. A demo can appear successful before these requirements are handled reliably.
The remaining problems concern the agent as an operational software component:
- Construction: teams invent their own approaches. Schroeder identifies Vercel’s recently released eve as an emerging approximation to a defined way of building agents.
- Observability: diagnosing and tuning behavior requires knowing what was transmitted at every step of every turn, including when execution goes wrong.
- Portability: environment variables, system requirements and runtimes can make a successful agent work only on its creator’s machine.
- Composability: even a good university chatbot may be difficult to reuse in another application.
Together, these costs can make a team retreat from custom agents before it reaches a robust, reusable system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tools and documentation still leave one agent doing the work
A common next move is to connect company systems to an existing general-purpose agent through Model Context Protocol. Schroeder uses Zillow’s information flowing into Claude or ChatGPT as an example. Looking at the client-support matrix in the recording, he observes that tools are the only consistently supported column and characterizes MCP’s practical role as tool distribution. That is a historical observation about client support, not a restriction of the protocol: the linked July 2026 documentation also covers data and prompts.
Tools alone do not supply a division of labor. Schroeder’s moon-landing analogy makes the limitation concrete: giving one person a vast collection of tools would not create the organization needed to reach the moon. Skills add instructions, which help, but a stack of manuals does not create a team either. He describes skills primarily as Markdown documentation and invokes research suggesting that large skill collections can worsen performance, without naming a study. The useful architectural question is how much responsibility remains concentrated in the same agent after both tools and instructions have been added.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Extending one agent accumulates responsibilities
Build up the stack from the bottom. A model supplies intelligence. A system prompt establishes its role. Tools expose actions, skills provide instructions, MCP connects external capabilities, and conversation messages carry the ongoing task. Most of what sits above the model ultimately contributes information to its context. This is where much integration work happens: changing the model or changing what the model receives.
Consider a developer who installs travel integrations for business trips, Figma and Playwright for work, Gmail for email, and Google Sheets for expense reports. React fixers and linters add development guidance; Matt’s grill-me skill and a GitHub skill add more. Each extension gives the same agent another responsibility. Schroeder compares this to inheritance: take an object and keep adding properties so that it can do more things.
The approach works, but its benefits need not grow indefinitely. Schroeder moves from five skills to hypothetical libraries of 100 or 1,000 to illustrate diminishing returns, not to establish a measured limit. The enduring software-design alternative is composition: distribute responsibilities among cooperating components. Context accumulation is a useful architectural model here, but installed skills should not be equated with fully loaded documents; skill systems can load instructions on demand, and selecting the right skill is a separate challenge from fitting its contents into context.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compose complete specialists
Instead of adding Figma expertise to the primary agent, give Figma its own agent. Its system prompt establishes the Figma-specific role; its knowledge concerns Figma’s API and interactions; its tools expose precisely the actions it needs. Its short message history concerns only the Figma task. Gmail, travel and Google Sheets can receive the same treatment. Each component is a complete agent with its own loop and history, rather than merely a server exposing tools.
A coordinator communicates with these specialists in ordinary English. The travel example becomes a small sequence:
- The coordinator asks the Gmail agent whether recent email mentions a trip.
- The Gmail agent returns information about a trip to Los Angeles that weekend.
- The coordinator asks the travel agent to begin making bookings.
The coordinator carries the broader objective; the specialists perform the local work. This is a proposed workflow, with the email result and booking handoff illustrating how responsibilities could move between agents.
The Apollo 11 launch-day comparison now changes. Instead of one person with every tool and manual, there is a team of experts. Schroeder points to a controller’s brain as the model, the dashboard as a bounded toolset, and speech as the message interface. The analogy explains the organization he wants to reproduce: separate expertise connected through communication. He calls these components domain-specific agents, while explicitly declining credit for inventing either the idea or the term.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Smaller context makes model choice more flexible
Standard Agents has been building an internal ecosystem around this arrangement. Schroeder reports “over 80% token efficiency” on tasks defined more explicitly ahead of time. He does not define the baseline or token accounting, so the phrase cannot be translated into a measured 80% reduction. Portability is the complementary goal: package a working Gmail agent so that another user can reuse its capabilities instead of rebuilding them.
The mechanism is easiest to see with a narrow request: retrieve Debbie’s latest email. The Gmail specialist need not receive the coordinator’s entire conversation. It can work from its own system message, its Gmail tools and the incoming request. Irrelevant travel, design or spreadsheet history does not need to accompany that local decision. The savings come from deciding which information belongs at each level of the system.
That narrower task also changes which model may be adequate. Schroeder claims DeepSeek V4 Flash is 137 times cheaper per task than Fable 5. The comparison lacks a specified workload, retry policy, token mix and matched success rates. He immediately identifies the practical constraint: if the cheaper model repeatedly fails, it loses both its economic advantage and its usefulness.
Specialization makes it possible to select tasks a smaller model can perform faithfully with minimal context. There are therefore two distinct opportunities: send fewer irrelevant tokens and use a less expensive model where its capability is sufficient. The same division of labor extends beyond language models; image-generation and diffusion models can serve tasks suited to their outputs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bound capabilities and distribute execution
Broad coding agents invite broad permissions because they can potentially do almost anything. Schroeder contrasts the habit of bypassing permission checks with a specialist whose available actions have already been explicitly approved. Permission dialogs may still be necessary, but the agent begins with a smaller capability surface. His imaginary colleague Doug in IT is reassured by the difference: approving a bounded business operation is easier to reason about than granting a general-purpose agent unrestricted reach.
Each specialist is also a small, independent execution environment. Schroeder proposes running thousands of these instances concurrently across regions, without requiring geographic co-location or one giant VPC. This is the scaling model he expects from the architecture: local execution can be distributed while coordination happens through messages. He presents the deployment potential, rather than a measured load-test result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An emerging ecosystem under economic pressure
There is a substantial availability gap between this architecture and a public ecosystem of reusable specialists. At the time of the recording, Schroeder describes daily internal use at Standard Agents but little broad public availability. He predicts rapidly increasing discussion and framework development through the end of 2026, followed by a 2027 centered on multi-agent orchestration. Vercel’s eve is an encouraging early signal to him because its positioning includes company brains, personal assistants and domain-specific agents. These are adoption forecasts, not completed milestones.
The economic motivation is that intelligence need not become cheaper on every timescale. Schroeder reports that 2026 token costs had risen 29% after adjustment for “IQ,” which he rounds to about 30%. He suggests a memory crunch as one possible contributor while allowing that the longer-term cost of intelligence could still decline. Even under that long-term expectation, decomposing work so it can use cheaper models remains valuable—and, he acknowledges, difficult.
He also reports a 76% increase in unadjusted token costs during 2026. The recording does not identify the tracking website, index composition or meaning of the IQ adjustment, so these figures remain attributed observations rather than a reproducible price index. Their practical role in the argument is customer economics: Schroeder regards Fable as too expensive for many customer-facing applications unless customer lifetime value is unusually high. Specialization offers a route to preserving task effectiveness while reducing the cost of serving each customer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tools, hooks and rules form the agent’s machinery
The closing architecture sketch returns to the model and system prompt, then expands what counts as a tool. This is an ideal agent design, rather than a walkthrough of a released API.
| Tool type | Operation | Example |
|---|---|---|
| Function | Executes code | Write a file |
| Prompt | Injects instructions or invokes a model | Generate an image |
| Agent | Delegates to a complete agent | Call a domain specialist |
A primary agent using GLM 5.2 could invoke Nano Banana through an image-generation prompt tool. Another tool could invoke a full agent with its own loop. A uniform tool layer can therefore expose operations with very different internal complexity.
Hooks provide a place to modify state or perform side effects around execution. Schroeder’s example supplies information a model does not inherently know: the current time. A hook can inject a synthetic exchange into message history so that the model receives an explicit time value. The example answer is 6:45 PM Pacific Time. In TypeScript, the history transformation can be expressed directly:
typescript
type Message = {
role: "system" | "user" | "assistant";
content: string;
};
function injectCurrentTime(
history: readonly Message[],
currentTime: string,
): Message[] {
return [
...history,
{ role: "user", content: "What time is it?" },
{ role: "assistant", content: currentTime },
];
}
const history: Message[] = [
{ role: "system", content: "Help with the user's task." },
];
const nextHistory = injectCurrentTime(
history,
"6:45 PM Pacific Time",
);
The existing messages remain intact, and the hook appends the time exchange. In an application, the supplied value would come from the runtime’s clock. The mechanism is explicit context injection; hooks can also trigger side effects rather than adding messages.
Agent rules determine how the loop may proceed. How many steps can occur before a turn ends? Could an agent continue for 10,000 turns or steps? Must a tool call pass validation? Schroeder raises these as policy questions, not recommended settings. They belong to the particular agent alongside its tools and hooks, because different domains require different execution limits and validation behavior.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give each agent somewhere to store and run its work
The bundle still needs an agent-owned filesystem. Ask ChatGPT, Claude or Codex to make a PDF for a child’s birthday party, outside an explicitly configured project, and the resulting artifact needs somewhere to live. Schroeder uses that familiar interaction to argue that file storage is a basic agent facility, not merely an optional feature for coding workflows.
The companion primitive is sandboxed code execution. An agent should be able to write files and run them inside its own isolated environment. Schroeder’s desired safety properties are preventing exfiltration and preventing access to the surrounding operating system; those are requirements for the sandbox to enforce, not automatic consequences of calling an environment a sandbox. In the proposed design, both filesystem and execution facilities are built into every domain-specific agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let specialists compose other specialists
Once a complete agent can be exposed as a tool, delegation becomes recursive. A coordinator can call an agent that calls one or several further agents. Schroeder’s business example begins with Salesforce: a specialist holds the relevant API knowledge and credentials for the company’s instance. Asked for the year’s top salespeople, it could retrieve the information and coordinate with a Google Workspace agent to create and return a spreadsheet.
The Salesforce agent could also delegate asset creation to an agent dedicated to that work. That specialist might combine Codex image generation, Nano Banana and an SVG generator, then perform its own reflection and quality assurance. The calling agent requests an outcome without needing to carry every asset-generation technique in its own context.
The primary coordinator might then ask a legal-team agent to review the work. European-customer issues could go to a GDPR specialist; workplace-safety issues could go to a separate OSHA specialist. Schroeder’s hypothetical 45 megabytes of GDPR context makes the separation vivid: the coordinator should not need every compliance detail merely because one branch of a task requires it. The completed structure is a hierarchy of cooperating agents, each retaining a small local context while handling its part of a larger workflow.
At the recording’s close, Standard Agents is slowly opening access to a small number of users. Schroeder directs interested businesses to standardagents.ai for early-access signup and invites interested businesses to contact the company about trying domain-specific agents. The rollout invitation follows the architectural ambition: make specialized capabilities reusable as complete agents, including their execution machinery, so that larger workflows can be assembled from smaller working parts.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Development-agent multiplexer for managing coding agents and git worktrees.
Lightweight UI framework with WASM sandbox capabilities.
Vercel’s agent framework announcement explains directory-based agents, durable sessions, sandboxes, approvals and subagents.
Anthropic’s announcement of Claude Fable 5 and its capabilities and safeguards.
DeepSeek’s introduction to the V4 model family, including V4 Flash.
Further reading
Research distinguishing skill-selection failures from context overhead as skill libraries expand.
The skill package format and its progressive loading of instructions, scripts and supporting resources.
Updates since the talk
July 2026 documentation introducing MCP connections to external data, tools and workflows.
Read the complete timestamped transcript
- 0:03
Okay, so I'm gonna be talking about domain-specific agents and why I really think that they are going to play an unbelievably important role in the future of AI and in the future of how we build agents.
- 0:16
To get started real quick, my name is Justin Schroeder. Uh, you can find me on X [REDACTED:username], and, um, I work at a small company called Standard Agents, which nobody's heard of right now 'cause we're still kind of in stealth mode.
- 0:30
Um, after this talk, if you're interested, feel free to reach out to me and, uh, I can let you know a little bit more. Mostly, I'm known for doing a lot of different open source projects, uh, dmux, which is a great multiplexer for all of your coding agents, uh, ArrowJS, which is sort of like a UI framework,
- 0:48
sort of like React for, um, the agentic era. A bunch more that I won't get into, but, you know, maybe check them out if you're interested. Okay. I think we can all agree that the moment in time that we are in is very similar to the Industrial Revolution.
- 1:04
Um, in fact, it might be like an accelerated Industrial Revolution. Maybe it's a bigger deal, but it's certainly not smaller. I probably don't need to convince you of that if you're listening to one of these talks.
- 1:14
Um, but that is the moment we find us- find ourselves in. So I actually think it's helpful to go back and sort of look at what was the key catalyst of the Industrial Revolution, and ultimately, it was that we learned how to harness energy with machines.
- 1:30
We learned how to harness energy with machines. And what's interesting is that in this next era, we are essentially learning to harness intelligence with agents. And agents, I think, can be thought of a little bit like the machine of yesteryear.
- 1:46
It's the thing that is going to use the intelligence, not so much us, [chuckles]
- 1:53
but the agents. What's interesting about that is I bet if I was in an actual room with you guys and, and we all put up our hands, I bet a lot of you when I say, "What is an agent?"
- 2:04
instantly have examples that pop into mind, but also probably can't pull out a definition immediately. Some of you maybe can, um, but the reality is that we haven't even coalesced on a definition of what an agent is, even though we're well into the agentic era at this point.
- 2:23
And I think that's kind of interesting. Um, here's my definition. You can feel free to agree with it or not, but agents are deterministic software that harness the non-deterministic results produced by models in pursuit of some desired objective.
- 2:39
Now, deterministic software might make you think more like a harness, and I actually think the distinction between an agent and a harness is really pedantic, not very helpful, um, and for the most part, in most cases, you can just conflate the two.
- 2:56
A harness is an agent, and an agent is a harness, okay? And for the, for the purposes of this talk, we're gonna go ahead and just move forward with that.
- 3:03
I think you could probably make some good arguments for why one is the other and vice versa, but really not important right now.
- 3:11
Now, if you did have some examples pop to mind, they might have been like Claude or Codex, um, you know, OpenClaw, Hermes. But you know what's interesting is I bet if you went out onto, you know, the, the streets of corporate America in any city, maybe not San Francisco, but any city in America, and you asked somebody
- 3:32
just in an office building, "Could you name an agent by name?"
- 3:39
I think some people are gonna get Claude,
- 3:43
some people might get Codex, and that's about it. I don't think hardly anybody's gonna be getting OpenClaw or Hermes. Uh, and, and really even Claude, I don't know that people would even know that that's an agent.
- 3:55
These things are not well understood, and yet what's so crazy is everybody is building agents. I have a real estate agency down the street that's building agents. I know in-- like independent private insurance brokers building their own agents.
- 4:13
I know Fortune 500 companies, lots of them, building their own custom agents. Everybody is trying to build their own custom agents. And I know people don't believe me, uh, but go talk to them.
- 4:25
Just go talk to people. They are trying to build custom agents, and I can't help but wonder why. Nobody seems to be asking this question, why? There's already AI everywhere.
- 4:37
You can get on ChatGPT, all the way down to some open source model from China on some, you know, rickety website. There's everything in between, but still people wanna build custom agents.
- 4:47
And ultimately, it comes down to integration. Businesses want their data properly integrated into AI. They, they believe, and are probably right, that if they appropriately leverage AI, they're gonna have these dramatic gains in their business and so on and so forth.
- 5:04
So they need to figure out how to get integrated, and building their own custom agents is obviously a way to do that, and it's one of the first ways that they discover, um, as a mechanism for doing it.
- 5:16
The problem, though, is that agents are really hard. You have to take very, very careful care of the agentic loop and make sure that it's properly orchestrated. There are a ton of different provider abstractions you need to think about.
- 5:32
Um, fortunately, there's some good tools coming out around that, you know, like the, the Vercel AI SDK is great. Um, durable execution, you need to make sure if there's faults, we can pick back up.
- 5:43
These are relatively hard problems, um, especially if you're thinking about it at scale. And the reality is there's just tons more. There's all kinds of validations and stop conditions and so on and so forth.
- 5:54
And so what often happens is people do try to build their own custom agents, and they sort of work as a demo, but, but not much more than that.
- 6:01
Um, and really, it turns out that it's an absolute nightmare for people. Um, building robust agents is just hard. And if you go talk to anybody [chuckles] in an IT department, they are pulling their hair out because there are so many different concerns.
- 6:18
Um, there's no defined way to build an agent right now. Like, actually no defined way. The closest thing maybe is, uh, Eve that just came out from Vercel is maybe, like, the closest thing.
- 6:29
Um, but in reality, everybody's kinda coming up with their own way to do it. Um, telemetry and observability on these agents is unbelievably hard, especially at scale. Like, if you wanna know exactly what is getting transmitted on every single step of every single turn of your agent, so that way you can diagnose it and fine-tune it and
- 6:48
make sure things aren't going off the rails, that is very hard to do. Uh, agents are also not portable. So if I do get a good agent working, if I've managed to climb to the top of, you know, this mountain and I've got a good agent that's finally working well, well, it works well on my machine. [chuckles]
- 7:06
But if I try to pass that off to somebody else, there's a very high likelihood that between all of the environment variable configurations and, and system requirements and, and runtimes, there's a good chance it's not gonna run on that person's machine.
- 7:20
And they're not composable. So even if I get, you know, a really good chatbot working for my university, the chances that I'm going to then be able to reuse that for another thing is very, very low.
- 7:32
I can't just easily share that. So what often happens is after a short pursuit towards agents, people kind of back away and say, "Okay, fine. No more agents, no agents."
- 7:43
Instead, we're gonna do the MCP thing. We've heard about this, it works. And sure enough, Model Context Protocol, it does work. And really, it, it works pretty well to take, you know, your corporate information like Zillow's information and then shove that into one of these really large, uh, ex- pre-existing agents, something like Claude or ChatGPT, which I
- 8:07
would consider a large general-purpose agent. Um, and it, and it sorta works like that. Uh, and it, and it works okay. But if you take a look, this is actually from the MCP website, and if you take a look at what is supported in MCP clients around the world, you will notice that only one of these columns
- 8:26
is actually filled out all the way down. And that, of course, is tools. So MCP has become a de facto tool distribution mechanism for agents. So if I need to get my company's tools into that other agent, then MCP is a good way to do that.
- 8:48
It has not proven to be great at providing other value yet.
- 8:55
And frankly, tools are just not enough. You know, I, I, [chuckles] I like to joke that we didn't land a man on the moon by giving one guy a ton of tools. [chuckles]
- 9:05
That's not a realistic way, uh, to get a really large project done.
- 9:11
So, uh, you know, maybe MCP is not the way, but aha, we have skills. We have skills, and skills are great. Um, I, I, I actually do enjoy skills.
- 9:21
I'm sure you do too. We install them all the time for all kinds of things. And fundamentally, what a skill is, is a markdown file which basically works as documentation.
- 9:30
Now, interestingly, there's lots of research out there that shows that if you use very many of these, it actually makes your agent substantially worse. But they do work as documentation for various complex things.
- 9:44
So, you know, back to the analogy of a man getting to the moon, it's a little bit like just giving this guy, you know, a ton of documentation, and the documentation's gonna help, but it's not the fundamental problem.
- 9:56
So what's the fundamental problem? Okay. Let's build up a basic agent stack here. Let's start with a model. All agents start with a model. Big one, small one, doesn't matter.
- 10:07
They start with a model. Then you have something like a system prompt on top of that, which tells the model what its role in the grand universe is, sort of like its, its life objective.
- 10:20
Then we have tools, the things that it can actually do, the effects it can take. And then skills would be layered on top of that. And then MCP would be layered on top of that.
- 10:30
And then finally, you have all the messages from the conversation. That is roughly the stack of information that gets passed along within the runtime of an agent. And if you take a look here, almost all of it
- 10:46
is context. Basically everything. The system prompt, tools, skills, all of that is stuff that ends up in the context of the agent. And so basically, people are trying to solve the integration problem by working on the context or the model.
- 11:06
These are the two areas where we constantly see new advances. We also see, you know, new, new things come out like skills and, and MCP, um, new technologies, new protocols.
- 11:17
They are all coming out in the r- in the area of the context and the model.
- 11:25
So how does it actually work then? Well, basically, you work at a company, you occasionally need to do some business travel, so you've got a couple travel, uh, MCPs installed.
- 11:36
You've also got, you know, Figma and Playwright installed on yours, and all of these are building up in that context layer. And then you've got some, you know, Gmail MCPs to go check your mail for you and some Google Sheets to go fill out some other, uh, some other, uh, expense reports or something like that.
- 11:53
And then you've got skills. You're a developer, so you've got some React fixers and linters. This is actually, I think, like the number one or the number two most popular MCP server that's out there.
- 12:03
Um, maybe you've got, uh, Matt's, uh, Grill Me skill or, or maybe you've got the GitHub skill. And basically what you're doing is you are inflating that context layer And we have a term for this in engineering.
- 12:16
It's called inheritance. The idea of inheritance is you take an object, and then you add more attributes to it to allow that one object to have other properties, right?
- 12:29
And that's exactly what we are doing here with an agent. We're saying this agent is pretty good, but if we add all of these adesh- additional extra layers, then the agent can do stuff that it previously couldn't do before.
- 12:44
That is exactly what inheritance is. And the truth about inheritance is it works. It does work. That's why these things are out there, and they are working. But there's an old saying, "Composition over inheritance."
- 13:01
And it turns out this, this is as old as time. Eventually, inheritance starts to break down. Imagine like, you know, okay, I've got five skills on, uh, ChatGPT or on, or on Claude, excuse me, and, uh, that works pretty well.
- 13:16
Now, what if I have 100 skills? What if I have 1,000 skills? There's some point at which I get diminishing returns from adding additional context. That's, that's just obvious.
- 13:27
We all kind of understand that implicitly. So is there an alternative? Well, composition is the alternative to inheritance. It looks something like this. So like imagine we have another little agent, and again, we're trying to provide Figma as an, as a, as a thing that can be done by our primary agent.
- 13:46
Well, what we could do is have a tiny little agent where the actual system prompt of the agent is written specifically to be a Figma agent. It knows everything about Figma.
- 13:57
It knows all of its, all of its context, all of its API, all of the right places to click and the things to do and mouse movements to make and everything like that.
- 14:06
And then it has these precise tools that it needs to perform all of those actions and nothing more, just that. And then a very small message history, which just has to do with the Figma portion of this.
- 14:21
And then you can have more of these. You can still have your Gmail and your travel and your Google Sheets and all of that kind of stuff, but each of them is a separate isolated agent, a full agent, not just a little server with tools on it.
- 14:33
It's a full agent with its own message history, its own agentic loop. And then above these, you have a coordinator. And the communication mechanism for all of these small agents speaking to the larger agent above it is just English.
- 14:51
They just talk to each other the way a human does. So if the primary agent is saying, "Oh, I should, I should check my mail to see if there's anything about going on a trip," well, it knows to go ask Gmail for any new, uh, emails about a trip.
- 15:08
Those funnel their way back up, says, "Oh, yeah, actually, there's a trip coming up to Los Angeles this weekend," and then it can go to our travel agent and start to make bookings.
- 15:20
That's kind of a, a rough idea of how something like this could work.
- 15:27
And the reality is it does work, and we know it works because this is actually how we got to the moon. [chuckles] There were teams of experts, teams of experts with faces that looked like that and faces that looked like that, each of them with different skills and capabilities, and faces that looked like that.
- 15:46
This is the Apollo 11 launch day. And look right here. There's an agent. I just found an agent sitting right there. [chuckles] That brain of his is, that's his LLM.
- 15:56
And here's his tools right there on the dashboard. Those are the tools. Now, he didn't have all the tools. He just had those tools, and he was really, really, really good at them.
- 16:06
And then look at that mouth. That's the messages. Uh, we are used to this. We can understand this. It implicitly works. It's almost a form of biomimicry for the agentic world.
- 16:18
Um, it works. And I call them domain-specific agents. Um, I don't think I was the first person to utter the words domain-specific agents, certainly not the first person to have this idea, um, but that is what I wanna talk to you about, agents that are just targeted to a very specific domain.
- 16:37
And we over here at Standard Agents have been building this ecosystem for quite some time, so we've gotten to have a really good inside look at how they actually work.
- 16:47
And I'm not ready to come out here and announce a product or anything like that, um, but I can give you a little bit of a peek. First of all, they are far more token efficient, far more token efficient.
- 16:57
We regularly see over 80% token efficiency for any given task. Now, it's a little more complicated because you have to define those tasks a little bit more ahead of time.
- 17:10
But if you can have an agent portability where I can take that Gmail agent, squeeze it up, and then send it to somebody else, we can create an ecosystem where we don't have to create every one of these skills and capabilities.
- 17:23
But within that domain, you're going to get dramatic efficiency.
- 17:29
Um, and part of the reason is, if you think about the way that the context work, works, I don't need to have the entire context of the conversation when I make a choice to do something.
- 17:40
Instead, my primary coordinator level can just ask the Gmail, uh, "Hey, get that last email from Debbie," and that is the totality of the context. It literally just has the system message, its tools, and that message that came in.
- 17:55
And so it is then able to perform this very targeted, very specialized, tiny little thing without all of the surrounding context.
- 18:06
It's also far more practical with small language models.
- 18:12
If you look at the difference in two models like DeepSeek, uh, V4 Flash and, uh, Fable 5, the cost difference Is mind-boggling. It is 137 times cheaper than Fable per task.
- 18:34
137 times. Now granted, if DeepSeek V4 Flash fails over and over and over again to do the job, then not only is it gonna be, you know, not that much cheaper, it's also going to be much more annoying to use it.
- 18:51
But that's why domain-specific agents are so great, because you don't need to have the V4 Flash do everything. Instead, it only needs to do the tasks that have been specifically picked for it to do, and with a very minimal context, it can execute those very faithfully.
- 19:11
So you get these dramatic cost reductions, not only with the token efficiency, but also because you can use much smaller language models and even non-language models. You can use image generation and diffusion models.
- 19:25
You can use all kinds of other models for smaller tasks.
- 19:30
You can also enforce really strict limits on the capabilities, and I think you know what I'm talking about. I'm talking about this. Uh, we are all flying awfully close to the sun nowadays, [chuckles] where everybody's just bypassing permissions left and right.
- 19:45
And of course, you have to, because a coding agent with a big model can do anything, and so we use it to do everything.
- 19:56
In a world that would be powered by smaller domain-specific agents, those agents can't do everything. They can only do the things that are already explicitly approved for them to do.
- 20:06
It doesn't mean that you still can't have permissions and permission dialogues, but you are opting into a much more controlled ecosystem, and I promise you, when you explain that to [chuckles]
- 20:19
Doug in IT, he, it puts his heart at ease understanding the difference between those two.
- 20:26
And, uh, and fourth, they, these have excellent scaling characteristics. Because each of these agents is its own small little execution environment, you can parallelize them, you can put them on the cloud very easily without needing, like, a giant VPC up there.
- 20:40
You can run thousands of instances all at the same time, um, in, in all kinds of regions of the world. They don't actually need to be, uh, g- you know, geographically co-located or anything like that.
- 20:53
Um, so they have very, very good scaling characteristics.
- 20:57
Unfortunately, they don't exist. That's the downside. [laughs] These domain-specific agents don't really exist. Um, not in a big public way. Um, like I said, here at Standard Agents, we have them, we are working with them on a daily basis, um, but they are not out there in public very much yet.
- 21:19
However, that's changing. That is going to change very quickly. We're about halfway through 2026, and, um, and I'm here to make a public prediction that I think as we roll on from, from this point to the end of 2026, we are going to see a dramatic uptick in people talking about building, uh, domain-specific agents, frameworks around them,
- 21:43
all kinds of things are coming down the pipe. And it's not gonna be a small trickle. It's, it's going to accelerate rapidly, and this will become, a, one of the main players in the agentic ecosystem.
- 21:56
And 2027, I would say, is basically the year of multi-agent orchestration. That's another word you'll start to hear a lot, I think. So that's my big, bold public prediction.
- 22:09
I was really excited just a few days ago when, uh, Vercel released Eve. Uh, this is the first time I actually saw the term that I had been blasting out into the void [chuckles] come back and hit me in my own face.
- 22:22
Uh, the framework for building agents, build a company brain, personal assistant, or domain-specific agent. So there we go. About halfway through the year, we're gonna start picking up steam.
- 22:35
That's my prediction. And there's a number of reasons. One of them is, um, something that most people believe right now is that the cost of intelligence is going down.
- 22:45
That trend reversed in 2026, actually. Uh, we track this, um, on, on a website. Uh, tokens are not getting cheaper anymore. They are actually going up even when adjusted for IQ.
- 22:58
They're up 29% when you adjust for IQ just this year. Halfway through the year, we're already up 30%, and that can be caused by lots of different things. Of course, um, we've got this memory crunch and, and you know, probably the long-term trend over a 10-year cycle or something is that intelligence will go down.
- 23:17
But that does not mean that we need to be paying 137 times the cost for something that can be done just as effectively. The problem is it's harder to break those things apart.
- 23:29
Now, if you don't account for IQ, tokens are up 76% this year, almost 100% increase in tokens just this year. Um, and we're, we're not even halfway through it.
- 23:43
So we are really trending upwards on, on token costs. So anything we can do, especially with large businesses to bring that down, is gonna be really important. Um, the other, the other use case to really consider is putting AI in front of customers.
- 23:58
You can't put Fable in front of a customer, um, unless that customer has a massive lifetime value. It's just too expensive. So you need to find a way to create great efficacy while being efficient, and domain-specific agents are gonna be the way to do that.
- 24:16
So I'm gonna leave you here momentarily, um, but before I do, let's just dream a little bit. Let me dig in a little bit deeper to how an agent could be orchestrated and what an ideal agent would actually look like, and then I promise to leave you alone.
- 24:35
Here we go. So remember we got that model, and we got the system prompt. And then at the tool layer, let's break that apart a little bit. On one hand, we have these like functions.
- 24:44
This would be like an actual function that can get executed, like write a file to the file system. Then we have prompts. Prompts are a lot like the system prompt, but they are smaller individual prompts that can get injected and, and sub-prompts that can, you know, you can run a function that actually calls an LLM.
- 25:08
So let's say I have a main agent running, but I wanna use NanoBanana just to generate an image when I'm using GLM, you know, 5.2 as my primary. Well, you can just have a tool that's a prompt.
- 25:20
That would be really cool if you could do that. And then another type of tool could be another full-blown agent, like a complete other domain-specific agent could just be one of the tools.
- 25:34
So that's the tool layer. And then you have hooks. Uh, what are hooks? Well, in this ideal world, a hook might be something that can kind of harness or change or mutate or perform side effects.
- 25:48
So let me give you an example. LLMs have no idea what time it is at any given point in time. Turns out a really great way to tell them what time it is, is you inject an artificial message or an artificial tool call in the message history.
- 26:04
So it looks like somebody just said, "Hey, what time it is?" And the other person replied, "Oh, it's 6:45 PM Pacific Time." Pretty simple.
- 26:15
Um, you can do that with a hook, or you could fire off some side effect using a hook. So this is an important piece of an agent. And then finally, there's, there's these agent rules, and agent rules are kinda complicated.
- 26:28
It's like, how many times should one side have a turn? Like, can it go on for 10,000 turns, uh, or 10,000 steps before its turn is up? You know, there's, there's all kinds of interesting little rules.
- 26:41
You know, when it calls, uh, a tool, you know, is it required to validate the whole thing or not, you know? All kinds of, of very specific tools, uh, or, or rules that, that belong to a specific agent.
- 26:54
And altogether, if we bundled all that up, we would call that an agent. But it's kinda missing a couple things. One, every agent should really have a file system.
- 27:05
If you've ever done this with ChatGPT or Claude or Codex, if you just ask it, you know, not inside of a project or anything, like, "Hey, can you make me a PDF for my, my son's birthday party?"
- 27:20
Well, it'll do it, and it'll store it in its own little file system. So the big labs have already realized that in order to create an effective chat interface, not to mention a big agent, it needs some sort of file system.
- 27:33
So every agent should have its own little sandbox file system. And also every agent should have a sandboxed code execution location. So it can write files, it can run those files, and it can do that safely without exfiltrating anything, without interacting with an OS at a higher level.
- 27:51
That needs to be baked in as a primitive to every single domain-specific agent. Okay. So let's say that that's our ideal agent. And now let's talk about that little agent tool there.
- 28:02
What is that? Well, those can be sub-agents, recursive sub-agents even. You could have an agent that calls a sub-agent that calls sub-agents that call sub-agents. Um, and there could be one or there could be many of these at different levels.
- 28:18
So for example, you could have this coordinator agent that's at the very top, and then you could have a Salesforce agent, and that agent knows Salesforce inside and out.
- 28:27
It knows all of its APIs. It knows, has all the credentials to communicate with your Salesforce instance in all the appropriate ways. And then it needs to communicate with a Google Workspace agent, so it can do all kinds of stuff in there.
- 28:40
It can run spreadsheets. I can say, "Hey, what are all my tops, uh, my, my top salespeople this year?" And boom, it can look in Salesforce. It can coordinate with the sub-agent, create a sheet for you, send that back.
- 28:51
Perfect. But maybe then you need to generate some assets. So the Salesforce agent actually has another sub-agent that it can talk to at any time it wants, and it's amazing at generating assets.
- 29:02
Maybe that sub-agent doesn't just have like, you know, Codex image generation. Maybe it has NanoBanana, maybe it has an SVG generator, all kinds of stuff, so that way it is an amazing asset generator and performs some of its own reflection in QA.
- 29:19
And then our primary agent might need a whole legal team agent just so it can check the work that's coming out of these other ones. And maybe the legal team agent really needs a GDPR compliance agent just for those European customers.
- 29:32
You know, the main one doesn't have all, you know, we don't wanna have 45 megabytes of context just on GDPR, so we make that a separate sub-agent. [chuckles] Uh, so you know, may...
- 29:42
And then maybe the legal team also needs like an OSHA compliance agent, which is also very complicated, and so it has a separate one for that. You kinda get the idea.
- 29:51
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. That's the idea behind domain-specific agents.
- 30:08
So thank you very much. I appreciate you listening to my talk. Again, uh, Standard Agents is where we're working, standardagents.ai. You can actually sign up on there, uh, for early access.
- 30:18
Um, we are slowly starting to roll this out to a few people. Um, if your business is super ambitious and really wants to, uh, try out small domain-specific agents, then, um, you know, you can write me, [REDACTED:email_address].
- 30:31
And of course, I'd appreciate a follow. Thank you so much. Bye.