Every Company Is Building Agents That Can't Work Together with Justin Schroeder, Standard Agents

Rather than relying on generic, maximally capable AI models wired up via MCP and markdown skill files, businesses need and are already building narrowly scop

Abstract

This synthesis examines a claim that runs counter to prevailing guidance in applied artificial intelligence (AI) engineering: that exposing a business through a Model Context Protocol (MCP) server and delegating work to a maximally capable generalist model is insufficient for production use. Evidence drawn from observed market behavior suggests organizations continue to build narrowly scoped, domain-specific agents for three reasons - integration, trust, and efficacy. The analysis identifies the binding constraint as the absence of a standard for the agent runtime (the harness), rather than for the agent's surroundings (tools, prompts, inter-agent communication, payments). The newly announced Standard Agent Specification is presented as a code-first, TypeScript-based response, together with a reference runtime, the Standard Agent Builder. Reported demonstration metrics include automated generation of a complete warranty-claims agent in 5 minutes 21 seconds and a 94% prompt cache hit rate in production telemetry.

1. Introduction

An agent, under the definition advanced here, is "deterministic software that harness[es] the non-deterministic results produced by models in pursuit of a desired objective." This framing locates the engineering problem not in the model but in the surrounding deterministic scaffolding - the harness - and yields the corollary that "a good agent is a good harness."

The dominant architectural recommendation of the present period is to wrap a business in an MCP server, supply markdown-based skill or Agents.md documentation, and route requests to a frontier model. Observed practice contradicts this recommendation: organizations continue to invest in bespoke agents. The central research question is therefore why this divergence persists, and what standardization is required to make domain-specific agent construction sustainable at scale.

Section 2 establishes the standards landscape. Section 3 analyzes the three drivers of custom agent construction and the fragmentation problem they create. Section 4 details the specification's technical primitives. Sections 5 and 6 discuss implications and limitations.

2. Background and Related Work

Existing standards address the agent's periphery. MCP standardizes tool distribution. Skills and Agents.md standardize prompt-style documentation. A2A and ACP standardize agent-to-agent communication. x402 standardizes agent payments. No existing standard governs the runtime in which an agent executes.

Two prior results inform the efficacy argument. First, the Jeppa paper reports that fine-tuning an agent's prompt is more effective than fine-tuning the underlying model - relocating optimization pressure from weights to harness. Second, the concept of LLM jaggedness holds that capability surfaces are uneven, such that a small, inexpensive model may outperform a large one within a narrow band. The "Model Zen Garden" project is cited as an instance, where a small model excelled specifically at 3D Zen garden generation.

3. Core Analysis

3.1 Integration: the business as its processes

The argument proceeds from the premise that "a business is really just its processes" - warranty claims, crew scheduling, permit pulling, financial aid, grant administration, billing disputes, payroll, contract review. Relationships, network effects, and proprietary data are treated as downstream consequences of those processes executing well. Delegating business-critical processes to a generic agent is characterized as unacceptably risky even when the agent performs competently, because organizations require control, reliable repeatable execution, and preservation of brand voice and tone.

3.2 Trust as capability restriction

The trust argument is compressed into the maxim: "If an agent can do anything, it might do anything." Unrestricted tool access is treated as a liability rather than a feature. The illustrative failure mode involves an agent tasked with processing a warranty claim that instead creates unauthorized accounts, replies to unrelated emails, or browses unrelated content, because it technically retains the tools to do so. The proposed remedy is event-triggered, narrowly scoped workflows - an agent invoked by a warranty claim event possesses only the tools required for that task (lookup equipment, attach photos, submit claim), while still operating as a full multi-turn agent with its own context and evaluative capacity.

3.3 Efficacy over raw capability

Efficacy is distinguished from efficiency: efficacy concerns whether a task is actually completed well and improves on the prior process, independent of how "smart" the underlying model is. Large general models, evaluated across broad benchmark suites, are argued to suffer a form of "bench maxing" that dilutes focus relative to a model or prompt fine-tuned for one specific task. A narrowly fine-tuned agent can therefore achieve markedly higher pass rates on its single task than a generalist model attempting the same task among many others. DeepSeek V4.1 Flash, deployed solely as a Gmail or warranty-claims agent, is reported to perform this narrow task well and far more cheaply than a large generalist model such as Opus 55. This produces the compressed claim: "A Gmail agent beats a Gmail skill" - small, domain-specific agents compose into larger systems and can themselves be exposed as MCP servers to bigger models.

3.4 Fragmentation and the missing runtime standard

