Multi-Agent Systems with Specialised Subagents: Capability Markets and Delegation Economics — Age-Grouped Course Lesson

Course Track: AI Agent Architecture & Economics Difficulty Range: Foundational (Ages 13+) → Advanced (Ages 18+) Estimated Duration: 3–5 hours (modular delivery) Prerequisites by Level: None (13+) | Basic algebra and logic (16+) | Microeconomics and programming concepts (18+)

Executive Summary

Multi-agent systems (MAS) are architectures in which multiple AI agents collaborate, each contributing specialised capabilities toward shared or delegated goals. The economic layer governing these systems — who delegates what task to whom, at what cost, under what trust conditions — constitutes an emerging field called delegation economics. This lesson builds from intuitive foundations for younger learners to rigorous economic and implementation frameworks for advanced students. It extends Empirica's published work on agent-to-agent payment protocols, API service consumption, and capability market structures, adding age-differentiated pedagogy, scenario exercises, and assessment rubrics not previously published.

Core thesis: Specialisation in multi-agent systems produces efficiency gains analogous to comparative advantage in trade theory, but introduces coordination costs, trust asymmetries, and market design problems that require both technical and economic reasoning to solve.

Learning Objectives by Age Group

Ages 13–15 (Foundational)

  • Explain what an AI agent is and why multiple agents might work together
  • Describe specialisation using real-world analogies (teams, supply chains)
  • Identify at least three examples of tasks that benefit from delegation
  • Recognise that delegation involves trade-offs: speed vs. cost vs. trust

Ages 16–17 (Intermediate)

  • Define capability markets and explain how agents "price" their services
  • Apply comparative advantage logic to agent task allocation
  • Analyse coordination costs and explain why they sometimes outweigh specialisation gains
  • Evaluate trust mechanisms (reputation, verification, escrow) in agent networks

Ages 18+ (Advanced)

  • Model delegation decisions using utility functions and constraint optimisation
  • Design a capability market with pricing, discovery, and settlement mechanisms
  • Assess failure modes: principal-agent problems, capability misrepresentation, cascading failures
  • Implement a basic orchestrator-subagent architecture with economic routing logic

Section 1: Foundations (Ages 13+)

What Is an AI Agent?

An AI agent is a software system that perceives inputs, reasons about them, and takes actions to achieve a goal — often autonomously, without step-by-step human instruction. Examples include a chatbot that books travel, a code assistant that writes and tests software, or a research agent that retrieves and summarises documents.

Key properties of an agent: - Goal-directed: Has an objective it works toward - Autonomous: Acts without constant human oversight - Reactive: Responds to new information - Proactive: Initiates actions to achieve goals

Why Multiple Agents?

A single agent faces limits: it cannot be simultaneously expert in legal reasoning, image analysis, financial modelling, and natural language translation. Multi-agent systems solve this by dividing labour.

Analogy — The Hospital: A hospital does not employ one person who is simultaneously a surgeon, radiologist, pharmacist, and administrator. It employs specialists who communicate and hand off tasks. A multi-agent system works the same way: an orchestrator agent (like a hospital administrator) receives a complex task and delegates subtasks to specialist subagents (like the surgeon or radiologist).

What Is Delegation?

Delegation is the act of assigning a task to another agent (or person) who has the capability or authority to complete it. Delegation is not free: - The delegating agent must identify who can do the task - It must communicate the task clearly - It must verify the result - It must pay (in compute, tokens, money, or trust credits) for the service

Three questions every delegation decision must answer: 1. Can this subagent actually do the task? (capability) 2. Will it do it correctly and honestly? (trust) 3. Is the cost worth the benefit? (economics)

Specialisation Creates Value — But Also Dependency

When agents specialise, they become very good at narrow tasks. This creates value (faster, cheaper, better outputs) but also dependency: if a specialist subagent fails or is unavailable, the whole system may stall.

Discussion prompt (Ages 13+): Think of a group project at school. What happens when the person responsible for one section doesn't deliver? How could the group have designed the project differently to reduce this risk?

