AI Engineer · Published 2026-06-29

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

Open on YouTube ↗

Summary

Overview

  • Speaker: Justin Schroeder
  • Channel: AI Engineer
  • Main topic: Domain-Specific AI Agents and Multi-Agent Orchestration
  • Purpose: To explain why domain-specific agents are the future of AI engineering, detail the agent tech stack (from models to MCP and skills), contrast inheritance with composition in agent design, and predict the rise of multi-agent orchestration by 2027. Justin Schroeder argues that the future of AI building and usage lies in domain-specific agents rather than monolithic general-purpose models. He defines agents as deterministic software harnessing non-deterministic model results, explains the challenges of current agent engineering, and introduces a stack based on composition, Model Context Protocol (MCP), agent skills, and multi-agent coordination mimicking historical engineering milestones like the Apollo program.

Topic Map

Industrial Revolution to Agential Era Analogy

  • Explanation: Drawing parallels between the industrial revolution (harnessing energy with machines) and the AI era (harnessing intelligence with agents).
  • Key claims:
    • We are in an accelerated industrial revolution for intelligence.
    • Agents are the machines of the agential era that will use intelligence.
  • Examples:
    • Harnessing energy with machines vs. harnessing intelligence with agents.
  • Terminology:
    • agential era
    • industrial revolution
  • Why it matters: Frames the current shift in AI engineering as a fundamental technological paradigm change.

Definition of an Agent

  • Explanation: Providing a precise software engineering definition for what constitutes an agent.
  • Key claims:
    • Agents are deterministic software that harnesses the non-deterministic results produced by models in pursuit of a desired objective.
  • Examples:
    • Distinction between a model, a harness, and an agent.
  • Terminology:
    • deterministic software
    • non-deterministic results
    • harness
  • Why it matters: Establishes a baseline technical definition amidst industry confusion.

The Mess of Building Agents Today

  • Explanation: Highlighting the practical difficulties engineering teams face when building custom agents.
  • Key claims:
    • Everyone is building agents, but building robust agents is hard.
    • There is no defined way to build an agent, leading to high friction in telemetry, portability, and composability.
  • Examples:
    • Real estate agencies and insurance brokers building custom agents.
    • Vercel's 'eve' framework as an emerging standard.
  • Terminology:
    • agentic loop orchestration
    • provider abstraction
    • durable execution
    • telemetry/observability
    • portability
    • composability
  • Why it matters: Explains why building agents currently feels like a nightmare for IT departments.

Model Context Protocol (MCP) and Agent Skills

  • Explanation: Evaluating existing integration mechanisms like MCP and Markdown-based agent skills.
  • Key claims:
    • MCP has become a de facto tool distribution mechanism for agents, but tools and documentation alone are not enough to land complex projects.
    • Using too many agent skills can degrade agent performance.
  • Examples:
    • Connecting corporate information (Zillow, American Airlines) to large general-purpose agents via MCP.
    • Markdown skill files acting as documentation.
  • Terminology:
    • Model Context Protocol (MCP)
    • agent skills
    • tool distribution
  • Why it matters: Shows the limitations of treating tools and documentation as the sole solution for agent capability.

Composition over Inheritance in Agent Design

  • Explanation: Comparing inheritance-based agent stacks with composition-based agent stacks.
  • Key claims:
    • Inheritance in agents (adding endless MCPs and skills to one monolithic agent) breaks down due to diminishing returns on context.
    • Composition (combining specialized sub-agents via a coordinator) is the superior architectural pattern.
  • Examples:
    • Adding 100+ skills to Claude vs. composing specialized sub-agents for Figma, Gmail, Kayak, and Navan.
  • Terminology:
    • inheritance
    • composition
    • context layer
    • sub-agent
  • Why it matters: Provides a clear architectural blueprint for scaling agent systems effectively.

