How should the Task Domain Boundary be defined and documented?

A Task Domain Boundary has three components. First, the in-scope task specification: the explicit list of task types the agent is designed to handle, defined at the same level of precision as the [T1/T2/T3 classification](https://arcoventure.studio/lexicon/t1-t2-t3) for each task type. Second, the out-of-scope criteria: the conditions under which the agent routes to a different specialist rather than attempting to handle the task itself — these must be as precise as the in-scope specification. Third, the failure protocol: what the agent does when it encounters a task it cannot classify as either in-scope or out-of-scope — the [Deterministic Failure](https://arcoventure.studio/lexicon/deterministic-failure) response rather than an attempted resolution. The Task Domain Boundary is part of the agent’s design document and must be version-controlled alongside the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture) that governs it.

When should an agent be decomposed into multiple specialists?

Three signals indicate decomposition is required. First, the system prompt is long enough to compromise output quality on any specific task class — when the prompt serves multiple domains simultaneously, it serves none of them optimally. Second, the tool set includes tools that are never invoked together — if document extraction tools and email composition tools are never called in the same workflow, they belong to different specialists. Third, the [Escalation Rate](https://arcoventure.studio/lexicon/escalation-rate) differs significantly between task types handled by the same agent — if document extraction escalates at 1% and email composition at 12%, the email composition tasks are being handled by a system optimised for document extraction. Decompose at the point where a task class’s quality requirements can be better served by a dedicated specialist. The cooperation interface design cost is paid once; the output quality improvement compounds across every subsequent invocation.

How does the cooperation interface prevent Context Collision at agent boundaries?

[Context Collision](https://arcoventure.studio/lexicon/context-collision) occurs when two agents operating on different context sets reach contradictory conclusions about the same operational state. The cooperation interface prevents this at the agent boundary by specifying explicitly what information the calling agent provides in its request and what the receiving agent returns in its response — eliminating the ambiguity that produces contradictory outputs. An ambiguous cooperation interface leaves the receiving agent to interpret the request according to its own context, which may differ from the calling agent’s. The cooperation interface schema is the machine-readable equivalent of the [Operational Ontology](https://arcoventure.studio/lexicon/operational-ontology) at the agent-to-agent boundary: the canonical, version-controlled contract that gives the request and response consistent meaning across every invocation, regardless of which calling workflow generated the request. Changes to the interface are tracked using [Deterministic Logging](https://arcoventure.studio/lexicon/deterministic-logging) so that every agent depending on the interface can verify they are operating against the current version.

How does Agent Specialisation relate to the Judgment Layer / Execution Layer separation?

[Agent Specialisation](https://arcoventure.studio/lexicon/agent-specialisation) operationalises the [Judgment Layer / Execution Layer](https://arcoventure.studio/lexicon/judgment-layer-execution-layer) separation at the implementation level. The Execution Layer contains the [T1 and T2 task classes](https://arcoventure.studio/lexicon/t1-t2-t3) that specialist agents handle within their defined Task Domain Boundaries: deterministic tasks executed autonomously, without [Steward](https://arcoventure.studio/lexicon/stewardship-model) involvement, because the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture) correctly specifies what the agent handles and what it escalates. The Judgment Layer contains decisions that exceed any specialist’s Task Domain Boundary and require genuine human assessment. The correct implementation produces a clean separation: when the Task Domain Boundary is precisely defined and the Exception Architecture governs escalation correctly, the Execution Layer expands with every validated exception class reclassified as autonomous, and the Judgment Layer contracts to the genuinely novel conditions no specialist was designed to handle. A system of poorly bounded generalist agents produces the opposite: the Judgment Layer remains large because the Steward must intervene in conditions the agents were never explicitly authorised to handle autonomously.

How does Agent Specialisation affect MTTI and Escalation Rate over time?

A correctly specialised agent system produces falling [Escalation Rate](https://arcoventure.studio/lexicon/escalation-rate) and extending [MTTI](https://arcoventure.studio/lexicon/mtti) over time through two mechanisms. First, a specialist with a precisely defined Task Domain Boundary escalates only the conditions genuinely outside its scope — not because of ambiguity, tool selection errors, or [Context Collision](https://arcoventure.studio/lexicon/context-collision) with adjacent agents. Each exception correctly escalated and encoded into the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture) reduces the Escalation Rate for that class permanently: the specialist handles the condition autonomously on every subsequent occurrence. Second, the cooperation interface eliminates a class of Escalation Rate drivers that generalist systems produce: the incorrect inter-agent handoffs that generate downstream errors requiring [Steward](https://arcoventure.studio/lexicon/stewardship-model) intervention. A specialist that produces stable, schema-conformant output via a versioned cooperation interface is a reliable component in every workflow that invokes it. The MTTI target the [Stewardship Model](https://arcoventure.studio/lexicon/stewardship-model) requires — greater than 72 hours of autonomous operation without human decision — is achievable only in a system where every agent knows precisely what it handles and what it escalates.

The Specialist Doctrine

Agent Specialisation is the architectural practice of designing agents with a narrowly defined task domain, a constrained and explicit capability set, and a formal cooperation interface that enables handoff to other specialised agents when the task exceeds the domain. The market selection argument that established why specialist autonomous businesses outperform diversified incumbents in a Breakable Market applies at the agent design level with equal force. A general-purpose agent asked to execute sales qualification, generate marketing content, resolve customer support tickets, and run financial analysis is optimised for none of them. Its system prompt is a compromise. Its tool set is a superset that adds cost without adding capability at any specific task. Its output on each task class is the intersection of what a generalist can produce rather than what a specialist can produce.

The structural logic is direct: the specialist agent becomes the natural routing target for every workflow that requires its capability. When a business designs an agent with sufficient domain depth — a system calibrated for one task class, with a system prompt optimised for that class, a tool set containing only the tools that class requires, and an output schema every calling workflow depends on — that agent becomes the one all other agents route to when the task arises. The generalist attempts equivalent output across multiple domains and produces adequate results on each. The specialist produces exceptional results on one. In an agentic stack where routing decisions are made automatically, adequate is a temporary position and exceptional is defensible. The question that applies to every agent design decision: what is the one thing this agent does that no other agent in this system does as well?

The spectrum of autonomy and why boundaries matter

Agency exists on a spectrum. At the low level, an agent makes binary choices within a decision tree. At the medium level, it has memory, calls tools, and retries failed tasks. At the high level, it does planning, divides tasks into subtasks, manages a task queue, and coordinates multiple parallel sub-agents across long task horizons. The higher the level of autonomy, the larger the surface area of potential failure — and the more important the Task Domain Boundary becomes as the architectural constraint that prevents a high-autonomy agent from making planning decisions that exceed its competence.

A Task Domain Boundary is the explicit specification of which tasks fall within an agent’s operational scope and which require handoff to another specialised agent. The boundary is not vague but precise: this agent handles inbound support tickets of classification T1a through T1f, as defined in the Exception Architecture — any ticket outside that classification is escalated via the defined cooperation interface. This precision has three architectural consequences. The agent’s system prompt is specific enough to produce consistently high-quality output within the domain. The agent’s tool set includes only the tools its defined domain requires, reducing tool selection ambiguity and Handoff Friction when the agent selects the wrong tool. The agent’s escalation criteria are clear enough that Context Collision at the agent-to-agent boundary is prevented: the cooperation interface specifies exactly what the receiving agent inherits and in what format.

This precision operationalises the Judgment Layer / Execution Layer separation at the implementation level. The Execution Layer contains the task classes specialist agents handle within their defined Task Domain Boundaries. The Judgment Layer contains decisions that exceed any specialist’s scope and escalate to the Steward. A well-bounded specialist expands the Execution Layer with every validated exception class reclassified as autonomous. A poorly bounded generalist keeps the Judgment Layer large because the Steward cannot trust an agent that was never given explicit limits to stay within them.

The cooperation interface — what makes specialists composable

Agent Specialisation without a cooperation interface produces isolated specialists that cannot compose into a system. The cooperation interface is the defined protocol by which one specialised agent invokes another with a structured request and receives a structured response. A sales intelligence agent that composes its answers from specialist sub-agents illustrates this at production scale: the intelligence agent routes sub-tasks to a data analysis specialist, a transcript retrieval specialist, and a knowledge retrieval specialist — each executing within its defined Task Domain Boundary and returning a structured response via its cooperation interface. The intelligence agent assembles the complete answer without any specialist needing to understand how the others work. The cooperation interface between each pair — the structured request and response schema — is what makes the system composable without requiring centralised orchestration.

The cooperation interface must be specified as part of the agent design document, not as an afterthought when integration is required. The same discipline the Operational Ontology applies to vocabulary applies here to the agent’s interaction contract: the input schema and output schema must be explicitly defined, canonical, and version-controlled using Deterministic Logging so that changes to one agent’s interface are visible to every agent that depends on it. An ambiguous cooperation interface produces Context Collision at the agent boundary — the calling agent sends a request the receiving agent cannot interpret correctly, and both produce contradictory outputs based on different interpretations of the same request.

The Arco Flywheel at the agent level

The Arco Flywheel operates at the portfolio level: each business Arco builds generates reusable infrastructure that makes the next build faster. Agent Specialisation creates the same flywheel at the agent level: each well-defined specialist can be reused across every workflow that requires its capability, without modification, because its Task Domain Boundary is explicit and its cooperation interface is stable. A document extraction specialist designed for the customer onboarding workflow can be invoked by the compliance workflow, the contract analysis workflow, and the financial reporting workflow — because all three need document extraction, and the specialist’s output schema is stable across all invocations.

A specialist invoked across many workflows accumulates operational experience from every invocation: which inputs it receives, which outputs satisfy each calling workflow’s Quality Threshold, which edge cases its cooperation interface must handle. The reuse compounds: the same design investment that produced the specialist for the first workflow produces it for every subsequent workflow that needs the same capability, at zero additional design cost. The specialist invoked by ten workflows compounds faster than the specialist invoked by one — both in output quality improvement and in the operational signal its executions generate for the Stewardship Model to govern.

The Operator’s Verdict

An agent without a clear Task Domain Boundary is a generalist waiting to be replaced by the specialist that defines one. The Agent Specialisation that makes an agent composable, reusable, and economically defensible is a design decision made before the first deployment — not a refactoring applied after the Escalation Rate reveals that the generalist configuration cannot be trusted to stay within limits it was never explicitly given.

Technology changes what agents can do. Specialisation determines what they do exceptionally.

KEY TAKEAWAY

What is Agent Specialisation and why does the agentic landscape structurally reward it?

Agent Specialisation is the architectural practice of designing agents with a narrowly defined Task Domain Boundary, a constrained capability set, and a formal cooperation interface that enables handoff to other specialised agents when the task exceeds the domain. The agentic landscape rewards specialists for the same structural reason the business landscape rewards specialist autonomous companies in Breakable Markets: a system optimised for one task class at high volume produces a structural quality advantage that a general-purpose system cannot replicate. A general-purpose agent’s system prompt is a compromise across all task classes it serves; a specialist’s is optimised for exactly one. A general-purpose agent’s tool set is a superset that adds ambiguity at tool selection time; a specialist’s contains exactly the tools its domain requires. A general-purpose agent that produces adequate output across many task classes will be replaced by the specialist that produces exceptional output on any one of them. The specialist that produces exceptional output on one task class becomes the natural routing target for every workflow that needs it — and in an agentic stack where routing decisions are automatic, exceptional is defensible and adequate is not. Key metric: a well-defined specialist agent can be reused across every workflow that requires its capability without modification — the cooperation interface design cost is paid once, and the output quality advantage compounds across every subsequent invocation at zero additional design cost.