A2A agents: let other systems hand work to your agent

So far we have talked about agents that work with a person in front of them: someone opens Codex or Claude Code and asks it for something. But there is another increasingly common case: the request comes from another system. An incoming ticket, a nightly job, another agent that needs yours to review a deployment.

That is what A2A (agent-to-agent) is for: an open protocol for one agent to send a task to another and follow its status.

A2A in two pieces

• The Agent Card, a public document at /.well-known/agent-card.json that says who the agent is, what it can do and how to authenticate to talk to it.
• message/send, the JSON-RPC call used to send it a message. The response is a task with its status: completed, working, or waiting for something.

The same agent, somewhere else

In Ploybot, an A2A agent is not a different kind of agent. It is the same one you already have in the catalogue, with its identity, capabilities, policy and history. What changes is where it reasons: instead of a person’s laptop, it runs in a runtime inside your cloud account.

The agent’s recipe says which prompt it uses, with which model, which MCP tools it has and how much it may spend. ploybot deploy takes it to your account: AWS Lambda, an ECS Fargate service or Azure Functions. Cloud credentials and the model key are requested at that moment and stay in your account (Secrets Manager or the Function App settings), not in the Ploybot catalogue.

Who can hand it work

The Agent Card is public, because it is discovery. But message/send requires a Bearer token. The deployment generates that token, stores it in your account and shows it to you once. Without it, the runtime answers 401 and spends nothing. And if no token is configured, the runtime simply does not start: leaving it open has to be an explicit decision, not an oversight.

Model spend is not a tool

There is a design detail that matters. If the model itself had to request its budget over MCP, it would either never ask or end up counting itself. That is why the runtime reserves the spend before each model call, against the control plane. If the reservation is not granted, there is no call.

Sensitive actions still wait for a person

The A2A agent’s tools are the usual ones, over MCP, under the same policy. When something needs approval, the A2A task moves to auth-required. Whoever decides gets notified as with any other operation, and once they approve, the caller retries the same message and the task carries on.

If the recipe names a verified AI endpoint, Prompt Shield runs inside the runtime itself: it checks every prompt, obfuscates personal data in strict mode and records in the evidence that it did so.

Try it from the browser

The console has an A2A chat at /console/a2a/. Give it the URL of the agent or its Agent Card and talk to it: you see the task states, the replies and the JSON of each one. If the agent is yours and you have access, the console obtains a short-lived grant from your session and you do not have to handle the Bearer. It also works for testing A2A agents outside Ploybot.

And between your own agents?

When the caller is another of your agents, Ploybot adds one more rule: there has to be an explicit policy saying agent X may invoke agent Y. If X delegates a capability to Y, Y receives a new grant that says so, and everything it does with it goes through policy, approval and the gateway again. And it does not impersonate X: it is still Y, and that is what gets recorded.

Get started

Create an account, set up an agent and try the console’s A2A chat. If you want to take it to your AWS or Azure account, write to us and we will prepare it with you.