The Future Is Domain-Specific Agents - Justin Schroeder, StandardAgents

Okay, so I'm going to 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. To get started real quick, my name is Justin Schrader. You can find me on X at JPSchrader. And I work at a small company called Standard Agents, which nobody's heard of right now because we're still kind of in stealth mode after this talk. If you're interested, feel free to reach out to me and I can let you know a little bit more. Mostly, I'm known for doing a lot of different open source projects. DMUX, which is a great multiplexer for all of your coding agents. Arrow.js, which is sort of like a UI framework, sort of like React for the agentic era. A bunch more that I won't get into, but 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 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 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. 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. It's the thing that is going to use the intelligence. Not so much us, but the agents. What's interesting about that is I bet if I was in an actual room with you guys and we all put up our hands. I bet a lot of you when I say what is an agent instantly have examples that pop into mind, but also probably can't pull out a definition immediately. Some of you maybe can, 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. And I think that's kind of interesting. 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. 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. And for the most part, in most cases, you can just conflate the two. A harness is an agent and an agent is a harness, okay? And for the purposes of this talk, we're gonna go ahead and just move forward with that. I think you could probably make some good arguments for why one is the other and vice versa, but really not important right now. Now, if you did have some examples pop to mind, they might have been like Claude or Codex, you know, Open Claw, Hermes. But you know what's interesting is I bet if you went out onto, you know, the streets of corporate America in any city, maybe not San Francisco, but any city in America, and you asked somebody just in an office building, could you name an agent by name? I think some people are going to get... Claude. Some people might get Codex. And that's about it. I don't think hardly anybody's going to be getting OpenClaw or Hermes. And really, even Claude, I don't know that people would even know that that's an agent. 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 independent private insurance brokers building their own agents. 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. But go talk to them. 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. You can get on ChatGPT all the way down to some open source model from China on some rickety website. There's everything in between, but still people want to build custom agents. And ultimately it comes down to integration. Businesses want their data. properly integrated into AI. 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. 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 as a mechanism for doing it. The problem though is that agents are really hard. 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. Fortunately, there's some good tools coming out around that, you know, like the Vercel AI SDK is great. Durable execution, you need to make sure if there's faults, we can pick back up. These are relatively hard problems, 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. And so what often happens is people do try to build their own custom agents and they sort of work as a demo, but not much more than that. And really it turns out that it's an... absolute nightmare for people. Building robust agents is just hard. And if you go talk to anybody in an IT department, they are pulling their hair out because there are so many different concerns. There's no defined way to build an agent right now. Like actually no defined way. The closest thing maybe is Eve that just came out from Vercel is maybe like the closest thing. But in reality, everybody's kind of coming up with their own way to do it. Telemetry and observability on these agents is unbelievably hard, especially at scale. Like if you want to 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 make sure things aren't going off the rails, that is very hard to do. Agents are also not portable. So if I do get a good agent working, if I've managed to climb to the top of this mountain and I've got a good agent that's finally working well, well, it works well on my machine. 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 system requirements and run times, there's a good chance it's not going to run on that person's machine. And they're not composable. So even if I get 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. 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. Instead, we're going to do the MCP thing. We've heard about this. It works. And sure enough, Model context protocol, it does work. And really, it works pretty well to take your corporate information like Zillow's information and then shove that into one of these really large pre-existing agents, something like Claude or ChatGPT, which I would consider a large general purpose agent. And it sort of works like that. 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 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. It has not proven to be great at providing other value yet. And frankly, tools are just not enough. You know, I like to joke that we didn't land a man on the moon by giving one guy a ton of tools. That's not a realistic way to get a really large project done. So, you know, maybe MCP is not the way, but aha, we have skills. We have skills and skills are great. I actually do enjoy skills. 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. 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. 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 is going to help, but it's not the fundamental problem. 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. 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 life objective. 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. 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 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. These are the two areas where we constantly see new advances. We also see new things come out like skills and MCP, new technologies, new protocols. They are all coming out in the area of the context and the model. 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 MCPs installed. You've also got Figma and Playwright installed on yours. And all of these are building up in that context layer. And then you've got some Gmail MCPs to go check your mail for you and some Google Sheets to go fill out some other expense reports or something like that. 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. Maybe you've got Matt's grill me skill 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. 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. 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 additional extra layers, then the agent can do stuff that it previously couldn't do before. 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. And it turns out this is as old as time. Eventually inheritance starts to break down. Imagine like, you know, okay, I've got five skills on ChatGPT or on Claude, excuse me. And that works pretty well. 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. 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 a... thing that can be done by our primary agent. 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. It knows 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. 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. And then you can have more of these. You can still have your Gmail and your travel and your Google Sheets and all 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. 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. They just talk to each other the way a human does. So if the primary agent is saying, oh, 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 emails about a trip. 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. That's kind of a rough idea of how something like this could work. And the reality is it does work. And we know it works because this is actually how we got to the moon. 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. This is the Apollo 11 launch day. And look right here, there's an agent. I just found an agent sitting right there. That brain of his, that's his LLM. 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 that. And then look at that mouth. That's the messages. We are used to this. We can understand this. It implicitly works. It's almost a form of biomimicry for the agentic world. It works. And I call them domain-specific agents. 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. But that is what I want to talk to you about. Agents that are just... targeted to very specific domain. 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. And I'm not ready to come out here and announce a product or anything like that, but I can give you a little bit of a peek. First of all, they are far more token efficient, far more token efficient. 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. 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. But within that domain, you're going to get dramatic efficiency. And part of the reason is if you think about the way that the context works, I don't need to have the entire context of the conversation when I make a choice to do something. Instead, my primary coordinator level can just ask the Gmail. 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. And so it is then able to perform this very targeted, very specialized, tiny little thing without all of the surrounding context. It's also far more practical with small language models. If you look at the difference In two models like DeepSeq V4 Flash and Fable 5, the cost difference is mind-boggling. It is 137 times cheaper than Fable per task. 137 times. Now, granted, if... DeepSeq v4 flash fails over and over and over again to do the job Then not only is it going to be you know, not that much cheaper It's also going to be much more annoying to use it 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. 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. You can use all kinds of other models for smaller tasks. 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. We are all flying awfully close to the sun nowadays where everybody's just bypassing permissions left and right. 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. 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. 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 Doug in IT, he puts his heart at ease understanding the difference between those two. And fourth, 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. You can run thousands of instances all at the same time in all kinds of regions of the world. They don't actually need to be geographically co-located or anything like that. So they have very, very good scaling characteristics. Unfortunately, they don't exist. That's the downside. These domain-specific agents don't really exist. Not in a big public way. Like I said, here at Standard Agents, we have them, we are working with them on a daily basis, but they are not out there in public very much yet. However, that's changing. That is going to change very quickly. We're about halfway through 2026. And I'm here to make a public prediction that I think as we roll on from this point to the end of 2026, we are going to see a dramatic uptick in people talking about building domain-specific agents, frameworks around them. All kinds of things are coming down the pipe. And it's not going to be a small trickle. It's going to accelerate rapidly. And this will become one of the main players in the agentic ecosystem. 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. That's my big, bold public prediction. I was really excited just a few days ago when Vercel released EVE. This is the first time I actually saw the term that I had been blasting out into the void come back and hit me in my own face. 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 going to start picking up steam. That's my prediction. And there's a number of reasons. One of them is something that most people believe right now is that the cost of intelligence is going down. That trend reversed in 2026, actually. We track this on a website. Tokens are not getting cheaper anymore. They are actually going up. even when adjusted for IQ. 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, we've got this memory crunch. And, you know, probably the long-term trend over a 10-year cycle or something is that intelligence will go down. 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. Now, if you don't account for IQ, tokens are up 76% this year, almost 100% increase in tokens just this year. And we're not even halfway through it. We are really trending upwards on token costs. So anything we can do, especially with large businesses, to bring that down is going to be really important. The other use case to really consider is putting AI in front of customers. You can't put fable in front of a customer 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. So I'm gonna leave you here momentarily, 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. 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. 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 sub-prompts that can, you know, you can run a function that actually calls an LLM. So let's say I have a main agent running, but I want to use Nano Banana 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. 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 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. 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. So it looks like somebody just said, hey, what time it is? And the other person replied, oh, it's 6.45 p.m. Pacific time. Pretty simple. 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 these agent rules. And agent rules are kind of complicated. It's like... how many times should one side have a turn? Like can it go on for 10,000 turns or 10,000 steps before its turn is up? There's all kinds of interesting little rules. When it calls a tool, is it required to validate the whole thing or not? All kinds of very specific tools. or rules that belong to a specific agent. And all together, if we bundled all that up, we would call that an agent. But it's kind of missing a couple things. One, every agent should really have a file system. 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 son's birthday party? 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. 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. 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. 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 calls sub-agents. And there could be one or there could be many of these at different levels. 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. It knows all of its APIs. It 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. It can run spreadsheets. I can say, hey, what are all my top salespeople this year? Boom, it can look in Salesforce. It can coordinate with the sub-agent, create a sheet for you, send that back. 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 at once. And it's amazing at generating assets. Maybe that sub-agent doesn't just have like, you know. Codex image generation. Maybe it has nano banana. 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. 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. You know, the main one doesn't have all, you know, we don't want to have 45 megabytes of context just on GDPR. So we make that a separate sub-agent. So, you know, 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 kind of get the idea. 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. So thank you very much. I appreciate you listening to my talk. Again, Standard Agents is where we're working, standardagents.ai. You can actually sign up on there for early access. We are slowly starting to roll this out to a few people. If your business is super ambitious and really wants to try out small domain specific agents, then you can write me, info at standardagents. And of course, I'd appreciate a follow. Thank you so much. Bye.

“Composition over inheritance” has always been a good engineering rule. It may also be the unlock for useful AI. A Gmail agent is fundamentally more powerful than a Gmail skill — and when composed with Sheets, Notion, and GitHub agents, the system gets more capable, more reliable, and cheaper to run. Suddenly, smaller models can do real work, and AI can move from internal copilots to customer-facing products. In this talk, we’ll unpack why this architecture hasn’t become the default yet, what’s been missing, and how to start building toward it today.

Speakers:
- Justin Schroeder (StandardAgents): Co-founder of StandardAgents. Compulsive open source builder. Creator of dmux, ArrowJS, FormKit, AutoAnimate, Tempo, zodown
  X/Twitter: https://x.com/jpschroeder
  LinkedIn: https://www.linkedin.com/in/jpschroeder/
  GitHub: https://github.com/justin-schroeder