For the last two years, AI engineering followed a simple script. Give an agent a prompt, some tools, and a memory layer. Watch it schedule a meeting, summarize a contract, or debug a script. The entire goal was to make a single agent useful on its own.
That goal has changed.
We are now watching the industry shift from solo agents to agent teams. A customer service triage bot identifies a refund request and routes the case to a payments agent. A research agent scraping web data hits a niche gap and delegates the task to a specialist sitting on a proprietary database. A logistics agent planning a shipment needs a real-time freight quote, so it asks a pricing agent for a number.
This sounds simple on paper. In practice, it is brittle.
The new challenge is interoperability. Teams build agents in different frameworks. Different vendors ship agents with different interfaces. When one company needs to work with another, the gap widens. We now have a landscape full of capable workers that lack a shared language. An agent cannot look up another agent in a directory. It cannot read a description of what its colleague does. And it cannot hand off a sensitive job without risking data leakage, context loss, or duplicate execution.
This is exactly the problem A2A is built to solve. It gives agents a common protocol for discovery, delegation, and secure collaboration.
From Single Agents to Agent Silos
The first wave of agent frameworks treated the boundary of the system as the boundary of the agent. You built a reasoning loop, gave it a tool belt, and hoped it could think its way through a workflow. That worked well enough when the agent stayed inside one codebase, one cloud account, or one vendor platform.
Real businesses do not operate inside monoliths. A refund request might start in a CRM, bounce into an internal payment service written in Python, and end in a fraud check hosted by a third party. When you model each of those services as an agent, you quickly realize that agents built on different stacks do not natively understand each other. Enterprise agents built on proprietary frameworks do not broadcast their capabilities to the outside world.
Without a standard, every integration becomes a custom project. Engineers write one-off glue code. Context gets lost in translation. Security policies become inconsistent, because each handoff is bespoke.
Agent Cards: A Public Resume
A2A introduces Agent Cards as a way for agents to announce who they are and what they can do.
Think of an Agent Card as a machine-readable résumé. An agent publishes a card that describes its domain, its required inputs, its expected outputs, and any constraints on the work it accepts. A payments agent might declare that it processes refund requests under a certain amount when provided with an order ID and a reason code, and that it returns either a confirmation number or an error. A data specialist might state that it accepts structured files up to a specific size and returns cleaned time-series data within a predictable window.
Before delegating work, a requesting agent reads the card. It understands whether the target agent is even capable of the job. It learns what format the payload needs. It knows whether it should expect a synchronous response or an asynchronous task that will finish later.
This removes guesswork. Instead of hardcoding integrations against every possible partner, an agent can browse available capabilities and choose the right teammate dynamically.
Tasks: Structured Work, Not Just API Calls
Agents do not need to chat like humans. They need to hand off jobs cleanly. A2A models this exchange as a Task.
A Task is more than