Choosing a Harness + Frontier Appendix

Overview

This lesson serves two purposes:

Part 1 provides a production-grounded framework for choosing agent harnesses. You'll learn decision criteria, anti-patterns to avoid, and how to match runtime requirements to harness capabilities.

Part 2 is an optional frontier appendix covering emerging runtime directions: protocol-native runtimes (MCP, A2A), autonomous goal decomposition, and long-running agent operating systems. These topics are experimental and not required for the capstone project.

Part 1: Choosing a Harness

Module 5 Lesson 11 (Ecosystem Map) showed you the landscape of available harnesses. Now you need a systematic way to choose.

Decision Framework

The flowchart below walks through five decision points that map to harness categories. Start at the top and follow the branches based on your requirements.

Decision tree with 5 decision points: (1) agent count, (2) control flow complexity or durable execution, (3) team knowledge, (4) deployment constraints. Each path leads to recommended harness categories.

Decision Point 1: How Many Agents?

• Single agent: Most use cases start here. A single agent with tools can handle complex tasks if the control flow is clear.
• Multiple agents with coordination: Only needed when you have genuinely distinct roles (e.g., researcher agent + code reviewer agent) or when parallelizing independent subtasks.

Heuristic: If you can describe the task without mentioning multiple personas, you probably need a single agent.

Decision Point 2: Control Flow Complexity or Durable Execution

For single agents:

• Simple control flow (3-5 turns, few tools, no branching): Use a simple library or single-agent SDK.
• Complex control flow (branching, loops, state transitions): Use an orchestration framework.

For multiple agents:

• Durable execution required (long-running, approval gates, resumability): Use an orchestration framework with state persistence.
• Short-lived, synchronous: Proceed to team knowledge assessment.

Decision Point 3: Team Knowledge

If you don't need durable multi-agent execution, choose based on what your team already knows:

• LangChain ecosystem: LangGraph or CrewAI for multi-agent coordination.
• Claude SDK / Anthropic API: Claude Team SDK or Agent SDK multi-agent mode.
• Other framework: Match the harness to your team's existing expertise (e.g., if you already use Temporal for workflows, extend it for agents).

Decision Point 4: Deployment Constraints

• Serverless, stateless: Use a stateless harness (function-based) or checkpoint state to an external store (S3, database).
• Long-running server, container: Use a harness with native state persistence (e.g., LangGraph with PostgreSQL checkpointer, Temporal).
• Enterprise (compliance, air-gap, audit): Use a harness with enterprise features (audit logs, role-based access, air-gap deployment) or build a custom solution if no harness meets your constraints.

Anti-Patterns

Avoid these common selection mistakes:

1. Over-Engineering

Example: Using LangGraph for a 3-turn single-tool agent that just answers customer questions.

Why it's wrong: The complexity overhead (graph definition, checkpointing, state management) doesn't justify the minimal orchestration needs. A simple library or Claude Agent SDK is sufficient.

Heuristic: If your agent can be described as "call tool, read result, respond," you don't need an orchestration framework.

2. Under-Engineering

Example: Using raw Claude API calls with custom state management for a 20-step workflow with approval gates, error recovery, and resumability.

Why it's wrong: You'll end up rebuilding features that orchestration frameworks already provide (checkpointing, state transitions, retry logic). The initial simplicity becomes technical debt.

Heuristic: If you're writing if state == "waiting_approval": handle_approval() in multiple places, you need an orchestration framework.

3. Hype-Driven Selection

Example: Choosing AutoGen because it was mentioned in a blog post, without assessing whether multi-agent coordination is actually needed.

Why it's wrong: Framework selection should be driven by requirements (agent count, control flow, durability), not by trending frameworks.

Heuristic: Write down your requirements first. Then map them to harness capabilities. Don't start with "I want to use X."

4. Building Custom When Framework Fits

Example: Building a custom orchestration layer because you want "full control," when LangGraph or Temporal already handles your use case.

Why it's wrong: Custom solutions require ongoing maintenance, testing, and feature development. Unless you have unique requirements that no framework addresses, you're creating avoidable technical debt.

Heuristic: Only build custom if you can articulate a requirement that no existing harness meets. "I want control" is not a requirement.

5. Multi-Agent When Single Agent Suffices

Example: Creating separate "planner," "executor," and "critic" agents when a single agent with a planning tool and reflection prompt would work.