Section 2: Core Concepts (Ages 16+)

Capability Markets: Definition and Structure

A capability market is a system — formal or emergent — in which agents advertise what they can do, and other agents (or humans) select and pay for those capabilities. The market has four components:

Component Function Example
Discovery Finding agents with needed capabilities Agent registry, capability index
Pricing Determining cost of a capability Token cost per API call, latency premium
Matching Connecting requester to provider Routing algorithm, auction mechanism
Settlement Completing payment and verifying output Escrow release, reputation update

Comparative Advantage in Agent Systems

Comparative advantage (Ricardo, 1817) states that a party should specialise in tasks where their relative efficiency is highest, even if another party is absolutely better at everything. This applies directly to agent systems.

Example: - Agent A can complete Task X in 2 seconds and Task Y in 10 seconds - Agent B can complete Task X in 3 seconds and Task Y in 4 seconds - Agent A has absolute advantage in both tasks - Agent B has comparative advantage in Task Y (it gives up less by doing Y) - Optimal allocation: Agent A does X; Agent B does Y

In agent networks, the orchestrator solves this allocation problem continuously, often under time and budget constraints.

Coordination Costs

Specialisation gains are offset by coordination costs — the overhead of managing delegation:

  • Discovery cost: Time/compute to find the right subagent
  • Communication cost: Tokens and latency to transmit task context
  • Verification cost: Effort to check that output is correct
  • Trust cost: Risk premium paid when subagent reliability is uncertain

Coordination cost formula (simplified):

Net gain = Specialisation gain − (Discovery + Communication + Verification + Trust premium)

If coordination costs exceed specialisation gains, it is more efficient for the orchestrator to complete the task itself. This is the make-or-buy decision in agent economics, directly parallel to the firm theory of Ronald Coase (1937).

Trust Mechanisms

Trust in agent networks is not assumed — it is constructed through mechanisms:

  1. Reputation systems: Agents accumulate scores based on past performance. High-reputation agents command premium prices.
  2. Capability verification: Cryptographic proofs or benchmark results that confirm an agent can do what it claims.
  3. Escrow and conditional payment: Payment is held until output is verified, reducing incentive for subagents to deliver low-quality work.
  4. Redundancy: Sending the same task to multiple subagents and comparing outputs (expensive but high-trust).

Exercise (Ages 16+): Design a trust scoring system for a network of 10 research subagents. What data would you collect? How would you weight recent vs. historical performance? What happens when a trusted agent suddenly underperforms?

Section 3: Advanced Economics (Ages 18+)

The Principal-Agent Problem in MAS

The principal-agent problem arises when one party (the principal) delegates to another (the agent) whose interests may not align with the principal's. In multi-agent systems, this occurs at every delegation layer:

  • Human → Orchestrator: Does the orchestrator pursue the human's actual goal or optimise for a proxy metric?
  • Orchestrator → Subagent: Does the subagent report accurate capability and cost, or misrepresent to win tasks?
  • Subagent → Tool/API: Does the tool return accurate data or hallucinate?

Mitigation strategies: - Incentive alignment: Design payment structures so subagent reward correlates with output quality, not just task completion - Monitoring: Orchestrator spot-checks subagent outputs against ground truth - Mechanism design: Structure the market so honest reporting is the dominant strategy (e.g., Vickrey auctions for task allocation)

Utility Functions and Delegation Decisions

An orchestrator maximises a utility function subject to constraints. A simplified model:

Maximise: U = Q(output) − C(cost) − R(risk)

Subject to:
  Budget constraint: Σ cost_i ≤ B
  Time constraint: Σ latency_i ≤ T
  Quality threshold: Q_i ≥ Q_min for all subtasks i

Where: - Q(output) = quality of final output (often a weighted composite) - C(cost) = total compute/token/monetary cost - R(risk) = expected loss from subagent failure or error - B = total budget - T = deadline

This is a constrained optimisation problem. In practice, orchestrators use heuristics, learned policies, or auction mechanisms rather than solving it analytically at runtime.

Pricing Mechanisms in Capability Markets

Three dominant pricing models observed in current and emerging agent markets:

Model Mechanism Best For Failure Mode
Fixed price Flat rate per task type Predictable, commodity tasks Underprices complex tasks
Dynamic/auction Price set by supply/demand at runtime Variable load, scarce capabilities Latency from auction overhead
Subscription/retainer Fixed periodic payment for priority access High-frequency, time-sensitive tasks Wasted spend if demand drops

Market failure conditions: - Monopoly capability: One subagent holds a unique capability, enabling rent extraction - Information asymmetry: Subagent knows its true capability; orchestrator does not — adverse selection risk - Externalities: A subagent's failure imposes costs on other agents in the pipeline (negative externality)

Cascading Failure Analysis

In tightly coupled agent pipelines, subagent failure propagates. A subagent that returns a malformed output does not just fail its own task — it corrupts inputs to downstream agents.

Failure propagation model:

P(system failure) = 1 − Π(1 − p_i)   [independent failures]
P(system failure) > 1 − Π(1 − p_i)   [correlated/cascading failures]

Where p_i is the failure probability of subagent i. Correlated failures (e.g., all subagents using the same underlying model) dramatically increase system-level risk.

Mitigation: Circuit breakers, fallback agents, graceful degradation protocols, and architectural loose coupling.

Section 4: Practical Implementation (Ages 18+)

Orchestrator Architecture Patterns

Three established patterns for orchestrator-subagent systems:

Pattern 1: Hierarchical Delegation

Human → Orchestrator → [Subagent A, Subagent B, Subagent C]
                              ↓
                       Subagent A → [Sub-subagent A1, A2]
  • Orchestrator decomposes task, assigns subtasks, aggregates results
  • Suitable for: complex, multi-step tasks with clear decomposition
  • Risk: orchestrator becomes bottleneck; deep hierarchies amplify latency

Pattern 2: Peer-to-Peer Delegation

Agent A ↔ Agent B ↔ Agent C
  • Agents negotiate directly without central orchestrator
  • Suitable for: dynamic, emergent task allocation
  • Risk: coordination overhead, no single point of accountability

Pattern 3: Market-Based Allocation

Task Board → [Bid: Agent A $0.02, Agent B $0.015, Agent C $0.03]
           → Award to Agent B (lowest bid meeting quality threshold)
  • Tasks posted to a market; agents bid; lowest qualifying bid wins
  • Suitable for: commodity tasks with many capable providers
  • Risk: race to bottom on price may reduce quality

Capability Discovery Implementation

A minimal capability registry entry (JSON schema):

{
  "agent_id": "research-agent-v2",
  "capabilities": ["web_search", "document_summarisation", "citation_extraction"],
  "pricing": {
    "web_search": {"per_call": 0.001, "currency": "USD"},
    "document_summarisation": {"per_1k_tokens": 0.002, "currency": "USD"}
  },
  "performance_metrics": {
    "avg_latency_ms": 340,
    "success_rate": 0.97,
    "quality_score": 8.2
  },
  "trust_level": "verified",
  "sla": {"uptime_guarantee": 0.99, "max_latency_ms": 2000}
}

Routing Logic: A Decision Algorithm

def select_subagent(task, available_agents, budget, deadline):
    candidates = [a for a in available_agents
                  if task.type in a.capabilities
                  and a.pricing[task.type] <= budget
                  and a.avg_latency <= deadline]

    if not candidates:
        return fallback_handler(task)

    # Score = quality_weight * quality - cost_weight * cost - latency_weight * latency
    scored = [(a, 0.5 * a.quality_score
                  - 0.3 * a.pricing[task.type]
                  - 0.2 * a.avg_latency)
              for a in candidates]

    return max(scored, key=lambda x: x[1])[0]

Key design decisions in this algorithm: - Weight parameters (0.5, 0.3, 0.2) encode the orchestrator's priorities — adjusting them changes market outcomes - Fallback handler prevents hard failure when no candidate qualifies - This is a greedy heuristic, not a globally optimal solution

Settlement and Verification

Post-task settlement requires: 1. Output receipt: Subagent returns result with metadata (latency, tokens used, confidence score) 2. Quality check: Orchestrator applies a verifier (another agent, a rule-based checker, or human review) 3. Payment release: If quality threshold met, payment released from escrow 4. Reputation update: Subagent's score updated based on this interaction

Implementation note: Empirica's published lesson on Agent-to-Agent Payment Protocols covers settlement layer mechanics in detail, including atomic transaction design and dispute resolution. This lesson assumes that infrastructure and focuses on the economic routing layer above it.

Section 5: Real-World Case Studies

Case Study 1: OpenAI's Multi-Agent Research Pipeline

OpenAI's internal research workflows use orchestrator agents that delegate to specialised subagents for literature search, code execution, data analysis, and report generation. Key economic observation: the orchestrator's routing decisions are not purely capability-based — they incorporate cost budgets per research query, creating de facto capability market dynamics even without a formal market structure.

Lesson: Capability markets can emerge informally from budget constraints, before any explicit market infrastructure is built.

Case Study 2: Anthropic's Claude Tool Use and Subagent Patterns

Claude's tool-use architecture allows a primary model to delegate to external tools (web search, code interpreter, calculator) via structured API calls. Each tool call has a latency and token cost. Anthropic's published benchmarks show that task decomposition quality — how well the orchestrator breaks down a problem — is the primary determinant of overall system performance, more than the capability of individual subagents.

Lesson: Orchestrator intelligence is the binding constraint in many MAS deployments. Investing in orchestrator quality yields higher returns than adding more subagents.

Case Study 3: Autonomous Software Development Agents (Devin, SWE-agent)

Systems like Devin (Cognition AI) and SWE-agent (Princeton) use multi-agent patterns for software engineering: a planning agent decomposes a coding task, delegates to a code-writing agent, a testing agent, and a debugging agent. Economic analysis reveals: - Iteration cost: Each debugging cycle consumes compute; poorly specified initial tasks multiply costs - Specialisation premium: Dedicated testing agents outperform generalist agents on bug detection by 15–30% in published benchmarks - Coordination overhead: Multi-agent SWE systems use 2–4× more tokens than single-agent approaches for equivalent tasks, but achieve higher success rates on complex problems

Lesson: Specialisation gains are real but require sufficient task complexity to justify coordination overhead. For simple tasks, a single capable agent is more economical.

Case Study 4: Financial Trading Agent Networks

Proprietary trading firms have deployed multi-agent systems where a portfolio orchestrator delegates to specialised subagents: a sentiment analysis agent, a technical analysis agent, a risk assessment agent, and an execution agent. The capability market here is internal but exhibits all market properties: agents compete for "task allocation" based on recent performance, underperforming agents are deprioritised (analogous to market exit), and pricing is implicit in compute allocation.

Lesson: Internal capability markets — where agents compete for task allocation based on performance — can drive quality improvement without requiring external market infrastructure.

Section 6: Interactive Scenarios & Exercises

Scenario A: The Overwhelmed Orchestrator (Ages 13+)

Setup: You are an orchestrator agent. You receive a task: "Plan a three-day school trip to Rome for 30 students, including transport, accommodation, meals, and educational activities." You have access to four subagents: a travel booking agent, a restaurant finder agent, a museum guide agent, and a budget calculator agent.

Tasks: 1. List all the subtasks you need to complete 2. Assign each subtask to the most appropriate subagent 3. Identify which subtasks depend on others (must be done in sequence) 4. Identify which subtasks can be done simultaneously (in parallel) 5. What happens if the travel booking agent fails? Write a contingency plan.

Discussion: What information does each subagent need from you to do its job? What information does it need from other subagents?

Scenario B: Pricing a Capability (Ages 16+)

Setup: You are a specialised legal document analysis agent. You can review a contract in 45 seconds with 94% accuracy. Your compute cost per review is $0.008. The market has two competitors: Agent X (60 seconds, 91% accuracy, $0.005) and Agent Y (30 seconds, 97% accuracy, $0.015).

Tasks: 1. What price should you charge? Justify using the competitive landscape. 2. An orchestrator values accuracy at 60%, speed at 25%, and cost at 15%. Calculate which agent it will select. 3. If Agent Y drops its price to $0.010, how does your optimal strategy change? 4. Design a pricing strategy that maximises your long-run market share, not just immediate profit.

Extension: What non-price signals could you use to differentiate your service? (Hint: consider trust, SLA guarantees, specialisation depth.)

Scenario C: Cascading Failure Simulation (Ages 18+)

Setup: A five-agent pipeline processes insurance claims: - Agent 1: Document ingestion (failure rate: 2%) - Agent 2: Data extraction (failure rate: 3%) - Agent 3: Fraud detection (failure rate: 1%) - Agent 4: Coverage assessment (failure rate: 4%) - Agent 5: Decision output (failure rate: 1%)

Tasks: 1. Calculate the probability that a claim is processed successfully end-to-end (assume independent failures) 2. Recalculate assuming Agent 2 and Agent 3 share the same underlying model (correlation coefficient = 0.7) 3. Design a circuit breaker: at what failure rate threshold should the orchestrator route claims to a human reviewer instead? 4. Propose an architectural change that reduces system failure probability below 5% without replacing any individual agent

Quantitative answer for Task 1:

P(success) = (1−0.02)(1−0.03)(1−0.01)(1−0.04)(1−0.01)
           = 0.98 × 0.97 × 0.99 × 0.96 × 0.99
           ≈ 0.893 (89.3% success rate)

Scenario D: Market Design Challenge (Ages 18+)

Setup: You are designing a capability market for a network of 50 specialised AI agents serving a legal research firm. The firm processes 10,000 tasks per day across six capability types: case law search, statute analysis, brief drafting, citation checking, jurisdiction mapping, and risk assessment.

Design requirements: 1. Specify the discovery mechanism: how do orchestrators find agents with needed capabilities? 2. Specify the pricing mechanism: fixed, auction, or subscription? Justify for each capability type. 3. Specify the trust mechanism: how is agent quality verified and communicated? 4. Specify the settlement mechanism: when and how is payment released? 5. Identify the three most likely market failures in your design and propose mitigations.

Section 7: Assessment Rubrics by Level

Foundational Level (Ages 13–15)

Criterion 4 — Exceeds 3 — Meets 2 — Approaching 1 — Beginning
Agent definition Defines agent with all four properties; gives original example Defines agent correctly; uses provided example Partial definition; some confusion with simple automation Cannot distinguish agent from non-agent system
Delegation concept Explains delegation trade-offs unprompted; identifies failure modes Explains delegation with prompting; identifies one trade-off Understands delegation as task assignment only Conflates delegation with instruction-following
Specialisation value Connects specialisation to system-level efficiency; uses analogy correctly Explains why specialisation helps; analogy partially correct Identifies that specialists exist; cannot explain why No clear understanding of specialisation benefit
Scenario exercise Completes all five tasks; contingency plan is specific and actionable Completes four tasks; contingency plan is general Completes two to three tasks; no contingency plan Completes one task or fewer

Intermediate Level (Ages 16–17)

Criterion 4 — Exceeds 3 — Meets 2 — Approaching 1 — Beginning
Comparative advantage Applies correctly to novel agent scenario; identifies when it does not apply Applies correctly to provided scenario Understands concept but calculation errors Cannot apply to agent context
Coordination costs Quantifies all four cost types; identifies when costs exceed gains Identifies three cost types; qualitative analysis Identifies coordination costs exist; cannot categorise No awareness of coordination costs
Trust mechanisms Designs original trust system with three mechanisms; addresses gaming Describes three mechanisms from lesson; applies to scenario Describes one to two mechanisms; limited application Cannot explain why trust mechanisms are needed
Pricing scenario Correct calculation; dynamic strategy; considers long-run equilibrium Correct calculation; static strategy Calculation errors; strategy partially justified Cannot perform pricing calculation

Advanced Level (Ages 18+)

Criterion 4 — Exceeds 3 — Meets 2 — Approaching 1 — Beginning
Utility function modelling Formulates original utility function; identifies parameter sensitivity Uses provided framework correctly; solves constrained problem Sets up problem but cannot solve; parameter confusion Cannot formulate utility function
Principal-agent analysis Identifies all three delegation layers; proposes incentive-aligned mechanisms Identifies two layers; proposes one mitigation Identifies principal-agent problem; no mitigation Cannot identify principal-agent problem in MAS context
Implementation Working routing algorithm with fallback; justified weight parameters Routing algorithm with minor errors; weights unjustified Algorithm structure correct; logic errors Cannot produce routing algorithm
Market design Complete market design; three failure modes with specific mitigations Complete design; one to two failure modes identified Partial design; no failure mode analysis Cannot specify market components
Cascading failure Correct probability calculation; correlated failure model; architectural solution Correct independent failure calculation; circuit breaker designed Calculation errors; conceptual understanding present Cannot model failure propagation

Glossary & Technical Terms

Agent (AI): A software system that perceives inputs, reasons, and takes autonomous actions toward a goal.

Capability market: A system in which agents advertise, price, and sell their functional capabilities to other agents or humans.

Cascading failure: A failure mode in which one component's failure triggers failures in dependent components, amplifying system-level risk.

Circuit breaker: An architectural pattern that detects failure conditions and reroutes tasks to fallback systems before failure propagates.

Comparative advantage: The principle that a party should specialise in tasks where their relative efficiency is highest, even if another party is absolutely more capable.

Coordination cost: The overhead — in compute, latency, tokens, or risk — incurred by managing delegation between agents.

Delegation: The assignment of a task from one agent (or human) to another agent with the capability to complete it.

Escrow: A conditional payment mechanism where funds are held by a neutral party until task completion is verified.

Incentive alignment: Designing reward structures so that an agent's self-interest leads it to act in the principal's interest.

Information asymmetry: A condition in which one party (typically the subagent) has more information about their true capabilities than the other party (the orchestrator).

Make-or-buy decision: The choice between completing a task internally versus delegating it to an external agent — directly analogous to Coase's theory of the firm.

Mechanism design: The engineering of rules and incentive structures so that rational participants' self-interested behaviour produces a desired collective outcome.

Orchestrator: A coordinating agent that decomposes complex tasks and delegates subtasks to specialised subagents.

Principal-agent problem: The misalignment of interests between a delegating party (principal) and the party performing the task (agent).

Reputation system: A mechanism that tracks and communicates an agent's historical performance to inform future delegation decisions.

SLA (Service Level Agreement): A formal commitment by a subagent specifying guaranteed performance parameters (uptime, latency, accuracy).

Specialisation: The concentration of an agent's capabilities on a narrow task domain, enabling higher performance within that domain.

Subagent: A specialised agent that receives delegated tasks from an orchestrator and returns results.

Utility function: A mathematical representation of an agent's preferences, used to rank outcomes and guide decision-making.

Vickrey auction: A sealed-bid auction in which the highest bidder wins but pays the second-highest bid price — incentivises truthful bidding.

Further Resources & Extensions

For Ages 13–15

  • Conceptual: Explore how supply chains work as real-world multi-agent systems (logistics, manufacturing)
  • Activity: Map a school's administrative structure as an agent hierarchy — who delegates what to whom?
  • Reading: "The Wealth of Nations" (Adam Smith) — Chapter 1 on division of labour, accessible excerpts

For Ages 16–17

  • Economic theory: Ricardo's "Principles of Political Economy" (1817) — comparative advantage chapters
  • Agent frameworks: Explore LangChain's multi-agent documentation (free, online) — no coding required to understand architecture diagrams
  • Simulation: NetLogo agent-based modelling platform — free, browser-based, visual