Advantages of Domain-Specific Agents

  • Explanation: Listing the core benefits of targeting agents to very specific domains.
  • Key claims:
    • Domain-specific agents are far more token-efficient (80%+ savings) and make small language models (SLMs) practical.
    • They enforce strict capability limits, have excellent scaling characteristics, and reduce costs significantly.
  • Examples:
    • DeepSeek v4 flash vs. Fable cost comparisons.
  • Terminology:
    • token efficiency
    • small language models (SLMs)
    • scaling characteristics
    • capability limits
  • Why it matters: Demonstrates why domain-specific agents solve the token cost and safety crises of modern AI deployment.

The Ideal Agent Stack

  • Explanation: Breaking down the exact architectural layers of an ideal domain-specific agent.
  • Key claims:
    • An ideal agent stack includes a model, system prompt, tools (functions, prompts, sub-agents), hooks, agent rules, a sandbox filesystem, and code execution capabilities.
  • Examples:
    • Salesforce agent talking to a Google Workspace agent and an Asset Generation agent under a coordination agent.
  • Terminology:
    • system prompt
    • hooks
    • agent rules
    • filesystem
    • code execution
    • recursive sub-agency
  • Why it matters: Provides developers with a concrete design pattern to build production-grade agent architectures.

Key Points

Agents are deterministic software wrapped around non-deterministic models

  • Explanation: The orchestration logic, loop control, and safety guardrails are code-driven, while the reasoning steps rely on probabilistic AI models.
  • Evidence: Justin Schroeder's formal definition slide.
  • Practical implication: Developers must focus on robust software engineering around the model rather than treating the model as the entire application.

Token costs are rising, not falling, when accounting for intelligence needs

  • Explanation: Even though raw token prices drop, the token count required per task is increasing rapidly due to context bloat and lack of efficiency.
  • Evidence: Standard Agents tracking data showing token costs up 29% to 76% in 2026.
  • Practical implication: Domain-specific agents are required to restrict context windows and drastically improve token efficiency.

Composition beats inheritance in agent scaling

  • Explanation: Overloading a single agent with every tool and skill causes context degradation and high token costs. Orchestrating small, specialized agents via natural language coordination is far more effective.
  • Evidence: Analogy to software engineering principles (composition over inheritance) and multi-agent workflow diagrams.
  • Practical implication: Build modular sub-agents for specific tasks (e.g., Figma, Gmail, legal compliance) rather than one giant monolithic assistant.

Frameworks, Models & Processes

The Ideal Domain-Specific Agent Stack

  • How it works: Layers modular components from low-level execution up to high-level governance rules.
  • Components:
    • Model (LLM or SLM)
    • System Prompt (life objective)
    • Tools (functions, prompts, sub-agents)
    • Hooks (side-effects and state injection)
    • Agent Rules (turn limits and validation)
    • Sandbox Filesystem & Code Execution (native primitive)
  • When to use: When building production-ready, scalable, multi-agent enterprise systems.

Examples & Case Studies

Comparing the moon landing control room to modern AI agent systems.

  • Illustrates: Multi-agent orchestration and division of labor.
  • Lesson: Just as Apollo 11 succeeded through specialized teams of experts with specific tools and narrow communication channels, AI systems succeed through coordinated domain-specific sub-agents.

Actionable Takeaways

  • Immediate:
    • Stop building monolithic general-purpose agents.
    • Adopt composition over inheritance when designing agent capabilities.
    • Incorporate sandbox filesystems and code execution as core agent primitives.
  • Strategic:
    • Prepare for the rise of multi-agent orchestration by 2027.
    • Leverage small language models (SLMs) with domain-specific agents to achieve 80%+ token efficiency and dramatic cost reductions.
    • Focus engineering efforts on agent telemetry, durability, and loop orchestration.
  • Questions to investigate:
    • How do we standardize agent portability across different runtime environments?
    • What are the best frameworks for managing recursive sub-agent turn coordination?
    • How can telemetry and observability be effectively implemented at scale for multi-agent loops?

