Most AI agent conversations eventually run into the same question:
What happens when one agent is not enough?
A single agent can write code, search docs, run tests, call APIs, summarize files, and generate reports.
That already feels useful.
But real work rarely fits into one neat box.
A software project might need:
- one agent to research requirements
- one agent to write code
- one agent to generate tests
- one agent to review the result
- one agent to deploy or monitor the system
A customer support workflow might need:
- a billing agent
- a technical support agent
- a sales agent
- a human handoff agent
A content workflow might need:
- a research agent
- a writing agent
- an SEO agent
- an editor
- a publishing assistant
At that point, the interesting problem is no longer just:
Can an agent use a tool?
It becomes:
Can agents work with each other?
That is where the A2A protocol becomes interesting.
And that is why the a2a-protocol skill on Terminal Skills is worth looking at.
MCP vs A2A in one sentence
MCP gave agents tools.
A2A gives agents coworkers.
That is the simplest way I think about it.
MCP, or Model Context Protocol, is mostly about connecting an agent to tools, APIs, files, databases, search systems, and external data sources.
A2A, or Agent2Agent, is about connecting one agent to another agent.
The difference matters.
If an agent needs to query a database, call a calendar API, or inspect a repo, MCP is a good fit.
If an agent needs to delegate work to another autonomous agent with its own capabilities, state, task lifecycle, and output format, A2A is the better mental model.
A tool usually does one specific thing.
An agent can own a whole domain of work.
Why agents need a collaboration layer
Right now, many agent workflows are still stitched together with prompts.
Something like:
First research the topic.
Then write a draft.
Then review it.
Then create a final version.
That can work for small tasks.
But it gets messy as soon as the workflow becomes more serious.
What happens when research takes five minutes?
What happens when the writing agent needs structured data, not a paragraph?
What happens when the reviewer rejects the output?
What happens when the task needs human input?
What happens when the work should continue asynchronously?
At that point, a prompt chain is not enough.
You need something closer to a protocol.
The A2A model introduces concepts like:
- an Agent Card for discovery
- declared skills and capabilities
- task lifecycle states
- messages between agents
- artifacts as outputs
- streaming updates
- push notifications
- cancellation
- structured data exchange
That sounds boring in the best possible way.
Boring protocols are what turn demos into infrastructure.
The Agent Card is the underrated part
One of the most useful ideas in A2A is the Agent Card.
An Agent Card is basically a description of what an agent is, where it lives, and what it can do.
It describes identity, capabilities, skills, endpoints, and auth without exposing the agent's internal tools, memory, or private state.
It can include:
- the agent name
- description
- endpoint URL
- version
- capabilities
- skills
- input modes
- output modes
- authentication requirements
A standard discovery endpoint like this:
/.well-known/agent-card.json
may not sound exciting.
But it solves a real problem.
If agents are going to collaborate, they need to know who they are talking to.
A coding agent should be able to discover a code review agent.
A support router should be able to discover a billing agent.
A research agent should be able to discover a writer agent.
Without a discovery layer, every multi-agent workflow becomes custom glue.
With one, agents can start to behave more like services.
Example: a code pipeline made of agents
Imagine a simple software pipeline.
You do not want one giant agent doing everything.
Instead, you split the workflow:
- Code writer generates the implementation.
- Test writer creates tests.
- Code reviewer checks both.
- Orchestrator coordinates the flow.
Each agent can have a narrow responsibility.
The code writer does not need to know everything about test strategy.
The test writer does not need to own product requirements.
The reviewer does not need to write the initial implementation.
This makes the workflow easier to inspect.
If the tests are weak, improve the test agent.
If the review is shallow, improve the review agent.
If the handoff fails, improve the orchestrator.
That is much cleaner than debugging one giant prompt with five hidden roles inside it.
Example: a customer support router
A2A also makes sense for support.
A support router agent receives a customer message:
I was charged twice and my account still says inactive.
The router should not try to solve everything itself.
It can delegate:
- billing question -> billing agent
- account activation -> technical agent
- refund eligibility -> policy agent
- unclear or sensitive issue -> human handoff
The router's job is classification, coordination, and response assembly.
The specialized agents own their own domains.
This is how real teams work.
Not everyone does everything.
The interesting part is making agents follow that same pattern.
Where Terminal Skills fits
This is where Terminal Skills becomes useful.
The a2a-protocol skill is not just a link to a spec.
It gives an AI coding agent a practical operating guide for building A2A systems:
- when to use A2A
- how to define an Agent Card
- how to build a server
- how to build a client
- how to handle task states
- when to use streaming
- how to orchestrate multiple agents
- how A2A differs from MCP
- what implementation guidelines to follow
That matters because agents often fail not from lack of intelligence, but from lack of workflow structure.
A model may understand A2A in general.
But a skill gives it a repeatable path:
terminal-skills install a2a-protocol
After that, the agent has a focused reference for the task instead of relying on vague memory or generic web knowledge.
This is the bigger idea behind Terminal Skills:
Agents do not just need more context. They need reusable operational instructions.
A2A is not a replacement for MCP
It is tempting to turn every new protocol into a winner-takes-all comparison.
I do not think that is the right framing here.
A2A and MCP solve different problems.
A practical way to separate them:
| Need | Better fit |
|---|---|
| Call a tool or API | MCP |
| Read from a data source | MCP |
| Give an agent access to external systems | MCP |
| Delegate a task to another agent | A2A |
| Discover agent capabilities | A2A |
| Coordinate long-running agent work | A2A |
MCP is agent-to-tool.
A2A is agent-to-agent.
In real systems, you probably want both.
An agent might use MCP internally to access tools, while exposing an A2A interface so other agents can delegate work to it.
That combination is where things get interesting.
What makes this useful for developers
For developers, the value is not the protocol acronym.
The value is fewer fragile workflows.
Instead of hardcoding every handoff, you can start thinking in terms of:
- discoverable agents
- declared capabilities
- explicit task states
- structured messages
- cancellable work
- streaming progress
- artifacts as outputs
That is closer to software engineering than prompt engineering.
And honestly, that is the point.
The next generation of agent systems will not be built from one giant prompt.
They will look more like networks of specialized workers with clear contracts between them.
Some of those workers will call tools.
Some will call other agents.
The quality of the system will depend less on one model being magical and more on whether the handoffs are well designed.
The small shift that matters
The first wave of AI agents was about giving models tools.
That was a huge step.
But tools are not the whole story.
If agents are going to handle real work, they need coordination.
They need delegation.
They need discovery.
They need contracts.
They need ways to say:
I can do this task.
Here is how to call me.
Here is what I return.
Here is how I report progress.
Here is how I fail.
That is why A2A is worth watching.
Not because every project needs a multi-agent architecture today.
Most do not.
But because the direction is clear:
Agents are moving from isolated assistants to interoperable workers.
MCP gave agents tools.
A2A gives them coworkers.
And skills like a2a-protocol help agents learn how to build that future without starting from a blank prompt.
If you want to try it, the skill is here:
https://terminalskills.io/skills/a2a-protocol
Install:
terminal-skills install a2a-protocol
Then ask your coding agent to build one tiny A2A loop: Agent Card -> server -> client -> delegated task.
Start small.
One focused agent.
One clear capability.
One verifiable handoff.
That is usually where the real workflow begins.
