Why Domain-specific Agents Are the Future - Justin Schroeder, Standard Agents

Summary

Justin Schroeder argues that businesses should move away from one general-purpose AI agent with access to many tools and toward small, domain-specific agents, each designed for one or a few business tasks.

Why use focused agents?

Schroeder gives three reasons:

• Integration: Agents can be built directly into existing business processes. For example, an HVAC company could automate a fleet-maintenance workflow: record a vehicle issue, assess its priority, schedule repairs, update records, and return the vehicle to service.
• Trust and control: A narrowly scoped agent has only the tools and permissions needed for its job. A Gmail agent, for instance, should handle Gmail tasks rather than being able to wander into unrelated actions.
• Efficacy: It is easier to test whether an agent reliably completes one defined process than to evaluate a general assistant with many unrelated responsibilities.

Schroeder defines an agent as deterministic software that uses a model’s non-deterministic outputs to achieve a goal. In practice, an agent may include a model, system instructions, tools, subagents, deterministic checks or “interceptions,” and rules that control its execution. He stresses that orchestration, recovery, and provider handling make agents more complex than a simple model-and-tool loop.

Architecture and efficiency

Schroeder favors many small agents connected through an orchestrator—for example, separate Gmail, Figma, and Google Sheets agents—rather than giving one assistant broad access to everything. He relates this approach to established engineering ideas such as least privilege and division of responsibilities.

Focused agents can also be evaluated against the specific business processes they serve. Since models have uneven strengths, an agent can use a less expensive model that performs well on its narrow task instead of defaulting to the most capable model for everything. Schroeder says his team’s internal testing found lower token use for some small tasks, while cautioning that public model benchmarks can be misleading. He illustrates model specialization with a project comparing models on 3D generation.

The factory analogy and standards

The talk compares today’s centralized agent setups to factories powered by a large steam engine and a system of line shafts. Replacing the steam engine with an electric motor was not enough to transform factories; broader changes and standards were needed. Schroeder sees standards as key to making domain-specific agents practical at scale.

He says agent standards should make agents:

• Portable: Installable across environments, potentially through package managers such as npm or pip.
• Vendor-agnostic: Usable across providers while retaining clearly defined behavior and configuration.
• Composable: Able to communicate and work together through common conventions.
• Consistent and assessable: Equipped with defined tools and settings so businesses can verify performance.

Schroeder says his company, Standard Agents, is working toward an open-source specification and a runtime for installing and running agents. In the Q&A, he adds that businesses will need internal platforms to oversee their agents and private, task-specific assessments to decide whether to adopt a new model. He advises against casually swapping models without verification.

Reviews, guides, and resources mentioned

• Schroeder recommends a report about the internal workings of the Grok bot, which he says illustrates the use of small specialist agents.
• He also praises an article by Diogo about public benchmarks and the “streetlight effect.” The subtitle does not provide the article’s title or a reliable link.
• No step-by-step tutorial or formal product review is presented.

Main speaker and sources

• Main speaker: Justin Schroeder of Standard Agents. The auto-generated subtitles render his surname as “Schrader” in the introduction.
• Other sources referenced: Diogo’s article on benchmarks and a report on the Grok bot’s internal design.