Why it's wrong: Multi-agent systems add coordination overhead (message passing, state synchronization, failure handling). Most tasks don't need the complexity.

Heuristic: Can a single agent with tools and a good system prompt do the job? If yes, start there. Only add agents when you need genuine role separation or parallelization.

Part 2: Frontier Appendix

Note: This section covers emerging runtime directions. These topics are experimental and not required for the capstone project. Maturity levels are assessed as of July 2026 and may change rapidly.

The agent runtime landscape is evolving beyond the production harnesses covered in Lessons 1-11. This appendix introduces three frontier directions: protocol-native runtimes, autonomous goal decomposition, and long-running agent operating systems.

Protocol-Native Runtimes

Traditional harnesses treat tools and resources as static configuration: you define tools upfront, bind them to agents, and the agent uses them.

Protocol-native runtimes reverse this: tools and resources are discovered dynamically via protocols, and the runtime adapts to what's available.

MCP (Model Context Protocol) as First-Class Runtime Primitive

What it is: MCP defines a standard protocol for exposing tools, resources, and prompts to LLMs. Instead of hardcoding tool definitions in your agent code, the agent connects to MCP servers that advertise their capabilities.

Runtime implications:

• Dynamic tool discovery: Agents can discover and use tools at runtime without code changes.
• Composability: Multiple MCP servers can be combined to create rich tool environments.
• Versioning and evolution: MCP servers can add, remove, or change tools without breaking agent code.

Maturity (July 2026):

• Adoption: Production-adopted in Claude Desktop, Zed, and other IDEs. Growing ecosystem of MCP servers.
• Hardening required: Security (untrusted server isolation), permissions (user consent for sensitive tools), identity (authenticating servers), observability (debugging tool calls across servers), and server quality (reliability and error handling).

Example: An agent running in Claude Desktop can use the filesystem MCP server to read files, the GitHub MCP server to create issues, and a custom database MCP server — all without the agent code knowing these tools exist ahead of time.

A2A (Agent-to-Agent Protocol) as Runtime Fabric

What it is: A2A defines a standard protocol for agents to discover, message, and coordinate with other agents. Instead of hardcoding multi-agent workflows, agents discover peers via a registry and negotiate coordination.

Runtime implications:

• Decentralized multi-agent systems: Agents can be deployed independently and discover each other at runtime.
• Protocol-driven coordination: Agents use A2A messages (task delegation, status updates, results) instead of framework-specific APIs.
• Federation: Agents from different organizations can collaborate if they speak A2A.

Maturity (July 2026):

• Adoption: Significant. Over 150 organizations support A2A, including AWS, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. Production deployments exist in Azure AI Foundry, Amazon Bedrock AgentCore, and Copilot Studio.
• Native support: Microsoft Agent Framework 1.0 ships with native A2A. Copilot Studio A2A is generally available. Google ADK includes A2A codelabs.
• Remaining challenges: Cross-vendor federation (most deployments are within single-vendor ecosystems), identity verification across trust boundaries, durable delivery guarantees, and debugging multi-agent flows across runtimes.

Example: A research agent running in Google ADK delegates a subtask to a code-generation agent running in Microsoft Agent Framework. The delegation happens via A2A messages, not framework-specific APIs. Both agents discover each other through an A2A registry.

CodeAct: Collapsing the Tool-Call Loop

What it is: Instead of the traditional loop where the model issues many small tool calls (model → tool call → observation → model → tool call → observation), CodeAct has the model emit a single executable program that composes multiple tool calls inside a sandbox. The sandbox executes all the tool calls and returns a consolidated result.

graph TD
  subgraph Traditional["Traditional: N Round Trips"]
      T1["Model"] --> T2["Tool Call 1"]
      T2 --> T3["Observation 1"]
      T3 --> T4["Model"]
      T4 --> T5["Tool Call 2"]
      T5 --> T6["Observation 2"]
      T6 --> T7["Model"]
      T7 --> T8["Final Answer"]
  end
  subgraph CodeActFlow["CodeAct: 1–2 Round Trips"]
      C1["Model"] --> C2["Generate Program"]
      C2 --> C3["Sandbox Executes<br/>All Tool Calls"]
      C3 --> C4["Consolidated Result"]
      C4 --> C5["Model"]
      C5 --> C6["Final Answer"]
  end

  style Traditional fill:#fff3e0,stroke:#f57c00
  style CodeActFlow fill:#e8f5e9,stroke:#388e3c

