A PRACTICAL MAP FOR AGENT SYSTEMS

Four layers. Different responsibilities.

Use MCP when an agent needs tools or data. Use A2A when independent agent applications need to exchange capabilities, tasks, messages, and artifacts. Use a framework or runtime to execute an agent workflow inside one application. In this guide, “harness” means the layer that keeps work identity, evidence, findings, and acceptance intact across those interactions.

Read the comparison

The short version

MCP lets an agent use tools. A2A lets independent agent applications communicate. A runtime organizes execution. A harness keeps work, evidence, and acceptance meaningful across that execution.

One system can carry all four layers.

Each layer has a narrower responsibility than the product category labels often suggest. The boundaries below reflect official core concepts, not every custom implementation a team could build.

Harness

Why should the work be believed?

Preserves work identity, constraints, evidence, findings, commit boundaries, target readback, and acceptance decisions.

Framework or runtime

How does one application execute?

Organizes loops, state, routing, handoffs, graphs, persistence, recovery, and human intervention inside an application.

A2A communication

How do independent agents interact?

Exchanges capability descriptions, messages, tasks, artifacts, and task state between agent applications.

MCP

How does an agent use tools and context?

Lets an AI application connect to tools, resources, and prompts through a common interface.

Do not ask only whether a product supports multiple agents.

Ask where it operates, what it binds, and which completion claim it can actually support.

Layer	Main connection	Core objects	It does not establish by itself
MCP	An AI application and external tools, data, or workflows	Tools, resources, prompts	A successful tool call does not establish that the complete work result is correct.
A2A	Independent agent applications	Agent cards, messages, tasks, artifacts	A completed task state does not establish independent acceptance of the artifact.
Framework or runtime	Agents, tools, and state inside one application	Loops, graphs, handoffs, state	A completed run does not establish that a change reached the real target or responsible party.
Harness	Work, executors, evidence, decisions, and the target environment	Events, capsules, gates, findings, acceptance	Governance does not replace model quality, protocol compatibility, authorization, or target-native acceptance.

Composition, not replacement.

A real task can cross each layer in sequence. None of the layers automatically completes the responsibility of the next.

01
Obtain capability through MCP
A research agent reads a knowledge base while an engineering agent invokes repository and test tools.
02
Coordinate another agent through A2A
A separate agent application can communicate capability, delegated task state, and resulting artifacts.
03
Organize application execution through a runtime
The application chooses routing, state transitions, recovery points, and human intervention.
04
Govern work through a harness
Constraints, ownership, evidence, findings, target readback, and acceptance remain linked to the work.

Choose from the gap, not from the label.

MCP

Tool integration is being rebuilt repeatedly

Use a common interface when AI applications need to discover and invoke data, tools, or prompt templates.

A2A

Agent applications are independent and cross-platform

Use a communication protocol when remote task exchange, task state, and structured artifact exchange are needed.

Framework

Application execution lacks a clear structure

Use a runtime when loops, graphs, handoffs, durable state, recovery, or human input need an explicit home.

Harness

A completion claim cannot survive scrutiny

Use governance when you need to know whether context drifted, a finding was repaired, and who accepted the real effect.

CLAIM BOUNDARY

Add a layer. Do not pretend it replaces every other layer.

Flowness is a public multi-agent harness project from the ToWow team. Its public Open Alpha demonstrates a narrow deterministic assurance-kernel proof with execution, independent review, targeted rework, and a fresh verdict for the successor candidate.

Complete Flow behavior, broad runtime behavior, production security, isolation, reliability, and scale need their corresponding versioned code and acceptance evidence. A target-native readback and explicit acceptance by the responsible party remain distinct from a protocol or runtime status.

ToWow and Flowness are a possible research composition, not a claimed current integration. This page does not claim that ToWow implements A2A, that every framework is integrated, or that A2A task completion is responsible-party acceptance.

Common questions from builders.

Can one system use all four layers?

Yes. A system can use MCP for tools, A2A for a remote agent interaction, a runtime for internal execution, and a harness for work identity, evidence, and acceptance. The layers are complementary, not competing product categories.

Does an A2A completed task mean the work is accepted?

No. A communication status describes the task lifecycle in that interaction. Acceptance needs the relevant work criteria, evidence, target-native readback where applicable, and an explicit decision from the responsible party.

Do orchestration frameworks make a harness unnecessary?

No. Frameworks can implement approval, tracing, and custom evaluation. The distinction here is that a harness makes work continuity and evidence governance explicit across handoffs and later acceptance, rather than inferring them from a completed application run.

Start with current primary sources.

Protocol and product scope can evolve. The linked sources support the stated boundaries, not an unverified integration or production deployment.

CONTINUE

Connect systems. Keep the evidence attached to the work.

Read the Harness guide Explore Flowness Understand trust boundaries Read the verification method