Claims Worth Verifying

  • Token costs per intelligence point are up 29% to 76% in 2026 (market statistic)
  • Domain-specific agents achieve over 80% token efficiency compared to general agents (technical benchmark claim)

Notable Quotes

"Agents are deterministic software that harnesses the non-deterministic results produced by models in pursuit of a desired objective." (at 3:45) "Composition over inheritance." (at 20:56) "We didn't land a man on the moon by giving one guy a ton of tools." (at 15:00)

Compressed Summary

  • Domain-specific agents solve the token cost and context bloat crisis of modern AI.
  • Composition over inheritance: modular sub-agents outperform monolithic general assistants.
  • The ideal agent stack features sandboxed filesystems, code execution, hooks, and natural language multi-agent coordination.
  • 2027 will be the year of multi-agent orchestration.
  • Keywords: domain-specific agents, multi-agent orchestration, model context protocol, agent stack, token efficiency
  • Core insight: Monolithic general-purpose agents fail at scale due to token costs and context degradation; the future belongs to composed ecosystems of domain-specific sub-agents communicating via natural language.

Core insights

6
Mental Modelmedium noveltystrong evidence

Agents should be defined as deterministic software that harnesses non-deterministic model output — orchestration logic, loop control, and guardrails are code, while only reasoning steps are probabilistic. This makes the 'harness' a first-class engineering artifact separate from the model.

Why it matters

It relocates engineering effort from prompt/model tuning to the software layer (control flow, guardrails, safety) that most teams underinvest in, and gives a concrete boundary for what is and is not an 'agent'.

Generalization

Any system embedding a probabilistic component should treat the probabilistic part as a bounded service inside deterministic code, not as the application itself.

Agents are deterministic software that harnesses the non-deterministic results produced by models in pursuit of a desired objective.
Open source video
The orchestration logic, loop control, and safety guardrails are code-driven, while the reasoning steps rely on probabilistic AI models.
Open source video
Architecturemedium noveltymoderate evidence

Scaling a single agent by stacking MCP servers and skills exhibits diminishing returns on context; the composition pattern — a coordinator dispatching to narrow sub-agents (e.g., Figma, Gmail, Kayak, Navan) — is claimed to be the superior architecture. This is inheritance-vs-composition from OO design re-applied to agent capability accumulation.

Why it matters

It defines where capability boundaries belong: not inside one context window, but between agents. This changes how teams decompose tools, prompts, and permissions.

Generalization

Capability growth via accumulated context scales sublinearly; capability growth via decomposition into independently-scoped components scales better wherever context is a scarce resource.

Inheritance in agents (adding endless MCPs and skills to one monolithic agent) breaks down due to diminishing returns on context.
Open source video
Adding 100+ skills to Claude vs. composing specialized sub-agents for Figma, Gmail, Kayak, and Navan.
Open source video
Empirical Resulthigh noveltymoderate evidence

Despite falling raw token prices, per-task token cost is rising because required context per task is inflating — the speaker cites tracking data showing token costs up 29% to 76% in 2026. Cheaper tokens do not mean cheaper agents.

Why it matters

It inverts the common cost-model assumption that model price declines automatically improve unit economics, and makes context discipline (not model choice) the primary cost lever.

Generalization

When a resource gets cheaper per unit but consumption per unit of work rises faster, total cost rises; optimizations must target consumption, not unit price.

Even though raw token prices drop, the token count required per task is increasing rapidly due to context bloat and lack of efficiency.
Open source video
Standard Agents tracking data showing token costs up 29% to 76% in 2026.
Open source video
Mechanismhigh noveltymoderate evidence

Narrowing agent scope yields roughly 80%+ token savings, makes small language models (SLMs) practical, and enforces strict capability limits — a single mechanism that simultaneously improves cost, feasibility of cheaper models, and safety posture.

Why it matters

Domain scoping is presented as a coupled solution to the cost crisis and the safety/capability-control problem, rather than a product-naming choice. It also creates a viable path to SLM deployment.