For Ages 18+

  • Academic: Wooldridge, M. (2009). An Introduction to MultiAgent Systems (2nd ed.) — foundational MAS textbook
  • Economic theory: Coase, R. (1937). "The Nature of the Firm" — transaction cost economics applied to agent boundaries
  • Implementation: LangGraph documentation — stateful multi-agent orchestration with Python
  • Research: AutoGen (Microsoft Research) — multi-agent conversation framework, open source
  • Empirica extensions: Agent-to-Agent Payment Protocols lesson (settlement layer); AI Agent API Service Consumption lesson (cost modelling); Physics Gravity Models lesson (agent economy spatial dynamics)

Advanced Research Directions

  • Mechanism design for capability markets under incomplete information
  • Formal verification of multi-agent coordination protocols
  • Federated learning as a capability-sharing mechanism between agents
  • Blockchain-based reputation systems for decentralised agent networks

Instructor Notes & Facilitation Guide

Pacing Recommendations

Audience Recommended Sections Duration Delivery Mode
Ages 13–15 Sections 1, 5 (Cases 1–2), Scenario A 60–75 minutes Discussion-led, visual aids
Ages 16–17 Sections 1–2, 5 (all cases), Scenarios A–B 90–120 minutes Lecture + group work
Ages 18+ All sections 3–5 hours Seminar + lab

Common Misconceptions to Address

Misconception 1: "More agents always means better performance." Correction: Coordination costs scale with agent count. Beyond a threshold, adding agents reduces net performance. The optimal number of agents is determined by the task decomposability and coordination cost structure.

Misconception 2: "The orchestrator is always the smartest agent." Correction: Orchestrators need planning and coordination intelligence, not necessarily domain expertise. A less capable orchestrator routing to highly capable subagents can outperform a highly capable single agent.

Misconception 3: "Trust in agent systems is a technical problem, not an economic one." Correction: Trust mechanisms are fundamentally economic — they create incentive structures. Reputation systems, escrow, and verification are market design tools, not just engineering solutions.

Misconception 4: "Specialisation always improves outcomes." Correction: Specialisation improves outcomes only when task complexity justifies coordination costs. For simple tasks, a generalist agent is more efficient. The Case Study 3 data (2–4× token overhead for multi-agent SWE systems) illustrates this directly.

Facilitation Tips

  • For Scenario B (pricing): Students often set prices based on cost-plus reasoning. Push them to consider competitive dynamics and long-run equilibrium — what happens when all agents adopt the same strategy?
  • For Scenario C (cascading failure): The correlated failure calculation is mathematically challenging. Focus on the conceptual insight — shared infrastructure creates hidden dependencies — rather than the exact calculation for younger advanced students.
  • For Scenario D (market design): Encourage students to identify tensions between design goals (e.g., low-latency discovery vs. comprehensive quality verification). There is no perfect design — the exercise is about explicit trade-off reasoning.
  • Cross-cutting theme: Return repeatedly to the Coasian insight — the boundary of the "agent firm" (what the orchestrator does itself vs. delegates) is determined by transaction costs. This unifies the economic and technical content.

Assessment Administration

  • Foundational: Scenario A as a group exercise; rubric applied to group product and individual contribution
  • Intermediate: Scenario B as individual written exercise; Scenario A as warm-up
  • Advanced: Scenarios C and D as individual or pair exercises; implementation section as optional lab extension
  • Cross-level: Case Study discussion can be run with mixed-age groups — older students explain economic concepts; younger students contribute intuitions about failure and trust

Connection to Empirica's Published Curriculum

This lesson sits at the intersection of three published Empirica tracks: 1. Agent Architecture: Extends the orchestrator-subagent pattern introduced in prior MAS lessons 2. Agent Economy: Provides pedagogical scaffolding for the economic concepts in the capability markets and payment protocols lessons 3. Implementation: Bridges conceptual economics to the API consumption and routing logic covered in the AI Agent API Service Consumption lesson

Instructors teaching the full Empirica agent economics curriculum should position this lesson after the foundational agent architecture lesson and before the payment protocols and gravity model lessons, which assume the economic vocabulary established here.

Empirica Course Lesson | AI Agent Architecture & Economics Track | Version 1.0 Validated research score: 80 | Age range: 13+ | Format: Markdown Report