A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우

Multi-agent development does not improve with adding more agents. Adding more agents without contracting roles and deliverables only blurs responsibility and allows one agent's poor judgment to propagate to the next level.

So the starting point for multi-agent design is not “how many agents to have,” but who can do what, what input they receive, and what output they leave behind.

In Part 1, we summarized that coding agents should be viewed as runtime. In Part 2, we covered Goal Runtime. In this third part, we cover the structure of multiple agents working together. The key keywords are A2A and MCP.

Key takeaways

• MCP is closer to the Agent-to-Tool axis.
• A2A is closer to the Agent-to-Agent axis.
• Multi-agent development requires an Agent Card that explains “who can do what.”
• Tasks should be managed as Tasks with status, not as conversation messages.
• Results should be separated into Artifacts, not chat responses.
• In the development harness, you can borrow the Task/Artifact model even if you do not implement the entire A2A right away.

MCP and A2A solve different problems

In the AI ​​agent ecosystem, MCP and A2A are often mentioned together. But they don't solve the same problem.

[MCP Comparison of A2A Official Documents] (https://a2a-protocol.org/dev/topics/a2a-and-mcp/) explains that MCP deals with how agents use tools and resources such as databases and APIs, and A2A is a separate axis that enables agent-to-agent collaboration.

To summarize briefly, the axes are different.

Agent-to-Tool and Agent-to-Agent

If you miss this difference when creating a development harness, the structure will be messed up.

Here's something closer to MCP:

1read file2run test3Git diff lookup4Check DB schema5API Documentation Search

On the other hand, here's something that's more A2A:

1Request a Security Review Agent to review changes2Request a test agent to analyze a failing test3Request documentation agent to write migration note4Ask the performance analysis agent to clean up bottleneck candidates

MCP expands your capabilities. A2A separates responsibilities.

In your development harness, tool calls and task delegation should be handled separately as shown below.

Agent Card is the agent’s self-introduction.

[A2A Protocol v1.0 Announcement] (https://a2a-protocol.org/latest/announcing-1.0/) describes A2A as a stable, production-ready open standard for communication between AI agents. One of the important concepts in this protocol is Agent Card.

The Agent Card describes what capabilities the agent has, how it communicates, and what inputs and outputs it supports.

From a development harness perspective, the Agent Card can be viewed like this.

1{2  "name": "Code Review Agent",3  "description": "Review PRs with a focus on security, maintainability, and missing tests.",4  "skills": [5    "review-diff",6    "detect-risky-auth-change",7    "suggest-test-cases"8  ],9  "inputModes": ["diff", "file-list", "test-result"],10  "outputModes": ["review-artifact"],11  "requiresApprovalFor": [12    "suggest-db-migration",13    "modify-auth-policy"14  ]15}

Without an Agent Card, the Lead Agent cannot know what other agents are good at. Just as human teams need role definitions, agent teams also need role definitions.

A task is a unit of work with state.

A2A specification describes a task as a stateful unit of work processed by the A2A server. Tasks can have fields such as id, contextId, status, history, and artifacts.

In the development harness, Task can be interpreted as follows.

1Task:2id: review-payment-webhook-change3owner: security-review-agent4input:5- changed files6- payment webhook diff7- related tests8status: input_required9question:10It currently includes changes to the webhook signature verification logic.11Because the existing secret rotation policy cannot be verified, we will stop the implementation and request user approval.

The important state here isinput_required. We need a state where the agent does not make risky decisions directly but asks people to do so.

1Can I proceed?2Can I replace it with a mock?3Can I create DB migration?4Can I call an external API?

When this question disappears, automation becomes faster but riskier.

Artifact is a result that can be reviewed

Artifact is a result created by an agent. A2A v0.1 specification describes artifact as a tangible output generated during a task.

Artifacts are especially important in coding agents. Chat messages flow. Artifacts are reviewed.

In practice, the artifact contract is more important than the final response.

1Review Artifact:2Summary:3Reviewed payment webhook changes.4 5Blockers:6- There is no fallback path when signature verification fails.7 8Warnings:9- The retry policy is different from the existing payment API.10 11Verified:12- Passed 12 unit tests13- No change in webhook parser14 15Not Verified:16- No actual PG sandbox call is performed.

These artifacts must exist for human review.

Applying it to your development workflow

There is no need to complicate the multi-agent structure from scratch.

At the MVP stage, the following should be sufficient:

The key is not to split every agent into actual separate processes. Initially, you only need to separate roles within one agent.

1At this stage, it only acts as a Test Agent.2The goal is to analyze the cause of test failure.3Do not modify the code, but only leave test artifacts.

This method is simple but effective. When agents try to analyze, implement, test, and review all at once, their output becomes blurred. Dividing roles makes the results clearer.

Risks of Multi-Agent

Multi-agent is powerful, but it is also risky. [MetaGPT paper] (https://arxiv.org/abs/2308.00352) suggests that errors can propagate when simply connecting multiple LLM agents, and proposes an approach that forces SOP and modular output to reduce this. ChatDev paper also models software development as a collaboration of multiple communicative agents, but this structure requires roles, steps, conversation methods, and verification to work.

Practice risks include:

checklist

When designing a multi-agent structure, contracts below the number of agents come first.

1[ ] MCP and A2A roles were distinguished.2[ ] Defined Lead Agent responsibilities.3[ ] Defined the input and output of each Agent.4[ ] Records task status.5[ ] Artifact format was decided.6[ ] Ask the person a question in the input_required state.7[ ] The final judge was left as the Human Owner.8[ ] There is a Permission Gate for dangerous tasks.

Standards to be taken in this episode

MCP increases the tools available to agents, while A2A defines responsibilities that can be passed on to other agents. If you mix the two, the structure becomes blurred. Multi-agent MVP must first capture the Agent Card, Task status, and Artifact formats.

Next time

In Part 4, we move on to memory. In particular, we distinguish AI Memory from RAG and organize how failure logs and Run Ledgers should be handled.

Continue reading the series

• Part 1: Why are coding agents runtime?
• Part 2: Goal-based development through Codex/goal
• Part 3: Multi-agent development workflow from A2A and MCP perspective
• Part 4: AI Memory is not RAG
• Part 5: AI Coding Agent Document Set for Application to Development Harness

References

• Announcing Version 1.0 - A2A Protocol
• A2A and MCP - A2A Protocol
• A2A Protocol v0.2.6 Specification
• A2A Protocol v0.1.0 Specification
• MetaGPT: Meta Programming for Multi-Agent Collaborative Framework
• ChatDev: Communicative Agents for Software Development