Given these three drivers, organizations are already building large numbers of agents, but implementations fragment across languages, tool choices, and agentic loop designs. Building an agent is argued to mean, in practice, building a harness - handling orchestration, step limits, parallel/async tool execution, durability, and error recovery. Even a pure-MCP approach eventually requires multi-step inference inside MCP tools, which effectively recreates an agent system under a different name. Because custom harnesses are not easily shared, do not necessarily run in others' hosting environments, and do not compose with differently built agents, no organization can feasibly hand-build hundreds of bespoke agents at scale without a shared interoperability layer - motivating a standard specifically for the runtime.

4. Technical Insights

The Standard Agent Specification defines an agent package as: model, system prompt, tools, sub-agents, agent rules, hooks, effects, and thread. Models are pinned to a specific provider, model, and quantization, with optional fallback models permitting escalation to higher intelligence on failure - a design intended to preserve the efficacy benefits of jaggedness rather than permit arbitrary model swapping.

Tools are constrained to exactly three types: a function (TypeScript code), a prompt (lightweight inference delegation, e.g., invoking an image-generation model), or a full sub-agent. Conversations are modeled as inherently two-sided, supporting AI-to-human, AI-to-AI (enabling built-in evaluation and reflection, such as one agent catching another's error), deterministic-code-to-human (a "handler" with no AI involved), or code-to-AI pairings. Sub-agents are complete agents that can be instantiated multiple times from a single definition - for example, one calendar-agent definition powering distinct "work" and "personal" instances. Parent hooks allow a child sub-agent to automatically expose and modify a parent's lifecycle hooks upon installation, enabling composition without manual configuration. Effects are scheduled code triggerable from within a tool call, executing at a future time (e.g., a scheduled email).

Every thread is a sandboxed environment with its own messages, tools, sub-agents, key-value store, and file system, and can execute self-written code under explicit permission scoping ("code mode"), including restricted network access or import lists. The runtime contract specifies abstract behaviors (e.g., threadState.readFile) without dictating implementation; the reference implementation runs on Cloudflare Durable Objects, with the virtual file system backed by a database. The specification is deliberately written entirely in TypeScript, justified on the grounds that it runs across edge, desktop, mobile, and browser environments and, being interpreted rather than compiled, allows agents to author and immediately execute other agents without a build step. Only TypeScript and Rust (or similar systems languages for performance-critical paths) are treated as consequential languages for this purpose.

In the reported demonstration, Claude Code was given a PDF describing a battery warranty process and generated a complete standard agent - prompts, tools, and a pinned DeepSeek V4.1 Flash model with narrowly scoped tools (check battery, offer trade-in, escalate to lead, report safety issue, ship replacement) - in 5 minutes 21 seconds. The admin interface reported full observability (tools called, token counts, cost, request bodies) and a 94% cache hit rate. The same agent was exposed concurrently as a website chatbot and as an MCP server.

5. Discussion

The analysis positions the Standard Agent Specification as addressing a layer of the stack left ungoverned by MCP, A2A, ACP, x402, and skills-based documentation: the runtime itself. This reframes the integration/trust/efficacy argument from a critique of generalist models into an infrastructure gap - organizations are not wrong to want scoped, trustworthy, efficacious agents, but currently lack a shared mechanism for building and distributing them without bespoke, non-portable harness code.

A notable tension is the coexistence of "vendor agnostic" and "coupled to a specific model" as simultaneous design principles. This is resolved by distinguishing the runtime (portable, vendor-agnostic) from the model binding within a given agent instance (pinned for efficacy), suggesting the specification separates where an agent runs from what it is optimized against. This distinction is central but requires further empirical validation beyond a single demonstration and anecdotal production metrics.

The explicit analogy to early browser-standards evolution (Mozilla, JavaScript, subsequent community governance) frames the specification as intentionally unfinished, with success contingent on community stress-testing rather than unilateral design authority.

6. Conclusion

The core contribution is a reframing of agent engineering debates away from model capability and toward runtime portability, composability, and scoping. The Standard Agent Specification and its reference runtime, the Standard Agent Builder, offer a concrete, code-first attempt to standardize the harness layer, complementing rather than replacing existing standards for tools, documentation, and communication. Practically, the findings suggest that teams building domain-specific agents should prioritize scoped tool access and pinned, task-fit models over generalist capability, and evaluate emerging runtime standards for interoperability before investing further in bespoke harness code.

Sources

• Every Company Is Building Agents That Can't Work Together - Justin Schroeder, Standard Agents - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub