Empirica Agent Economy Series — Course Lesson Format: Markdown Report | Audience: All age groups

Executive Summary

Multi-agent systems (MAS) distribute complex tasks across networks of specialised subagents, each optimised for a narrow capability domain. This architecture creates emergent economic structures: capability markets where agents bid for tasks, and delegation hierarchies where orchestrators allocate work based on cost, latency, and quality signals.

The core economic insight is that specialisation generates surplus. A subagent trained or fine-tuned for a specific task completes it faster, cheaper, and more accurately than a generalist — mirroring comparative advantage in human trade theory. Orchestrating agents exploit this surplus through delegation, capturing the difference between the value of task completion and the cost of outsourcing it.

This lesson covers: - How specialisation and delegation function as economic mechanisms - The structure of capability markets and how prices form - Cost-benefit frameworks for delegation decisions - Age-appropriate learning paths from foundational to advanced - Practical implementation patterns for real systems

Core Concepts: Specialisation and Delegation

What Is a Specialised Subagent?

A specialised subagent is an autonomous computational unit optimised for a defined capability class. Specialisation can occur along several axes:

Axis Example
Domain knowledge Legal document parsing, medical coding, financial modelling
Modality Vision, audio transcription, code execution
Latency profile Real-time response vs. batch processing
Cost tier Cheap high-volume inference vs. expensive high-accuracy inference
Tool access Web search, database query, API calls

Specialisation is not binary. Agents exist on a spectrum from narrow (single-task) to broad (multi-domain), and the optimal specialisation level depends on task distribution in the environment the agent operates in.

Delegation as an Economic Act

Delegation is the transfer of a task from an orchestrating agent to a subagent, accompanied by:

  1. A specification — what the task requires (inputs, outputs, quality constraints)
  2. A payment or credit transfer — compensation for compute, API costs, and capability premium
  3. A trust signal — the orchestrator's confidence that the subagent will complete the task correctly

Delegation is economically rational when:

Value(task completion) − Cost(delegation) > Value(self-completion) − Cost(self-execution)

This inequality drives the entire architecture of multi-agent systems. When it holds, delegation creates value. When it fails — due to coordination overhead, trust failures, or subagent underperformance — centralised execution dominates.

The Principal-Agent Problem in MAS

Every delegation relationship instantiates a principal-agent problem:

  • The principal (orchestrator) wants the task done correctly and cheaply
  • The agent (subagent) has its own cost structure and may have misaligned incentives

In human organisations, this is managed through contracts, monitoring, and reputation. In MAS, the analogues are: - Verifiable outputs (the orchestrator checks the result before paying) - Reputation scores (historical performance tracked on-chain or in shared registries) - Escrow and conditional payment (payment released only on verified completion)

Capability Markets: Structure and Dynamics

Market Architecture

A capability market is a mechanism through which agents with tasks find agents with the relevant capabilities, and prices are determined. Three structural models exist:

1. Centralised Marketplace A registry or broker maintains a catalogue of available subagents, their capability descriptions, pricing, and performance history. Orchestrators query the registry and select subagents. Simple to implement; creates a single point of failure and potential monopoly rents for the registry operator.

2. Peer-to-Peer Discovery Agents advertise capabilities via broadcast or gossip protocols. Orchestrators discover subagents directly. Resilient and decentralised; discovery overhead is high and quality signals are harder to aggregate.

3. Auction-Based Allocation Tasks are posted as open requests. Subagents bid on tasks based on their cost structure and current load. The orchestrator selects the winning bid using a scoring function that weights price, quality, and latency. Efficient price discovery; adds latency to task initiation.

Price Formation

Capability prices in a functioning market reflect:

  • Marginal compute cost — the direct inference or execution cost per task
  • Scarcity premium — when a capability is rare, price rises above marginal cost
  • Quality premium — higher accuracy commands higher prices when outputs are verifiable
  • Latency premium — real-time capabilities command premiums over batch equivalents
  • Reputation premium — subagents with strong track records charge above commodity rates