Generalization

Restricting an agent's operating domain reduces context requirements, which lowers cost and simultaneously raises the viability of smaller/cheaper models for that domain.

Domain-specific agents are far more token-efficient (80%+ savings) and make small language models (SLMs) practical.
Open source video
They enforce strict capability limits, have excellent scaling characteristics, and reduce costs significantly.
Open source video
Failure Modemedium noveltymoderate evidence

MCP has become a de facto tool-distribution mechanism, but tools plus markdown documentation are insufficient to complete complex projects, and overloading an agent with skills actively degrades its performance. Integration surface is not capability.

Why it matters

It warns against treating MCP server count or skill count as a capability metric, and identifies skills as a context-polluting resource with a degradation threshold.

Generalization

Adding declarative capability descriptions consumes the same scarce context budget as task content; capability registries need their own scaling and selection strategy (e.g., retrieval/routing) rather than unconditional loading.

MCP has become a de facto tool distribution mechanism for agents, but tools and documentation alone are not enough to land complex projects.
Open source video
Using too many agent skills can degrade agent performance.
Open source video
Architecturemedium noveltymoderate evidence

An ideal domain-specific agent stack is enumerated as: model, system prompt, tools (functions, prompts, and sub-agents), hooks, agent rules, a sandbox filesystem, and code execution — with sub-agents as a tool type enabling recursive sub-agency under a coordinator.

Why it matters

It gives a concrete layer list in which sub-agents are unified with tools as a single abstraction, and where hooks/rules and a sandbox filesystem sit relative to the model — useful as a checklist for production agent design.

Generalization

Treating an agent as a uniform 'callable tool' makes recursive composition the default scaling mechanism for hierarchical agent systems.

An ideal agent stack includes a model, system prompt, tools (functions, prompts, sub-agents), hooks, agent rules, a sandbox filesystem, and code execution capabilities.
Open source video
Salesforce agent talking to a Google Workspace agent and an Asset Generation agent under a coordination agent.
Open source video

Deep dives

5

Sub-agent granularity: measuring composition over inheritance

Research question

For a fixed multi-tool task, what sub-agent granularity minimizes tokens per successful task, and how does task-failure attribution change as tools move from one shared context window into independently-scoped sub-agents?

Why

The composition claim is asserted with an analogy (Figma, Gmail, Kayak, Navan) but no boundary rule or benchmark. Without a measured granularity curve, teams decomposing agents are guessing, and coordination cost may silently eat the context savings.

Inheritance in agents (adding endless MCPs and skills to one monolithic agent) breaks down due to diminishing returns on context.
Open source video
Adding 100+ skills to Claude vs. composing specialized sub-agents for Figma, Gmail, Kayak, and Navan.
Open source video
Source video

Skill-count degradation mechanism and the routing fix

Research question

Is agent performance degradation with skill count monotonic, and is the cause context dilution, tool-selection ambiguity, or conflicting instructions — and does retrieval/routing over the skill registry remove the degradation?

Why

Skill degradation is treated as context pollution but the mechanism is unstated, so teams cannot decide whether to cap skills, summarize them, or retrieve them. This determines whether an agent skill library can scale at all.

Using too many agent skills can degrade agent performance.
Open source video
MCP has become a de facto tool distribution mechanism for agents, but tools and documentation alone are not enough to land complex projects.
Open source video
Source video

Separating scope restriction from model choice in the token-savings claim

Research question

How much of the reported 80%+ token savings from domain-specific agents is attributable to narrowed scope versus model choice, when model and scope are independently ablated on the same task set?

Why

The savings figure and the SLM practicality claim are stated together, so teams cannot tell whether narrowing scope makes small models viable or whether a small model was doing the saving. This determines the order of operations for cost work.

Domain-specific agents are far more token-efficient (80%+ savings) and make small language models (SLMs) practical.
Open source video
They enforce strict capability limits, have excellent scaling characteristics, and reduce costs significantly.
Open source video
Source video

