---
title: "Transcript: The Future Is Domain-Specific Agents - Justin Schroeder, StandardAgents"
category: "transcripts"
videoId: "spNAUEgq_A8"
sourceLabels: ["YouTube transcript", "Cached transcript markdown"]
wordCount: "5175"
---

# Transcript: The Future Is Domain-Specific Agents - Justin Schroeder, StandardAgents

## Source Video
- [YouTube](https://www.youtube.com/watch?v=spNAUEgq_A8)

## Local Cache
- `raw/sources/youtube-transcripts/spNAUEgq_A8.txt`
- 5,175 words

## Transcript

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's Justin Schrader. Uh you can find me on X at JP Schrader. And um I work at a small company called Standard Agents, which nobody's heard of right now cuz we're still kind of in stealth mode. 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, 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. 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.

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. 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 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, 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. 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. 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. A harness is an agent and an agent is a harness, okay? And for the for the purposes of this talk, we're going to 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, um you know, OpenClaude, 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 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 OpenClaude or Hermes. Uh Uh, and 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 in like 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, uh, 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, you know, 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 They believe, and are probably right, that if they appropriately leverage AI, they're going to 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, um, as a mechanism for doing it. 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. 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. 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. 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. 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 in an IT department, they are pulling their hair out because there are so many different concerns. 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. Um, but in reality, everybody's kind of 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 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. 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. >> [laughter] >> But if I try to pass it 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 going to run on that person's machine. 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. 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 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 pre-existing agents, something like Claude or ChatGPT, which I would consider a large general-purpose agent. Um and it and it sort of works like that. Uh and 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's 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 I I 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, uh you know, maybe MCP's not the way, but aha, we have skills. We have skills, and skills are great. Um I I 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's 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 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, you know, new new things come out like skills and and MCP, um new technologies, new protocols. They are all coming out in the in the area of the context and the model.

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 MCPs installed. 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. 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. 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. 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? 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 addish- 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 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. 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 an as a 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 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. 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 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.

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. That's kind of a 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. >> [laughter] >> That brain of his is 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 them. 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. 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 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. 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. 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. 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.

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. 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 DeepSeek uh V4 Flash and uh Fable 5, the cost difference is mind-boggling. It is 137 times cheaper than Fable per task. and 37 times.

Now, granted, if DeepSeek 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. >> [snorts] >> 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. We're 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. >> [snorts] >> And uh 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. 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 you know, geographically co-located or anything like that. Um so, they have very, very good scaling characteristics. Unfortunately, they don't exist. That's the downside. >> [laughter] >> These domain-specific agents don't really exist. Um 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 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 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 it's going to accelerate rapidly, and this will become a 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. So, 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 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, 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, 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. Um and we're we're not even halfway through it. So, we are really trending upwards on on token costs. So, anything we can do, especially with large businesses, to bring that down is going to be really important. Um the other the other use case to really consider is putting AI in front of customers. 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 going to be the way to do that. So, I'm going to leave you here in 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. 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 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, [snorts] 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. 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 kind of complicated. 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 it's turn is up? You know, there's there's all kinds of interesting little rules. 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.

And altogether, if we bundle 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 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 call sub-agents.

Um, 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 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. It can run spreadsheets.

I can say, "Hey, what are all my tops uh my my top sales people 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 it wants. 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 and 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, you don't we don't want to have 45 megabytes of context just on GDPR. So, we make that a separate sub agent. Uh so, you know, may 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, uh Standard Agents is where we're working, standardagents.ai. You can actually sign up on there uh for an early access. 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 info@standardagents. And of course, I'd appreciate a follow. Thank you so much. Bye.