Price signals in capability markets perform the same function as prices in any market: they aggregate dispersed information about supply, demand, and quality, and direct tasks toward the most efficient provider.

Market Failure Modes

Failure Mode Mechanism Mitigation
Information asymmetry Subagent knows its true quality; orchestrator does not Verifiable output proofs, reputation systems
Adverse selection Low-quality agents undercut on price, driving out high-quality agents Minimum quality thresholds, credentialing
Monopoly on rare capabilities Single provider of a scarce capability extracts maximum rent Open-source capability development, capability replication incentives
Coordination failure Agents cannot find each other efficiently Standardised capability description schemas
Sybil attacks Malicious agents create fake reputation Stake-based reputation, cryptographic identity

Delegation Economics: Cost-Benefit Analysis

The Full Cost of Delegation

Naive delegation analysis counts only the subagent's fee. Full cost accounting includes:

Total Delegation Cost =
  Subagent fee
  + Specification cost (tokens to describe the task)
  + Coordination latency cost (time waiting for result)
  + Verification cost (tokens/compute to check output)
  + Error cost × P(error) (expected cost of subagent failure)
  + Retry cost × P(retry needed)

Each term matters. For high-volume, low-value tasks, specification and verification costs can exceed the subagent fee. For high-stakes tasks, error cost dominates.

The Make-or-Buy Decision

Every orchestrator faces a continuous make-or-buy decision: execute internally or delegate. The decision framework:

Delegate when: - The subagent's specialisation advantage is large (quality or speed gain > coordination overhead) - The task is well-specified (low specification cost) - The output is easily verifiable (low verification cost) - The subagent has a strong reputation (low expected error cost) - The orchestrator's own compute is constrained or expensive

Execute internally when: - The task requires tight integration with internal state - Specification is ambiguous or expensive to formalise - Verification is difficult or impossible - The capability gap between orchestrator and subagent is small - Latency requirements preclude round-trip delegation

Delegation Depth and Hierarchy

Delegation can be recursive. An orchestrator delegates to a subagent, which itself delegates subtasks to further subagents. This creates a delegation tree with economic implications:

  • Each layer adds overhead — coordination costs compound
  • Each layer adds latency — sequential delegation chains are slow
  • Each layer adds failure probability — errors propagate upward
  • Each layer can add value — if each subagent genuinely specialises, the surplus at each layer justifies the overhead

Research in distributed systems suggests that effective delegation hierarchies rarely exceed three to four layers before coordination costs consume the specialisation surplus. Flat, wide hierarchies (one orchestrator, many parallel subagents) outperform deep chains for most task types.

Pricing Strategies for Subagents

Subagents operating in a capability market must set prices. Three strategies:

Cost-plus pricing: Set price = marginal cost + fixed markup. Simple; leaves surplus on the table when demand is high.

Value-based pricing: Set price as a fraction of the value the orchestrator captures from task completion. Requires estimating orchestrator surplus; maximises revenue when feasible.

Dynamic pricing: Adjust price based on current load, queue depth, and competitor pricing. Maximises utilisation and revenue; requires real-time market signals.

Age-Grouped Learning Paths

🟢 Ages 10–14: The Robot Team Analogy

Core idea: Imagine a team of robots where each robot is really good at one thing. One robot is great at drawing, one at maths, one at writing. When you have a big project, the team leader (the orchestrator) gives each part of the project to the robot that's best at it.

Key concepts at this level: - Specialisation: Being really good at one specific thing - Delegation: Asking someone else to do a job because they're better at it than you - Trade-off: Sometimes asking for help takes time, so you have to decide if it's worth it

Activity: Think of a school project. List the tasks (research, writing, drawing, presenting). Which "robot" would you assign each task to, and why?

Takeaway: Teams work better when each member focuses on what they do best. The team leader's job is to match tasks to the right team member.

🔵 Ages 15–18: Systems Thinking and Incentives

Core idea: Multi-agent systems are like companies. The CEO (orchestrator) doesn't do every job — they hire specialists. But hiring has costs: salary, management time, the risk that the hire underperforms.

