Justin Schroeder argues that agents should be tuned for narrow tasks such as checking Gmail or monitoring issues, because their performance becomes easier to measure and improve.
2
Standards should package an agent's prompt, model, provider, tools, and runtime so another person can run it with the same behaviour and results.
3
Domain experts need to help define useful agents, while AI builders need to show them what the technology can do.
Summary
Justin Schroeder argues that the next generation of agents will contain many narrowly scoped specialists rather than one model that tries to handle every task. A Gmail agent, for example, could use only Gmail tools and run on a smaller model with lower cost and more predictable behaviour. Schroeder says the prompt, tools, model, provider, and harness all affect performance, so agents need standards and runtimes that preserve the setup that made them effective. He expects agents to be shared through existing interfaces, skills, or marketplaces, although Demetrios Brinkmann doubts that a conventional agent marketplace will work. The discussion also covers scheduled background agents, coordination trees, and small business uses such as helping a butcher order meat. The final argument is about adoption: domain experts understand their own problems, while AI builders understand the available capabilities. Both groups need a way to work together.
Justin Schroeder says current models are trained as broad "god models" that can code and answer wildly unrelated questions. He expects agents to be tuned for one small task and to perform that task very well. His example is an agent whose entire job is checking Gmail. A narrow responsibility makes its effectiveness easier to measure. Schroeder also imagines these agents being shared and composed with other agents, similar to how developers combine skills today. The difference is that the agent itself would carry a focused capability rather than asking one general model to handle every possible job.
The harness can change the result more than the model
Schroeder says the same model and prompt can produce very different results depending on the harness around it. He describes the harness as the combination of the prompt, tools, and surrounding setup. Once an effective configuration is found, the model's age or brand may matter less for that task. This becomes more important with smaller models, which need a precise specification. That specification would identify the exact prompt, model, provider, and related parts of the chain, giving another user the same setup and the same expected behaviour instead of asking them to recreate it by trial and error.
Agent standards should carry the setup that makes an agent work
Schroeder compares agent standards with the specifications shared by different JavaScript runtimes. He wants metadata pinned to an agent so the agent knows what it needs in its harness. He also expects dedicated agent runtimes, with different performance and operational tradeoffs, to run agents against a shared specification. In his view, a runtime ecosystem would let people deploy an agent with a guaranteed configuration while choosing an environment that fits the task. This would address the current problem where one person can create an effective Gmail agent, but another person cannot reliably use the same agent.
Scoping an agent can reduce tool overload and cost
The reason to scope down is not always to use a smaller model. Schroeder describes a microservices approach in which each agent has a limited responsibility and a limited set of tools. His coding agents may have several skills and MCP servers, creating a large set of possible actions. A Gmail agent would have Gmail-specific actions such as checking recent messages. Schroeder says this focused setup can let a smaller model produce more value quickly. He also describes background jobs that check issues or messages every five minutes, while warning that unattended agents can consume a large amount of usage and produce an unexpected $1K bill.
A coordinator is only one way to organise many agents
Brinkmann asks how anyone could keep track of a thousand agents. Schroeder answers that a coordinator with a tree or graph of subagents is one useful structure. A personal assistant could sit at the top while specialised agents handle separate tasks beneath it. He does not think every agent has to be found through that central assistant, though. Some agents could run quietly in the background, such as a small system for a butcher shop that calculates how much meat to order for the next week. That kind of focused application could run cheaply and remain mostly invisible to the user.
The agent marketplace may already exist inside other tools
Brinkmann says he is 99% sure a conventional agent marketplace will never work because users would rather ask Claude to build exactly what they need than browse random agents and modify them. Schroeder responds that everyone may already have a personal marketplace through the skills and MCP components they install. Brinkmann concedes that he has searched for recommended skills and use cases for his Hermes agent. Schroeder's distinction is that current skills often inject context into a general agent, which can make it worse at unrelated tasks. A more specialised agent could retain the same user interface while executing through its own guaranteed setup.
Domain experts know the problems that AI builders often miss
Schroeder says people outside the AI industry often have clearer ideas about useful applications than people who build agents every day. A nurse or doctor may immediately identify transcription, note-taking, and other workflow opportunities that technology workers overlook. The reverse problem also exists: domain experts may not know what the technology can do. Schroeder describes the needed relationship as a meeting between people who understand the capabilities and people who understand the work. Domain experts should help shape the agents for their fields, while AI builders need to expose enough possibilities for those experts to recognise useful applications.
"You can have an unbelievable output from one harness and a terrible output on the same prompt with the exact same model and the only difference is the harness."Justin Schroeder04:42
Who should watch
You are building general-purpose agents and need to decide whether a narrow agent with fewer tools would be easier to evaluate and run.
Your agents perform background work and you want to understand the cost and runtime risks of leaving them active.
You work with a domain team whose members know the workflow problems but need help identifying which agent capabilities could solve them.
