The Future Is Domain-Specific Agents - Justin Schroeder, StandardAgents

Overview

Justin Schroeder argues that the next major shift in AI agent development will mirror the Industrial Revolution: we’ll be “harnessing intelligence with agents” rather than “harnessing energy with machines.”

He claims that building useful agents isn’t primarily about generic, all-purpose chatbots, but about domain-specific agents—small agents specialized to a narrow task area (e.g., Gmail, travel booking, Figma editing, compliance)—orchestrated by a higher-level coordinator.

---

Definition & framing

• Schroeder proposes an agent definition: deterministic software that harnesses the non-deterministic outputs of models to achieve a desired objective.
• For the purposes of the talk, he treats “harness” and “agent” as effectively interchangeable (he notes a pedantic distinction isn’t useful for the message).

---

Why custom agent-building is currently hard (and often fails)

Even though models like ChatGPT, Claude, and open models are widely available, companies still struggle to build robust “custom agents.” He highlights:

• Integration is the real driver: businesses need their data and tools integrated correctly into AI workflows.
• But robust agents are “absolute nightmare” level engineering due to:
  • Careful orchestration of the agentic loop
  • Multiple provider abstractions
  • Durable execution (ability to resume after faults)
  • Validations and stop conditions
  • Telemetry/observability at scale (diagnose what happened at every step)
  • Portability issues (agents often don’t run reliably across environments)
  • Composability issues (hard to reuse an agent across products/workflows)

---

MCP and “tools-only” limitations

• Many teams pivot toward Model Context Protocol (MCP) to plug company data/tools into larger general agents (e.g., Claude/ChatGPT).
• He argues MCP can become a de facto tool distribution mechanism, but it provides limited additional value beyond tools.

Analogy: MCP isn’t enough to “hand one guy tons of tools” and finish a “moon landing”—tools aren’t the fundamental solution.

---

Skills and context inflation (why inheritance-style approaches break down)

He describes an “agent stack” roughly like:

• Model
• System prompt (role/objective)
• Tools
• Skills (described as markdown-like documentation; warns that using many can make agents worse)
• MCP
• Conversation messages

In practice, he says this becomes mostly context stuffing.

He argues many existing approaches “solve integration” by inflating context (system prompts + tools + skills + MCP content). This often uses an “inheritance” approach (adding layers of context/skills to extend capability), which:

• Works initially,
• But hits diminishing returns when scaled to large numbers of skills (100s/1000s).

---

Proposed alternative: composition via domain-specific agents

Rather than one agent accumulating more and more context, Schroeder proposes composition:

• Create separate isolated full agents per domain/task (each with its own message history and agentic loop)

• A coordinator agent manages them

• Communication between agents happens using plain English (human-like requests)

Example flow:

1. Coordinator asks the Gmail agent for trip-related emails
2. Gmail agent returns relevant information
3. Coordinator then calls the travel agent to book based on those details

---

Claimed advantages of domain-specific agents

Schroeder presents several benefits:

1. Token efficiency

   • Regularly >80% token efficiency for tasks, since specialized agents only need minimal context.

2. Portability / ecosystem potential

   • A Gmail agent could be reused by other coordinators, reducing duplicated effort.

3. Cheaper with smaller models

   • Specialized agents can be constrained to a narrow job, enabling use of cheaper/smaller models.
   • He cites cost differences such as “137x cheaper” (model names are referenced, though details are unclear from subtitles).

4. Ability to enforce strict capability limits

   • Specialized agents can be restricted to approved actions, addressing concerns like “permission bypass” when large models can do anything.

5. Better scaling characteristics

   • Each small agent can run in its own execution environment, enabling parallelization and deployment without requiring large shared infrastructure.
   • He claims they could scale to thousands of instances globally.

---

Missing piece / public availability downside

• Schroeder says domain-specific agents don’t exist much publicly yet in large, visible ecosystems.
• Prediction for acceleration:
  • By mid-2026: more frameworks and talk around domain-specific agents
  • 2027: “year of multi-agent orchestration”
• He references Vercel releasing Eve, described as supporting a “company brain / personal assistant / domain-specific agent.”

---

Cost trend argument

He argues token/intelligence costs aren’t steadily falling:

• He claims token costs increased during 2026 (based on internal tracking), making efficiency more important.
• He notes customer-facing AI is constrained by cost—“can’t put very expensive models in front of customers” unless lifetime value is massive.

---

“Ideal agent” architecture details (deeper technical concept)

At the tool layer, he proposes a more granular design:

Tools split into

• Functions (e.g., write to filesystem)
• Prompt tools
  • Smaller injected prompts that call another model for sub-tasks (e.g., image generation)
• Sub-agents
  • A domain-specific agent can itself be invoked as a tool

Hooks

Mechanisms to inject or mutate context/side effects, such as:

• Providing the current time to an LLM via an artificial message/tool call

Agent rules

Constraints like:

• Turn/step limits
• Validation requirements
• Tool call constraints

---

Required primitives: filesystem + sandboxed code execution

He claims every agent should include:

• Its own sandbox filesystem
• A sandboxed code execution environment
  • So it can create files and run code safely without broad OS access or exfiltration.

---

Recursion and hierarchical multi-agent teams

He describes nested orchestration, for example:

• Coordinator agent → Salesforce agent → asset generator sub-agent → legal team agent → compliance agents (e.g., GDPR/OSHA)

Key idea:

• Each specialized agent keeps a small minimal context window
• Yet the team contributes to end-to-end workflows.

---

Product / ecosystem mentions (what he says about his work)

• He does not announce a specific product during the talk, but teases an ecosystem for domain-specific agents:
  • standardagents.ai (early access sign-up mentioned)
• Mentions open-source projects (agent tooling ecosystem), including:
  • Dmux: multiplexer for coding agents
  • ArrowJS: “React-like” UI framework for the agentic era
  • Additional projects mentioned but not detailed

---

Main speakers/sources

• Justin Schroeder (talk speaker; Standard Agents; mentioned contact/social handles)

Referenced external sources/tools:

• Vercel (AI SDK, Durable execution, and release of Eve, plus the closest “agent definition” reference to Vercel’s work)
• Model Context Protocol (MCP) (referenced MCP website)
• Large agent platforms mentioned: Claude, ChatGPT