Key concepts at this level: - Comparative advantage: Even if one agent is better at everything, it still makes sense to delegate tasks where the relative advantage of the specialist is greatest - Principal-agent problem: When you hire someone, their interests may not perfectly align with yours. How do you design incentives so they do the job well? - Market price signals: In a market with many specialists, prices tell you who is efficient and who is not

Discussion question: If you ran a company and could hire unlimited specialists, what would stop you from delegating everything? (Answer: coordination costs, verification costs, and the risk of losing control of quality.)

Takeaway: Delegation is powerful but not free. The economics of when to delegate and when to do it yourself is a core management skill — and a core AI system design skill.

🟠 Ages 19–25: Economic Frameworks and System Design

Core idea: Multi-agent delegation is a formal economic problem. The orchestrator is a firm making input procurement decisions. Subagents are suppliers in a capability market. Standard microeconomic tools apply: comparative advantage, market structure, price formation, and mechanism design.

Key concepts at this level: - Capability markets: How supply and demand for specialised AI capabilities determine prices and allocation - Mechanism design: How to structure the rules of a capability market so that agents reveal their true costs and capabilities (incentive compatibility) - Transaction cost economics: Coordination, specification, and verification costs determine the boundary of the "firm" (what the orchestrator does internally vs. outsources) - Adverse selection and moral hazard: Information asymmetries between orchestrators and subagents create market failures that must be designed around

Technical exercise: Model a simple capability market with three subagents of different quality and cost. Write the orchestrator's decision rule as a scoring function. What happens to market outcomes if one subagent's quality is unobservable?

Takeaway: MAS design is applied mechanism design. The economic structure of the system determines whether specialisation surplus is captured or dissipated in coordination costs.

🔴 Ages 26+: Advanced Practitioner and Research Level

Core idea: Production multi-agent systems must solve hard problems in distributed systems, mechanism design, and operational economics simultaneously. The theoretical frameworks are well-developed; the engineering challenges are not.

Key concepts at this level: - Dynamic capability markets: Prices and availability change in real time; orchestrators need adaptive routing logic - Reputation system design: How to build reputation mechanisms that are Sybil-resistant, manipulation-resistant, and informative - Delegation under uncertainty: Orchestrators often don't know task difficulty in advance; how do you price and route tasks when the cost of completion is uncertain? - Vertical integration vs. specialisation: When should an agent economy firm build capabilities in-house vs. rely on the market? Classic make-or-buy, applied to AI infrastructure - Cross-system interoperability: Capability markets only function if agents from different systems can discover, trust, and transact with each other — requires standardised protocols

Research frontier questions: - Can capability markets achieve efficient allocation without centralised coordination? - How do reputation systems behave under adversarial conditions at scale? - What is the optimal delegation depth for different task classes? - How do capability prices evolve as models improve and commoditise?

Practical Implementation Frameworks

Framework 1: Capability Registry Pattern

Orchestrator
    │
    ├── Query CapabilityRegistry(task_type, quality_min, latency_max, price_max)
    │       └── Returns: [SubagentA, SubagentB, SubagentC] with scores
    │
    ├── Select SubagentA (highest score within constraints)
    │
    ├── Issue Task(spec, payment_escrow)
    │
    ├── Receive Result
    │
    ├── Verify Result (automated or sampling-based)
    │
    └── Release Payment (or trigger dispute resolution)

Implementation notes: - Capability descriptions should use a standardised schema (task type, input/output format, latency SLA, price per unit) - Escrow prevents non-payment; verification gates prevent payment for failed tasks - Registry should be append-only with cryptographic signatures to prevent tampering

Framework 2: Auction-Based Task Allocation

1. Orchestrator posts Task(spec, deadline, max_price) to market
2. Subagents evaluate task against their current load and capability
3. Subagents submit bids: Bid(price, estimated_latency, quality_guarantee)
4. Orchestrator scores bids: Score = w1*(1/price) + w2*(1/latency) + w3*quality
5. Winning subagent receives task and escrow
6. On completion: verify → release payment
7. Update reputation scores for all participating subagents

