The Future Is Domain-Specific Agents

The Industrial Revolution turned energy into useful work through machines. What plays the equivalent role when the resource is intelligence? For Justin Schroeder, the answer is agents: software that puts model intelligence to work toward an objective. Schroeder works at Standard Agents, described in the recording as still largely in stealth, and builds projects including dmux, a multiplexer for coding agents, and ArrowJS, a UI framework he likens to React for the agentic era. His opening analogy frames AI as an accelerated industrial transition: agents become the machinery through which intelligence is used.

Recognizing an agent is easier than defining one. Developers can name examples while disagreeing about what belongs in the category. Schroeder adopts an operational definition: an agent is deterministic software that harnesses nondeterministic model results in pursuit of a desired objective. The model supplies uncertain outputs; the surrounding software organizes their use. For this discussion, agent and harness refer to that same package. The distinction matters less than the software responsible for turning model responses into useful action.

Claude, Codex, OpenClaw and Hermes may be familiar names to agent developers. Schroeder suspects an ordinary office worker would recognize far fewer—and might not describe even Claude as an agent. Yet he encounters custom-agent projects everywhere: a neighborhood real estate agency, independent insurance brokers and Fortune 500 companies. Familiarity with agent terminology is not a prerequisite for wanting one.

Why build custom software when ChatGPT and open-source models already make AI widely available? Access to intelligence does not integrate a business’s data and workflows. Businesses want AI to operate with their information, inside the processes where better decisions or faster execution would produce value. Building a custom agent is an obvious route to that integration, even when the business has little interest in becoming an agent-platform developer.

The first difficulty is the agentic loop: orchestration must correctly carry a task through model responses, tool calls and subsequent decisions. Provider differences add another layer; Schroeder points to the Vercel AI SDK as useful help with those abstractions. Durable execution must recover after faults, while validation and stop conditions determine which actions are acceptable and when execution should end. A demo can appear successful before these requirements are handled reliably.

The remaining problems concern the agent as an operational software component:

• Construction: teams invent their own approaches. Schroeder identifies Vercel’s recently released eve as an emerging approximation to a defined way of building agents.
• Observability: diagnosing and tuning behavior requires knowing what was transmitted at every step of every turn, including when execution goes wrong.
• Portability: environment variables, system requirements and runtimes can make a successful agent work only on its creator’s machine.
• Composability: even a good university chatbot may be difficult to reuse in another application.

Together, these costs can make a team retreat from custom agents before it reaches a robust, reusable system.

A common next move is to connect company systems to an existing general-purpose agent through Model Context Protocol. Schroeder uses Zillow’s information flowing into Claude or ChatGPT as an example. Looking at the client-support matrix in the recording, he observes that tools are the only consistently supported column and characterizes MCP’s practical role as tool distribution. That is a historical observation about client support, not a restriction of the protocol: the linked July 2026 documentation also covers data and prompts.

Tools alone do not supply a division of labor. Schroeder’s moon-landing analogy makes the limitation concrete: giving one person a vast collection of tools would not create the organization needed to reach the moon. Skills add instructions, which help, but a stack of manuals does not create a team either. He describes skills primarily as Markdown documentation and invokes research suggesting that large skill collections can worsen performance, without naming a study. The useful architectural question is how much responsibility remains concentrated in the same agent after both tools and instructions have been added.

Build up the stack from the bottom. A model supplies intelligence. A system prompt establishes its role. Tools expose actions, skills provide instructions, MCP connects external capabilities, and conversation messages carry the ongoing task. Most of what sits above the model ultimately contributes information to its context. This is where much integration work happens: changing the model or changing what the model receives.

Consider a developer who installs travel integrations for business trips, Figma and Playwright for work, Gmail for email, and Google Sheets for expense reports. React fixers and linters add development guidance; Matt’s grill-me skill and a GitHub skill add more. Each extension gives the same agent another responsibility. Schroeder compares this to inheritance: take an object and keep adding properties so that it can do more things.

