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.
| division | MCP | A2A |
|---|---|---|
| Connect to | Tools, API, DB, file system | another agent |
| key questions | What can this agent be used for? | Who can this agent delegate work to? |
| main purpose | tool/resource access | agent collaboration |
| Development harness application | Test execution, file search, DB inquiry | Delegate code reviews, test analysis, and documentation |
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:
read filerun testGit diff lookupCheck DB schemaAPI Documentation SearchOn the other hand, here's something that's more A2A:
Request a Security Review Agent to review changesRequest a test agent to analyze a failing testRequest documentation agent to write migration noteAsk the performance analysis agent to clean up bottleneck candidatesMCP 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.
{ "name": "Code Review Agent", "description": "Review PRs with a focus on security, maintainability, and missing tests.", "skills": [ "review-diff", "detect-risky-auth-change", "suggest-test-cases" ], "inputModes": ["diff", "file-list", "test-result"], "outputModes": ["review-artifact"], "requiresApprovalFor": [ "suggest-db-migration", "modify-auth-policy" ]}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.
Task:id: review-payment-webhook-changeowner: security-review-agentinput:- changed files- payment webhook diff- related testsstatus: input_requiredquestion:It currently includes changes to the webhook signature verification logic.Because 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.
Can I proceed?Can I replace it with a mock?Can I create DB migration?Can 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.
| bad result | Good Artifact |
|---|---|
| “I fixed it” | Change File List |
| “I passed the test” | Execution commands and log summary |
| “It doesn’t seem like a problem” | Blocker, warning, suggestion classification |
| “I’ll remember it” | memory candidate with source, scope, validated_at |
In practice, the artifact contract is more important than the final response.
Review Artifact:Summary:Reviewed payment webhook changes. Blockers:- There is no fallback path when signature verification fails. Warnings:- The retry policy is different from the existing payment API. Verified:- Passed 12 unit tests- No change in webhook parser Not Verified:- 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:
| role | explanation |
|---|---|
| Lead Agent | Decompose goals, determine execution order, and final summary |
| Implementation Agent | code fix |
| Test Agent | Test creation and failure analysis |
| Review Agent | Review of risks and omissions |
| Human Owner | Approval, distribution, final merge decision |
The key is not to split every agent into actual separate processes. Initially, you only need to separate roles within one agent.
At this stage, it only acts as a Test Agent.The goal is to analyze the cause of test failure.Do 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:
| risk | explanation | react |
|---|---|---|
| Unclear responsibility | Not sure who makes the final decision | Separation of Lead Agent and Human Owner |
| Error propagation | Incorrect analysis by one agent is passed on to the next step | Add artifact review step |
| excessive automation | Performing hazardous tasks without authorization | Permission Gate |
| Output mix | Conversation and results are mixed | artifact contract |
| increased cost | Multiple agent repeated calls | Task budget settings |
checklist
When designing a multi-agent structure, contracts below the number of agents come first.
[ ] MCP and A2A roles were distinguished.[ ] Defined Lead Agent responsibilities.[ ] Defined the input and output of each Agent.[ ] Records task status.[ ] Artifact format was decided.[ ] Ask the person a question in the input_required state.[ ] The final judge was left as the Human Owner.[ ] 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
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.