Cost model for recursive sub-agency at increasing depth

Research question

In a coordinator/sub-agent topology, how do token consumption, latency, and error propagation scale from depth 1 to depth 3, and at what depth does marginal task success stop justifying marginal cost?

Why

Sub-agents represented as tools make recursion the default scaling mechanism, but nesting adds overhead and makes it ambiguous where hooks, rules, and context limits apply. A depth ceiling or budget rule is needed before this becomes a production default.

An ideal agent stack includes a model, system prompt, tools (functions, prompts, sub-agents), hooks, agent rules, a sandbox filesystem, and code execution capabilities.
Open source video
Salesforce agent talking to a Google Workspace agent and an Asset Generation agent under a coordination agent.
Open source video
recursive sub-agency
Open source video
Source video

Interface checklist for the missing agent standard

Research question

Which concrete interfaces (loop control, provider abstraction, durable execution, telemetry, composability) must a framework define for agents to be portable, and how do current candidates score against that checklist on the same agent?

Why

High friction in telemetry, portability, and composability is named as the core pain, and 'eve' is cited as an emerging standard without defined interfaces. Turning this into a checklist converts an opinion into a testable portability target.

There is no defined way to build an agent, leading to high friction in telemetry, portability, and composability.
Open source video
Vercel's 'eve' framework as an emerging standard.
Open source video
Source video

Article ideas

4

Cheaper Tokens, More Expensive Agents

Falling per-token prices are a distraction from the real cost lever: per-task context consumption is inflating faster than unit prices are falling, so agent cost work must target consumption — tool schemas, skill documentation, and history — not model selection.

Angle

Invert the standard cost-model assumption and show where the token budget actually goes per task, with the 29%–76% per-task cost increase as the counterexample to 'prices are dropping'.

Source video

Composition Over Inheritance Is the Real Agent Architecture Decision

Accumulating MCP servers and skills inside one context window is inheritance, and it fails for the same reason deep inheritance hierarchies fail: coupling. Capability boundaries belong between agents, not inside one prompt, and decomposition is the only scalable path.

Angle

Re-apply the OO inheritance-vs-composition argument to agent capability accumulation, using the monolithic-agent vs. coordinator-plus-sub-agents contrast as the case study.

Source video

Integration Surface Is Not Capability

MCP server count and skill count are being used as capability metrics, but declarative capability descriptions consume the same scarce context as task content and degrade performance past a threshold — capability registries need selection and routing strategies, not unconditional loading.

Angle

Attack the MCP-servers-as-progress-metric mindset and describe skill registration as a context budget problem with a degradation curve.

Source video

The Harness Is the Artifact

Treating the model as the application is the core engineering mistake; the durable, testable artifact is the deterministic harness — loop control, guardrails, hooks, and rules — that wraps bounded probabilistic calls, which is where portability, telemetry, and durability become design surfaces.

Angle

Take the speaker's agent definition literally and unpack what becomes code versus what stays probabilistic, and what that implies for testing and provider swapping.

Source video

Project ideas

4

Granularity Bench

beyond-evals

For a fixed multi-tool task set, a coordinator dispatching to 3–4 narrow sub-agents achieves at least 50% fewer tokens per successful task than a single agent with every tool loaded into one context, at equal or better task success.

Proof of concept

Implement both topologies against the same task suite with the same tool set (Figma, Gmail, Kayak, Navan), a shared model, and identical prompts-per-tool; run N trials per task and instrument token accounting per agent boundary.

Measurement

Tokens per successful task, task success rate, latency, and per-failure attribution (which agent boundary failed) for monolithic vs. composed topologies.

Source video

Skill Degradation Curve

beyond-evals

Tool-selection accuracy degrades monotonically past a measurable skill count, and replacing unconditional skill loading with retrieval-based skill routing removes the degradation at equal task success.

Proof of concept

