Standard Agents' Justin Schroeder argues that rather than entrusting every task to one enormous model, we should compose agents specialized in small tasks or particular business processes. Businesses want systems deeply integrated into their work that repeatedly produce correct results, more than impressive models themselves. Delivering that at scale requires standards ensuring agent portability and interoperability.

1. Today's AI in an Old Factory

Justin Schroeder introduces himself as someone who used to write a lot of code and had a bad habit of continually releasing it as open source. His talk addresses domain-specific agents, the focus of his organization, Standard Agents.

To illustrate the difficulty of predicting the future, he begins with postcards made in 1899 depicting a future Paris. Some visions of the year 2000 were wildly off target; others were surprisingly, or unfortunately, accurate. This is a light warning that his own predictions may also prove wrong.

He then shows an Industrial Revolution factory. A large, heavy, expensive steam engine sat at the center, powering workstations through long line shafts and belts running throughout the building. Dangerous and inefficient in many ways, the arrangement nevertheless worked.

He compares today's AI agents to that stage:

"We put one giant model at the center of everything and connect individual human tasks to that central system."

Skills or MCP may provide those connections. He does not mean these are bad, but says the arrangement resembles the centralized factory. He wants a factory in which every workstation has its own power source and workspace. The practical equivalent is a domain-specific agent built for one or two small tasks.

2. What Is an Agent, and Why Is Building One Hard?

Acknowledging that definitions vary, Schroeder offers his own:

"An agent is deterministic software that uses nondeterministic outputs generated by a model to achieve a desired goal."

In plain terms, an agent takes potentially variable model outputs and uses defined software to call tools and manage subsequent actions. It can be understood as a software-based control system; he sees little practical value in drawing a strict distinction.

On the surface, building an agent looks simple: let a language model call tools, feed their results back, and repeat. This is the familiar agent loop. Production operation is much harder.

The workflow must coordinate asynchronous operations, avoid dependence on one model provider, and support durable execution that resumes after failure. Many programming tools exist, but combining them into an effective agent is difficult.

He remarks somewhat satirically that this difficulty prompts suggestions to skip agents, build MCP servers, and give employees tools such as Claude. Yet ordinary businesses outside Silicon Valley are building agents. Even businesses building MCP servers sometimes place agents behind those calls.

3. Three Reasons Businesses Build Agents

He summarizes the motivations as integration, trust, and effectiveness:

• Integration: Businesses want AI deeply connected to existing processes and systems.
• Trust: They struggle to trust a broadly empowered general-purpose AI to behave appropriately every time.
• Effectiveness: What matters is consistently finishing the job, rather than which technology did it.

Quoting a friend at a large company, he explains why faster coding alone does not solve every business problem:

"Even if we handwrote the code on napkins, tore them up, mailed each piece around the world in envelopes, got them back, reassembled them, and typed them into a computer, that would not be the bottleneck in shipping a new feature."

Organizational and procedural factors, beyond development speed, can block releases. Although AI use has spread widely, he believes it remains superficial in many companies.

He cites HVAC business Blue Ridge Mechanical. Its operations consist of many processes: local marketing, lead acquisition and qualification, customer onboarding, revenue forecasting, and more. Each has a beginning and end; long or short, they collectively run the business.

Offering a super-powerful AI to replace all those processes may feel dangerous. The company has no reason to entrust its entire functioning operation to it. Instead, focus on one clearly bounded process, such as fleet maintenance: receive a breakdown report, prioritize it, schedule repairs, update records, and return the vehicle to service.

"If you say you can automate that process and make it work correctly, that becomes an interesting proposition for a business."

The point is not vaguely "adopting AI" but deeply integrating AI into specific work that already exists.

4. Trustworthy Dedicated Agents Instead of General-Purpose Skills

To explain trust, Schroeder examines agent components. Above the base model may sit a system prompt assigning a role, executable functions, subprompts for small reasoning tasks, and callable subagents.

There may also be hooks that run in prescribed ways at particular moments and rules limiting how many steps an agent can take. File-system access and code execution can be added as needed. Together, these elements form an agent.

Tools such as Codex that can work for extended periods are useful in some situations, but an HVAC business does not want endless work. It wants a particular process completed and worries about agents moving beyond its control.

His alternative is a dedicated Gmail agent rather than a general-purpose agent with a Gmail skill. It understands Gmail and its APIs, but lacks unnecessary tools.

"If you ask it to check Twitter while writing an email, the Gmail agent says, 'No. I cannot do that because I do not have the tools.'"

A general-purpose agent with many skills and permissions may expand a request into unexpected actions, he jokes—for example, discovering a security issue while checking email and shutting down production as a precaution. He adds that this is an exaggeration, but not a large one.

To reduce such risks, he proposes small agents dedicated to Figma, Gmail, Google Sheets, and so forth, with an orchestrator coordinating and assigning work above them. MCP can connect the agents.

He says Grok bots also use small agents specialized in particular subtasks internally, arguing that the approach already works effectively.

5. Established Engineering Principles, Not a New Architecture

Composing small agents is not new, he says. Software engineering already offers relevant principles:

• Least privilege: Give each component only the permissions it needs.
• Separation of concerns: Manage distinct responsibilities separately.
• Composition: Combine necessary components rather than concentrating everything in a giant structure.
• The law of Demeter: Avoid components knowing or depending excessively on one another's internals.

These principles should apply consistently to agents too.

He also invokes the moon landing. Behind the people who landed stood teams of experts deeply familiar with their respective fields. Specialists used their own tools and information, pooling knowledge toward one goal—much like cooperating specialized agents.