Runtime implications:

• Fewer model turns: CodeAct collapses multi-step tool plans into fewer round-trips, reducing orchestration overhead and latency.
• Sandbox requirement: The runtime must provide an isolated execution environment (sandbox) for running model-generated code. Microsoft's Hyperlight micro-VMs provide per-call isolation at minimal overhead.
• Changed error surface: Errors now occur inside the generated program, not at the tool-dispatch level. The runtime must capture and return sandbox execution errors to the model.
• Tool composition: The model can compose tools programmatically (loops, conditionals, data transformation between tool calls) rather than relying on the harness for sequencing.

Maturity (July 2026):

• Early production: Microsoft Agent Framework ships CodeAct via the agent-framework-hyperlight (alpha) package, using Hyperlight micro-VMs for isolation.
• Open questions: How to enforce permission boundaries inside generated code, how to handle partial execution failures, and how to provide observability into sandbox execution steps.

Agent Identity, Delegation, and Governance

What it is: As agents communicate across runtimes via protocols like MCP and A2A, a new runtime concern emerges: who is this agent, what authority does it have, and can you verify its actions? Agent protocols alone do not solve identity or authority.

graph LR
  USER["User<br/>(identity)"] -->|"delegate<br/>full scope"| A["Agent A<br/>(scoped token)"]
  A -->|"delegate<br/>narrowed scope"| B["Agent B<br/>(sub-token)"]
  B --> ACTION["Action"]
  ACTION -.->|"provenance chain"| USER

  style USER fill:#e3f2fd
  style A fill:#fff3e0
  style B fill:#f3e5f5
  style ACTION fill:#e8f5e9

Runtime implications:

• Verifiable identity: Each agent in a delegation chain needs a cryptographically verifiable identity, not just a name string. This enables audit trails and trust decisions.
• Delegated authority: When Agent A delegates a task to Agent B, the runtime must track what authority was delegated, with what scope, and for how long. Invocation-bound capability tokens (proposed in the Agent Identity Protocol) attach authority to specific invocations rather than granting standing permissions.
• Provenance chains: For compliance and debugging, the runtime must maintain an unbroken chain showing which agent initiated an action, through which intermediaries, and with what authorization.
• Governance patterns: Centralized governance (who can delegate), decentralized enforcement (each runtime validates tokens), and cryptographically-verifiable actor chains.

Maturity (July 2026):

• Converging patterns: Three independent sources — Uber Engineering, Gartner, and the Coalition for Secure AI (CoSAI) — published agent identity architectures in June 2026 that converge on the same pattern: centralized governance, decentralized enforcement, and cryptographically-verifiable actor chains.
• Research proposals: The Agent Identity Protocol (AIP) proposes invocation-bound capability tokens for verifiable delegation across MCP and A2A.
• No standard yet: Each platform handles agent identity differently. Cross-vendor identity federation remains unsolved.

Autonomous Goal Decomposition

What it is: Agents that take high-level goals (e.g., "Build a web scraper for product prices") and autonomously decompose them into subtasks, execute them, track progress, and re-plan when blocked — without requiring human-authored task breakdowns.

Runtime implications:

• Goal trees: The runtime must track a tree of goals and subgoals, not just a linear task sequence.
• Progress tracking: The runtime must know which goals are completed, in progress, blocked, or abandoned.
• Re-planning: When a subgoal fails or becomes infeasible, the agent must re-plan and update the goal tree.

Maturity (July 2026):

• Demonstrated capabilities: Research systems (e.g., Voyager, Reflexion) and early products (e.g., Devin, AutoGPT) show agents decomposing goals and executing multi-step plans.
• Open challenges:
  • Reliability: Agents can hallucinate infeasible plans or get stuck in loops.
  • Controllability: Users need guardrails to prevent agents from pursuing unintended subgoals.
  • Cost: Autonomous decomposition requires many LLM calls. Budgeting and early stopping are essential.

Example: An agent given the goal "Migrate the user service from REST to GraphQL" might decompose it into:

1. Analyze current REST endpoints.
2. Design GraphQL schema.
3. Implement resolvers.
4. Write tests.
5. Update client code.

The agent executes these subtasks, re-plans if step 2 reveals unexpected complexity, and reports progress.

Long-Running Agent Operating Systems