The approach works, but its benefits need not grow indefinitely. Schroeder moves from five skills to hypothetical libraries of 100 or 1,000 to illustrate diminishing returns, not to establish a measured limit. The enduring software-design alternative is composition: distribute responsibilities among cooperating components. Context accumulation is a useful architectural model here, but installed skills should not be equated with fully loaded documents; skill systems can load instructions on demand, and selecting the right skill is a separate challenge from fitting its contents into context.

Instead of adding Figma expertise to the primary agent, give Figma its own agent. Its system prompt establishes the Figma-specific role; its knowledge concerns Figma’s API and interactions; its tools expose precisely the actions it needs. Its short message history concerns only the Figma task. Gmail, travel and Google Sheets can receive the same treatment. Each component is a complete agent with its own loop and history, rather than merely a server exposing tools.

A coordinator communicates with these specialists in ordinary English. The travel example becomes a small sequence:

1. The coordinator asks the Gmail agent whether recent email mentions a trip.
2. The Gmail agent returns information about a trip to Los Angeles that weekend.
3. The coordinator asks the travel agent to begin making bookings.

The coordinator carries the broader objective; the specialists perform the local work. This is a proposed workflow, with the email result and booking handoff illustrating how responsibilities could move between agents.

The Apollo 11 launch-day comparison now changes. Instead of one person with every tool and manual, there is a team of experts. Schroeder points to a controller’s brain as the model, the dashboard as a bounded toolset, and speech as the message interface. The analogy explains the organization he wants to reproduce: separate expertise connected through communication. He calls these components domain-specific agents, while explicitly declining credit for inventing either the idea or the term.

Standard Agents has been building an internal ecosystem around this arrangement. Schroeder reports “over 80% token efficiency” on tasks defined more explicitly ahead of time. He does not define the baseline or token accounting, so the phrase cannot be translated into a measured 80% reduction. Portability is the complementary goal: package a working Gmail agent so that another user can reuse its capabilities instead of rebuilding them.

The mechanism is easiest to see with a narrow request: retrieve Debbie’s latest email. The Gmail specialist need not receive the coordinator’s entire conversation. It can work from its own system message, its Gmail tools and the incoming request. Irrelevant travel, design or spreadsheet history does not need to accompany that local decision. The savings come from deciding which information belongs at each level of the system.

That narrower task also changes which model may be adequate. Schroeder claims DeepSeek V4 Flash is 137 times cheaper per task than Fable 5. The comparison lacks a specified workload, retry policy, token mix and matched success rates. He immediately identifies the practical constraint: if the cheaper model repeatedly fails, it loses both its economic advantage and its usefulness.

Specialization makes it possible to select tasks a smaller model can perform faithfully with minimal context. There are therefore two distinct opportunities: send fewer irrelevant tokens and use a less expensive model where its capability is sufficient. The same division of labor extends beyond language models; image-generation and diffusion models can serve tasks suited to their outputs.

Broad coding agents invite broad permissions because they can potentially do almost anything. Schroeder contrasts the habit of bypassing permission checks with a specialist whose available actions have already been explicitly approved. Permission dialogs may still be necessary, but the agent begins with a smaller capability surface. His imaginary colleague Doug in IT is reassured by the difference: approving a bounded business operation is easier to reason about than granting a general-purpose agent unrestricted reach.

Each specialist is also a small, independent execution environment. Schroeder proposes running thousands of these instances concurrently across regions, without requiring geographic co-location or one giant VPC. This is the scaling model he expects from the architecture: local execution can be distributed while coordination happens through messages. He presents the deployment potential, rather than a measured load-test result.

There is a substantial availability gap between this architecture and a public ecosystem of reusable specialists. At the time of the recording, Schroeder describes daily internal use at Standard Agents but little broad public availability. He predicts rapidly increasing discussion and framework development through the end of 2026, followed by a 2027 centered on multi-agent orchestration. Vercel’s eve is an encouraging early signal to him because its positioning includes company brains, personal assistants and domain-specific agents. These are adoption forecasts, not completed milestones.

The economic motivation is that intelligence need not become cheaper on every timescale. Schroeder reports that 2026 token costs had risen 29% after adjustment for “IQ,” which he rounds to about 30%. He suggests a memory crunch as one possible contributor while allowing that the longer-term cost of intelligence could still decline. Even under that long-term expectation, decomposing work so it can use cheaper models remains valuable—and, he acknowledges, difficult.

He also reports a 76% increase in unadjusted token costs during 2026. The recording does not identify the tracking website, index composition or meaning of the IQ adjustment, so these figures remain attributed observations rather than a reproducible price index. Their practical role in the argument is customer economics: Schroeder regards Fable as too expensive for many customer-facing applications unless customer lifetime value is unusually high. Specialization offers a route to preserving task effectiveness while reducing the cost of serving each customer.

The closing architecture sketch returns to the model and system prompt, then expands what counts as a tool. This is an ideal agent design, rather than a walkthrough of a released API.

A primary agent using GLM 5.2 could invoke Nano Banana through an image-generation prompt tool. Another tool could invoke a full agent with its own loop. A uniform tool layer can therefore expose operations with very different internal complexity.

Hooks provide a place to modify state or perform side effects around execution. Schroeder’s example supplies information a model does not inherently know: the current time. A hook can inject a synthetic exchange into message history so that the model receives an explicit time value. The example answer is 6:45 PM Pacific Time. In TypeScript, the history transformation can be expressed directly:

type Message = {
  role: "system" | "user" | "assistant";
  content: string;
};

function injectCurrentTime(
  history: readonly Message[],
  currentTime: string,
): Message[] {
  return [
    ...history,
    { role: "user", content: "What time is it?" },
    { role: "assistant", content: currentTime },
  ];
}

const history: Message[] = [
  { role: "system", content: "Help with the user's task." },
];

const nextHistory = injectCurrentTime(
  history,
  "6:45 PM Pacific Time",
);

The existing messages remain intact, and the hook appends the time exchange. In an application, the supplied value would come from the runtime’s clock. The mechanism is explicit context injection; hooks can also trigger side effects rather than adding messages.

Agent rules determine how the loop may proceed. How many steps can occur before a turn ends? Could an agent continue for 10,000 turns or steps? Must a tool call pass validation? Schroeder raises these as policy questions, not recommended settings. They belong to the particular agent alongside its tools and hooks, because different domains require different execution limits and validation behavior.

The bundle still needs an agent-owned filesystem. Ask ChatGPT, Claude or Codex to make a PDF for a child’s birthday party, outside an explicitly configured project, and the resulting artifact needs somewhere to live. Schroeder uses that familiar interaction to argue that file storage is a basic agent facility, not merely an optional feature for coding workflows.

The companion primitive is sandboxed code execution. An agent should be able to write files and run them inside its own isolated environment. Schroeder’s desired safety properties are preventing exfiltration and preventing access to the surrounding operating system; those are requirements for the sandbox to enforce, not automatic consequences of calling an environment a sandbox. In the proposed design, both filesystem and execution facilities are built into every domain-specific agent.

Once a complete agent can be exposed as a tool, delegation becomes recursive. A coordinator can call an agent that calls one or several further agents. Schroeder’s business example begins with Salesforce: a specialist holds the relevant API knowledge and credentials for the company’s instance. Asked for the year’s top salespeople, it could retrieve the information and coordinate with a Google Workspace agent to create and return a spreadsheet.

The Salesforce agent could also delegate asset creation to an agent dedicated to that work. That specialist might combine Codex image generation, Nano Banana and an SVG generator, then perform its own reflection and quality assurance. The calling agent requests an outcome without needing to carry every asset-generation technique in its own context.

The primary coordinator might then ask a legal-team agent to review the work. European-customer issues could go to a GDPR specialist; workplace-safety issues could go to a separate OSHA specialist. Schroeder’s hypothetical 45 megabytes of GDPR context makes the separation vivid: the coordinator should not need every compliance detail merely because one branch of a task requires it. The completed structure is a hierarchy of cooperating agents, each retaining a small local context while handling its part of a larger workflow.

At the recording’s close, Standard Agents is slowly opening access to a small number of users. Schroeder directs interested businesses to standardagents.ai for early-access signup and invites interested businesses to contact the company about trying domain-specific agents. The rollout invitation follows the architectural ambition: make specialized capabilities reusable as complete agents, including their execution machinery, so that larger workflows can be assembled from smaller working parts.