Incrementally inject 1 to 100 skill definitions into a fixed agent, probing tool-selection accuracy and instruction-following at each step; then swap in a retrieval router over the same registry and repeat the sweep.

Measurement

Tool-selection accuracy and instruction-following score as a function of injected skill count, with and without retrieval routing; identify the degradation knee.

Source video

Context Cost Attribution Gateway

gatehouse

Most per-task token growth is context payload (tool schemas, skill documentation, accumulated history) rather than reasoning tokens, so enforcing a per-request context budget at the gateway cuts cost per task by 30%+ at parity task success.

Proof of concept

Instrument an agent's outbound calls to segment every request into tool-schema tokens, skill-documentation tokens, history tokens, and reasoning tokens; add a gateway policy that caps and summarizes the injectable segments only.

Measurement

Token breakdown by segment per task and cost per task before and after the gateway policy, plus task success rate to confirm parity.

Source video

Sub-Agent Depth Meter

new

Coordinator/sub-agent nesting beyond depth 2 yields sublinear task-success gains while producing superlinear token and latency cost, and error propagation across boundaries amplifies with each added level.

Proof of concept

Build one coordinator with specialized sub-agents callable as tools, then run the same task set at nesting depths 1, 2, and 3 with identical sub-agent implementations and injected failures at each boundary.

Measurement

Tokens, latency, task success, and error-propagation rate (failures traceable to a nested boundary) as a function of nesting depth.

Source video

Architectural implications

3

The unit of capability becomes the sub-agent boundary rather than the tool/skill slot on a single agent.

Before

One general-purpose agent accumulating MCP servers and skills in a shared context window.

After

A coordinator agent routing to narrow sub-agents (Figma, Gmail, Kayak, Navan, Salesforce, Google Workspace, Asset Generation).

Consequence

Context per agent shrinks; permissions and capability limits become enforceable per sub-agent; tool registries must be scoped rather than global.

Source video

The model, harness, and agent are separated as distinct artifacts.

Before

The model is treated as the application, with orchestration implicit in prompts.

After

Deterministic orchestration code (loop control, guardrails, hooks, rules) wraps non-deterministic model calls.

Consequence

Portability, telemetry, and durable execution become harness concerns with their own design surface, and provider abstraction can live below the agent.

Source video

Sub-agents are represented as a tool type in the stack, alongside functions and prompts.

Before

Tools are external functions; agents are top-level constructs.

After

Sub-agents callable as tools, enabling recursion under a coordinator.

Consequence

Uniform call interface simplifies orchestration but raises questions about depth limits, cost accounting, and failure propagation across nested agents.

Source video

Tradeoffs and failure modes

4

Skill and MCP accumulation

Benefit

Broad capability coverage from a single agent configuration and a standardized tool-distribution channel.

Cost or risk

Diminishing returns on context and measurable performance degradation as skills multiply.

Using too many agent skills can degrade agent performance.
Open source video
Source video

Cheap raw tokens vs. total task cost

Benefit

Falling per-token prices make larger models economically accessible.

Cost or risk

Token count per task is rising due to context bloat, so total cost rises 29% to 76% despite price declines.

Even though raw token prices drop, the token count required per task is increasing rapidly due to context bloat and lack of efficiency.
Open source video
Source video

Domain-narrow agents vs. general-purpose agents

Benefit

80%+ token savings, strict capability limits, better scaling, and practical use of small language models.

Cost or risk

Requires decomposition into many specialized agents, shifting complexity into coordination and requiring a working multi-agent orchestration layer that the speaker says does not yet exist as a standard.

There is no defined way to build an agent, leading to high friction in telemetry, portability, and composability.
Open source video
Source video

Recursive sub-agency

Benefit

Composable, reusable specialized agents callable as tools under a coordinator.

Cost or risk

Nested coordination layers add token and latency overhead and create ambiguity about where context, hooks, and rule enforcement apply.

recursive sub-agency
Open source video
Source video

Open questions

5