What it is: Agent runtimes that support agents persisting across days or weeks, maintaining session state, consolidating memory, managing credentials, and operating within cost budgets.

Runtime implications:

• Session management at scale: The runtime must persist sessions across restarts, handle session expiration, and resume paused sessions.
• Memory consolidation: Long-running agents accumulate conversation history. The runtime must summarize, archive, or forget old context to stay within token limits.
• Credential management: Agents need durable access to APIs, databases, and filesystems. The runtime must securely store and refresh credentials.
• Cost budgeting: Long-running agents can rack up API costs. The runtime must enforce budgets and alert when thresholds are crossed.

Maturity (July 2026):

• Experiments: Platforms like Agent Protocol and emerging agent IDEs (e.g., Replit Agent, Cursor with long-running mode) are exploring this space.
• No standardized runtime: Each platform handles session persistence, memory, and credentials differently. No cross-platform standard exists.

Example: A developer uses an agent to refactor a large codebase over three days. The agent persists its session, consolidates findings from day 1, resumes on day 2, and completes the refactor on day 3 — without re-reading the entire codebase each time.

Frontier Maturity Radar

The diagram below shows where each frontier direction sits on the maturity spectrum (as of July 2026).

Maturity radar showing four stages: Research → Experimental → Early Production → Mature. MCP and A2A are at Early Production. CodeAct, Agent Identity, and Autonomous Goal Decomposition are at Experimental. Long-Running Agent OS is at Research.

Interpretation:

• MCP: Production-adopted in Claude Desktop, Claude Code, MAF 1.0, and Google ADK. Requires hardening for server-side, multi-user, or untrusted-server scenarios.
• A2A: Early production within single-vendor ecosystems (Azure, Google Cloud). 150+ supporting organizations. Cross-vendor federation still maturing.
• CodeAct: Alpha in MAF via Hyperlight. Changes the loop shape (fewer model turns, sandbox execution). Permission boundaries and observability inside sandboxes are open questions.
• Agent identity and governance: Converging architectural patterns from Uber, Gartner, and CoSAI. Research proposals (AIP) exist but no cross-vendor standard.
• Autonomous goal decomposition: Demonstrated in research and early products, but reliability and controllability remain open challenges.
• Long-running agent OS: Early experiments. No standardized runtime yet.

Module Closing

This module taught you how the runtime layer executes agent architectures.

Connecting back to Module 4: Module 4 (Agent Architectures) taught you what architectures exist — single-agent, multi-agent, supervisor, pipeline. This module taught you how the runtime executes them: how state is managed, how errors are handled, how agents coordinate, how tools are invoked, and how the system is monitored.

Connecting forward:

• Module 6 (Agent Design Patterns): The runtime is the platform. Design patterns are the reusable solutions built on that platform. You'll learn patterns for tool use, memory management, error recovery, and human-in-the-loop workflows.
• Module 8 (Agent Frameworks & SDKs): Module 8 gives you hands-on experience with the harnesses you just compared. You'll build agents with Claude Agent SDK, LangGraph, CrewAI, and compare their runtime characteristics in practice.

Summary

Part 1: Choosing a Harness

• Use the five-decision-point framework: agent count, control flow complexity, durable execution, team knowledge, and deployment constraints.
• Avoid anti-patterns: over-engineering (complex framework for simple tasks), under-engineering (raw API calls for complex workflows), hype-driven selection, building custom when a framework fits, and multi-agent when single agent suffices.

Part 2: Frontier Appendix

• Protocol-native runtimes: MCP is production-adopted; A2A has reached early production with 150+ supporting organizations.
• CodeAct: Collapses multi-turn tool-call loops into sandbox-executed programs. Alpha in MAF via Hyperlight.
• Agent identity and governance: Converging patterns for verifiable identity, delegated authority, and provenance chains. No cross-vendor standard yet.
• Autonomous goal decomposition: Demonstrated in research and early products; reliability and controllability remain open.
• Long-running agent OS: Early experiments; no standardized runtime yet.

Module closing: Module 4 taught architectures. Module 5 taught how the runtime executes them. Module 6 (Design Patterns) teaches reusable patterns on the runtime platform. Module 8 (Frameworks & SDKs) gives you hands-on practice.

Next: Module 6 (Agent Design Patterns) — reusable solutions for tool use, memory management, error recovery, and human-in-the-loop workflows.