Returning to the factory, electric motors, particularly induction motors, enabled independent power at each workstation. He compares that to individual agents working independently within their scopes. However, electric motors alone did not immediately transform factories, a qualification he revisits later.

6. Effectiveness Comes from Business Evaluations, Not Public Rankings

Discussing effectiveness, Schroeder criticizes public benchmarks. Rankings sometimes conflict with experienced performance, and a single score can be mistaken for a model's overall quality.

He quotes a researcher named Diogo to explain why public benchmarks should not be trusted unconditionally:

"The biggest victims of benchmarks are the people who need their results most: those without time to test models themselves and develop a feel for their capabilities."

An HVAC business cares far more about whether its work is handled properly than public rankings.

He likens this to the streetlight effect: a drunk searches beneath a streetlight because visibility is better, although the keys were lost elsewhere. AI evaluation can likewise focus on what is easy to measure instead of the answer actually needed.

Domain-specific agents have a clear advantage here: narrow scope makes task-specific evaluations easier to build. Testing whether a dedicated Gmail agent checks email correctly is easier than ensuring a general-purpose agent with countless contexts and tools performs the same task correctly every time.

"Breaking agents down into individual tasks or business processes lets you evaluate those processes much more precisely."

7. Using Models' Uneven Capabilities to Reduce Costs

Model performance is uneven: one model may excel at a task but struggle with others. The best overall model is not necessarily the best fit for a particular task.

He illustrates this with a small project, Model Zen Garden. Different models receive the same prompt to generate small 3D worlds, and their results are compared. The name comes from CSS Zen Garden, which compared website CSS implementations.

In one example, Tencent's HY3 produced a more impressive result than another model: grass swayed in the wind and lighting looked natural. Schroeder considers it poor at most other tasks but remarkably good at 3D work, saying that generating this world cost about 60 cents.

"If a model handles that business process correctly at a reasonable cost, it does not matter whether a better model exists overall."

Small agents can select suitable models for each task to reduce token use and cost. In a small internal evaluation not yet published, he claims isolating simple tasks, such as retrieving emails from a particular person, substantially reduced token consumption.

He also reports that DeepSeek V4 Flash was 137 times cheaper per task than Fable in his comparison. This is a specific comparison presented by the speaker, not a claim that every task has the same cost difference. His point is that cheaper models should not be expected to do everything Claude does, but may be entirely suitable for narrowly scoped tasks.

8. Motors Plus Standards Transformed the Factory

Later, Schroeder partly corrects his earlier claim that electric motors transformed factories. They mattered, but factories initially replaced steam engines with electric motors while retaining centralized line shafts. In his account, this continued for roughly 30 years after induction motors appeared.

He compares it to upgrading the central model connected to numerous skills. Efficiency may improve somewhat, but the underlying architecture remains unchanged.

"It is like upgrading the model at the center. It works and is a little more efficient, but it is not the change that revolutionized everything."

He identifies standardization as the real turning point. Initially, inconsistent current types, frequencies, voltages, and amperages made motors so expensive to use that factories sometimes had to build their own. Standards made it much easier to supply electrical equipment to individual workstations.

Citing US electrical specifications, he says bench grinders made in 1910 and 2021 are effectively interchangeable in terms of power supply. The ability to use the same standards across eras is what matters.

He sees domain-specific agents as an emerging reality rather than a distant future. He also predicts fewer tools will ask users to choose models. Model choice interests enthusiasts, but most businesses care about getting the job done correctly, not model names.

9. Standards and Runtimes for Agents

Scaling agents requires more than building many of them: standards for creating, installing, and connecting them are needed. He proposes:

• Domain specificity: Focus on a clear, narrow area of work.
• Reproducible execution environments: Installing someone else's agent should provide the same capabilities and environment as the original.
• Portability: Agents should be installable and transferable like packages installed through npm or pip.
• Vendor independence: Avoid being trapped within one company's proprietary system.
• Composability: Agents should communicate and cooperate through standardized mechanisms.

Vendor independence and reproducible execution are distinct. A standard should avoid dependence on one vendor's tooling, but running a validated agent elsewhere requires matching key conditions, including model, provider, and quantization level, to reproduce expected performance.

He introduces Standard Agents as a small team addressing this problem. It aims to offer an open-source specification defining how to build domain-specific agents and a runtime to install and run them. Longer term, he envisions an ecosystem of competing execution environments, analogous to Node and Python.

10. Q&A: Model Choice and Operational Governance

The first question concerns the balance between implementing workflows directly in agents and adjusting the models themselves. Schroeder says business logic is implemented primarily in the agent.

Nevertheless, the model remains an important component. Developers build an intuitive understanding of models' strengths and weaknesses, so building an agent for a particular model matters, especially with smaller models.

"The agent should be very small and narrowly scoped, but the model is still an important part of it."

He does not consider casually switching a tool's model and sending the same data a sound long-term approach: after a model change, it is hard to verify preserved behavior. Understand models' different strengths and weaknesses and apply them to the work instead.

The second question asks how to maintain and govern multiple agents as models continually change: must every new flagship trigger upgrades, and how should agents using mixed models be controlled?

He says an operations platform is needed so an organization's IT team can see all its small running agents and manage their evaluations. New models should be assessed using internal evaluations tailored to the company's business processes, rather than public rankings.

But a new release alone is no reason to switch:

"If the current model does its job correctly, just keep using it until it is retired."

He closes by reaffirming that repeatedly producing correct results comes first.