What is the correct granularity for sub-agent boundaries, and how is it measured rather than asserted?

Why unresolved

The summary provides an analogy (Figma, Gmail, Kayak, Navan) and a principle (composition over inheritance) but no boundary-definition rule or benchmark comparing decomposition choices.

Research direction

Build a benchmark that varies sub-agent granularity on a fixed multi-tool task and measure token cost, task success, and failure attribution.

Source video

How much of the 80%+ token savings from domain-specific agents is attributable to scope restriction versus model choice?

Why unresolved

The summary states savings and SLM practicality together but does not separate the contributions or describe the measurement setup.

Research direction

Ablation study holding model constant while varying domain scope, then holding scope constant while varying model size.

Source video

What causes skill-count performance degradation — context dilution, retrieval confusion, or conflicting instructions?

Why unresolved

The summary reports the degradation without a mechanism, and distinguishes tools/distribution from the problem of 'landing complex projects'.

Research direction

Controlled experiments adding skills incrementally and probing tool-selection accuracy and instruction-following at each step.

Source video

Does recursive sub-agency remain cost-effective as depth increases, given rising per-task token consumption?

Why unresolved

The stack listing includes recursive sub-agency and sub-agents as tools, but no cost or reliability data for nested orchestration is presented.

Research direction

Measure token, latency, and error-propagation behavior across nesting depths 1–3 in a coordinator/sub-agent topology.

Source video

What does standardizing agent telemetry, portability, durable execution, and composability actually require, and is Vercel's 'eve' a candidate standard?

Why unresolved

The summary names these as friction points and cites 'eve' as an emerging standard without defining the interfaces.

Research direction

Compare proposed agent frameworks on a common interface checklist for loop control, provider abstraction, durability, and observability.

Source video

Key claims

8
opinionVerification not requested

An agent is deterministic software that harnesses non-deterministic model results toward an objective.

Evidence

Agents are deterministic software that harnesses the non-deterministic results produced by models in pursuit of a desired objective.

Source video
causalVerification needed

Adding endless MCPs and skills to one monolithic agent breaks down because of diminishing returns on context.

Evidence

Inheritance in agents (adding endless MCPs and skills to one monolithic agent) breaks down due to diminishing returns on context.

Question

At what skill/tool count does measurable performance degradation begin, and is the cause context length, retrieval ambiguity, or instruction conflict?

Source video
factualVerification needed

Per-task token costs rose 29% to 76% in 2026 even as raw token prices dropped.

Evidence

Standard Agents tracking data showing token costs up 29% to 76% in 2026.

Question

What was the measurement set, task distribution, and baseline period behind the 29%–76% range?

Source video
comparativeVerification needed

Domain-specific agents deliver 80%+ token savings and make small language models practical.

Evidence

Domain-specific agents are far more token-efficient (80%+ savings) and make small language models (SLMs) practical.

Question

Relative to what baseline, on which tasks, and with what task-success trade-off were the 80%+ savings measured?

Source video
opinionVerification not requested

MCP has become a de facto tool distribution mechanism for agents, but tools and documentation alone are insufficient for complex projects.

Evidence

MCP has become a de facto tool distribution mechanism for agents, but tools and documentation alone are not enough to land complex projects.

Source video
causalVerification needed

Using too many agent skills can degrade agent performance.

Evidence

Using too many agent skills can degrade agent performance.

Question

Is degradation monotonic in skill count, and does skill routing/retrieval eliminate the effect?

Source video
predictionVerification needed

Multi-agent orchestration will rise as the dominant pattern by 2027.

Evidence

predict the rise of multi-agent orchestration by 2027

Question

What adoption or cost metrics would confirm or falsify a 2027 inflection toward multi-agent orchestration?

Source video
opinionVerification not requested

There is no defined way to build an agent, producing high friction in telemetry, portability, and composability.

Evidence

There is no defined way to build an agent, leading to high friction in telemetry, portability, and composability.

Source video

Connections

4