Weight calibration: The scoring weights (w1, w2, w3) encode the orchestrator's priorities. A latency-sensitive orchestrator sets w2 high. A cost-sensitive orchestrator sets w1 high. These weights should be tunable per task class.

Framework 3: Hierarchical Delegation with Budget Propagation

For complex tasks requiring multi-level delegation:

Root Orchestrator
  Budget: $B_total
  Task: T_complex

  ├── Subtask T1 → SubagentA (budget: $B1)
  │     └── Sub-subtask T1a → SubagentX (budget: $B1a)
  │
  ├── Subtask T2 → SubagentB (budget: $B2)
  │
  └── Subtask T3 → SubagentC (budget: $B3)
        └── Sub-subtask T3a → SubagentY (budget: $B3a)

Constraint: B1 + B2 + B3 ≤ B_total
            B1a ≤ B1 (budget cannot exceed parent allocation)

Budget propagation rules: - Each delegating agent receives a budget and must complete its task within it - Subagents cannot exceed their allocated budget without escalating to the parent - Unused budget can be returned (increasing parent's surplus) or retained (incentivising efficiency)

Framework 4: Quality-Tiered Routing

Not all tasks require the same quality level. Routing logic should match task stakes to subagent quality tier:

Task Stakes Quality Tier Verification Level Example
Low Commodity (cheapest available) Spot-check Formatting, simple classification
Medium Standard Automated verification Summarisation, translation
High Premium Full verification + human review Legal analysis, medical coding
Critical Highest available + redundancy Multi-agent consensus Financial decisions, safety-critical outputs

Integration with Existing Agent Economy Concepts

This lesson builds on and connects to other components of the agent economy:

Connection to Payment Protocols

Delegation economics requires payment infrastructure. The cost-benefit analysis of delegation only functions if payment is: - Atomic with task completion — payment and delivery happen together or not at all - Low-friction — payment overhead must not dominate small task costs - Programmable — escrow, conditional release, and dispute resolution must be automatable

Without robust payment protocols, capability markets collapse into trust-based systems that cannot scale.

Connection to Memory and Knowledge Markets

Subagents often require context to complete tasks. The cost of providing that context — retrieving relevant memory, purchasing knowledge — is part of the full delegation cost. An orchestrator delegating a task must account for: - What context the subagent needs - Whether that context must be purchased from a knowledge market - Whether the subagent already has the relevant knowledge (reducing context transfer cost)

Subagents with persistent, relevant memory are more valuable because they reduce the orchestrator's context-provisioning cost.

Connection to LLM API Cost Structures

Subagent pricing is downstream of LLM API costs. A subagent's minimum viable price is its marginal inference cost. As model costs fall (driven by hardware improvements, quantisation, and caching), capability market prices compress. This creates: - Commoditisation pressure on common capabilities - Persistent premiums only for rare, hard-to-replicate capabilities - Incentives to specialise into niches where commoditisation is slow

Understanding per-token economics is prerequisite to understanding capability market dynamics.

Case Studies and Real-World Applications

Case Study 1: Code Generation Pipeline

Setup: A software development orchestrator receives a feature request. It must produce tested, documented code.

Delegation structure: - Spec subagent: Converts natural language request into formal technical specification - Code generation subagent: Produces code from specification (specialised on target language/framework) - Test generation subagent: Writes unit tests for the generated code - Documentation subagent: Generates inline and API documentation - Review subagent: Checks code against style guides and security patterns

Economic dynamics: The orchestrator captures value from the complete pipeline. Each subagent is paid for its specific contribution. The orchestrator's margin is the difference between the client's payment and the sum of subagent costs plus coordination overhead.

Key tension: If the orchestrator uses a single large generalist model for all steps, it avoids coordination costs but pays higher per-token rates and may get lower quality on specialised steps. The make-or-buy decision is continuous.

Case Study 2: Research Synthesis System

Setup: An orchestrator must produce a comprehensive research report on a technical topic.

Delegation structure: - Search subagents (multiple, parallel): Query different databases and sources - Extraction subagent: Pulls key claims and data from retrieved documents - Fact-checking subagent: Cross-references claims across sources - Synthesis subagent: Integrates findings into coherent narrative - Formatting subagent: Applies output schema and citation formatting

Economic dynamics: Parallel search subagents reduce latency but increase cost. The orchestrator must decide how many parallel search agents to deploy based on the value of faster completion vs. the cost of additional agents.

Capability market insight: Search subagents are highly commoditised (many providers, low price). Synthesis subagents command premiums because high-quality synthesis is harder to replicate and more directly tied to output value.

Case Study 3: Financial Data Processing

Setup: An orchestrator processes incoming financial data streams, extracts signals, and routes to downstream systems.

Delegation structure: - Parsing subagents: Convert raw data formats (high volume, low cost, commodity) - Anomaly detection subagent: Flags unusual patterns (specialised, premium-priced) - Classification subagent: Categorises transactions by type (medium specialisation) - Compliance subagent: Checks against regulatory rules (high specialisation, high stakes)

Economic dynamics: The compliance subagent operates in a high-stakes, low-competition market. Its price reflects both the scarcity of the capability and the cost of errors (regulatory penalties). The orchestrator cannot substitute a cheaper alternative without accepting unacceptable error risk.

Delegation depth: This system is intentionally flat. Compliance and anomaly detection subagents do not further delegate — the stakes are too high and verification of sub-delegated outputs is too difficult.

Key Takeaways and Further Learning

Core Principles

  1. Specialisation generates surplus — narrow optimisation outperforms generalism on specific tasks, creating economic value that delegation can capture.

  2. Delegation has full costs — specification, coordination, verification, and error costs must all be counted, not just the subagent fee.

  3. Capability markets form naturally — wherever specialised agents exist and tasks need routing, market structures emerge. Designing those markets well determines whether surplus is captured or wasted.

  4. The principal-agent problem is structural — every delegation relationship has misalignment risk. Verifiable outputs, reputation systems, and escrow are the engineering solutions.

  5. Hierarchy depth has diminishing returns — coordination costs compound with each delegation layer. Flat, parallel architectures outperform deep chains for most tasks.

  6. Prices encode information — capability market prices aggregate supply, demand, quality, and scarcity signals. An orchestrator that ignores price signals misallocates tasks.

  7. Commoditisation is relentless — common capabilities converge to marginal cost over time. Durable value lies in rare, hard-to-replicate specialisations.

Conceptual Connections to Explore

  • Mechanism design theory: The formal study of how to design rules for strategic interactions to achieve desired outcomes — directly applicable to capability market design
  • Transaction cost economics: Coase's theory of the firm explains why some activities are internalised and others outsourced — the same logic applies to orchestrator/subagent boundaries
  • Comparative advantage: Ricardo's trade theory is the foundational economic argument for specialisation and delegation
  • Distributed systems: CAP theorem, consensus protocols, and fault tolerance are the engineering constraints within which capability markets must operate

Practitioner Checklist

Before deploying a multi-agent delegation system:

  • [ ] Have you modelled the full cost of delegation (not just subagent fees)?
  • [ ] Is there a capability registry or discovery mechanism?
  • [ ] Are payments atomic with task completion?
  • [ ] Is output verification automated and reliable?
  • [ ] Is there a reputation or quality-tracking system?
  • [ ] Have you set delegation depth limits to control coordination overhead?
  • [ ] Are budget constraints propagated through the delegation hierarchy?
  • [ ] Have you identified which capabilities are commodity vs. premium, and priced accordingly?
  • [ ] Is there a fallback for subagent failure (retry logic, alternative providers)?
  • [ ] Have you stress-tested the system under adversarial conditions (Sybil agents, low-quality providers)?

Empirica Agent Economy Series. This lesson is part of a sequence covering the economic infrastructure of autonomous agent systems. Adjacent lessons cover payment protocols, memory and knowledge markets, and LLM API cost structures.