A2A

How Independent AI Agents Work Together: An A2A Bridge for Hermes Agent

By IdeaBosqueLast updated: July 24, 2026

What this means for your business

Your agents cooperate without a rewrite. The Agent2Agent Protocol (A2A) is an open standard for AI agents to discover, delegate to, and stream work between each other. A thin bridge lets an existing agent speak that standard without changing its internals — you keep the investment you already made.
No vendor lock-in. Because the bridge sits between the standard and the agent, you can swap the underlying agent framework later without breaking the integrations built on top of it. Other teams keep calling the same standard endpoint.
One system serves many customers or business units — with hard data separation. Tenant isolation is enforced at the database level, not just in application code, so a coding mistake cannot leak one customer's data to another. That is the difference that survives a security review.
Humans stay in control of sensitive actions. When an agent needs sign-off — a purchase, a data-access decision, a quote approval — the request surfaces as a standard "waiting for approval" state that carries all the way back to the person or agent that started the chain, even across framework boundaries.
It is real and tested, not a slide. The whole thing is packaged as an open-source deployment (docker-a2a-hermes-agent-gateway) with an automated test suite that proves each capability before you depend on it.

The problem: agents that can't talk to each other

Most organizations don't adopt "one AI agent." They accumulate several. A quoting agent here, a catalog-lookup agent there, an inventory agent owned by a different team — often built on different frameworks, sometimes from different vendors, at different times. Individually they work. The bottleneck is getting them to cooperate: to hand work to one another, wait for a result, and pass control back.

Solving that by hand-wiring each agent to every other agent is slow, brittle, and gets worse with every new agent. It also quietly locks you in — the moment integrations are hard-coded to one vendor's interface, replacing that vendor means re-doing all of them.

The Agent2Agent Protocol (A2A) is the open standard that removes that bottleneck. It defines a common language for agents to discover each other, delegate tasks, stream progress, and report completion — regardless of what each agent is built on. Adopt the standard once, and every new agent speaks the same language as the rest.

The catch: your existing agents don't speak A2A natively. Hermes Agent from Nous Research, for example, exposes its own interface. Rewriting a working agent to add a new protocol is exactly the kind of expensive, risky project teams want to avoid.

The answer is a bridge — a small translation layer that speaks A2A on the outside and talks to the agent in its own language on the inside. The agent never changes. The docker-a2a-hermes-agent-gateway project is a working, open-source example of that bridge, packaged so it can run as a single deployable unit.

How the pieces fit

There are three moving parts, and only one of them is ever exposed to the outside world:

The front door (the gateway). Everything comes in through one controlled entry point. It decides who is allowed in, which customer a request belongs to, how fast callers may go, and how live progress is streamed back. Nothing else is reachable directly.
The translator (the bridge). It receives requests in the open A2A standard and turns them into whatever your agent actually understands — then turns the answer back. This is the only piece that knows anything about the specific agent, which is exactly why the agent can be swapped later.
The agent and its record of work. Your existing agent does the real reasoning. Everything it does is written down — every task and message — kept strictly separated by customer.

Because the front door and the record-keeping are separate from the agent itself, you can keep the gateway inside your own cloud and point it at an agent running somewhere else, or at a managed database of your choosing. Nothing forces all three into the same place.

Adopt the standard without rewriting your agents

The single most valuable property here is that your agent never changes. The translator does all the work of speaking the standard on its behalf.

That has two direct business consequences:

You protect the investment you already made. The team that built the quoting agent doesn't stop to re-engineer it for a new protocol. They add a bridge and move on.
You avoid lock-in in both directions. Callers depend only on the open standard, not on your agent vendor. If you later replace the agent — a better model, a cheaper provider, an in-house build — the translator changes and every integration built on top keeps working untouched. Conversely, one gateway can front several different agents at once: reasoning-heavy work routed to one, routine workflow steps to another, all looking identical to whoever is calling. The choice of engine becomes an implementation detail you control, not a commitment you're stuck with.

Serve many customers or business units — with data separation that survives an audit

The same deployment can serve many tenants — separate customers, or separate internal business units — from one running system. Each gets its own agents, its own task history, and its own message record.

What makes this safe rather than merely convenient is where the separation is enforced. Every request is tagged with which customer it belongs to, and the database itself refuses to return one customer's rows to another — a control enforced at the data layer, below the application code. In practice this means a bug or a forgotten filter in the software cannot leak data across customers, because the database is the backstop, not the application. That is the distinction a security or compliance reviewer looks for, and the one that lets you put multiple clients on shared infrastructure without putting their data at risk.

Keep humans in control of sensitive actions

Autonomy is only acceptable when a person can intervene at the moments that matter. When an agent reaches a step that needs sign-off — authorizing a purchase, approving a quote, releasing sensitive data — it doesn't just proceed. It pauses and raises a standard "waiting for approval" state.

The important part is that this state travels. A request that started several agents away — possibly on a completely different framework, owned by a different team — receives that same "input required" signal, unchanged. A human approves (or declines), and the work resumes. Governance doesn't stop at the boundary of one agent; the open standard carries the approval gate across the whole chain. For any workflow touching money, contracts, or regulated data, that end-to-end control is what makes agent delegation defensible rather than reckless.

Run it where your data has to live

The deployment is a single, self-contained package that can run bundled — agent, database, and gateway together — for a quick start, or split apart for production. You can keep the controlled front door inside your own network and point it at a managed database (so backups, encryption, and compliance are handled by your cloud provider) and at an agent running on separate hardware.

For businesses with data-residency or sovereignty requirements, this matters: the record of every agent interaction can be kept inside the boundary your policies require, rather than in a third party's cloud you don't control.

Proven before you depend on it

A capability you can't verify is a liability. This deployment ships with an automated test suite that exercises the real, running system end to end — confirming that agents can be discovered, that requests complete, that live progress streams correctly, that a client which misses a live update can still retrieve the full result, and that failures and cancellations behave as expected. The tests report a clear pass or fail on each check and are designed to run as an automated gate, so a broken change is caught before it reaches production rather than after.

The practical value is risk reduction: you are not taking anyone's word that the integration works. It is demonstrated, repeatably, on every change.

What running it in production actually takes

Being honest about operating cost is part of the business case. A few realities worth planning for:

It is designed to run lean, then scale deliberately. The default is a single, simple deployment. Serving very high volume across multiple copies is supported but is a deliberate step, not an accident — it needs shared infrastructure so the copies stay consistent. Plan the scale-up; don't assume it's free.
Keeping current is a routine, not a rewrite. The building blocks are pulled from their open-source sources, so staying up to date is a standard refresh operation your team runs on a schedule.
The security posture is yours to set. The package ships with placeholder passwords and permissive defaults so it starts easily out of the box — these are meant to be replaced before it faces the internet. The optional bundled agent is powerful and should only run on infrastructure you trust. None of this is exotic; it is the normal hardening any production system needs, and it should be on the go-live checklist.

None of these are blockers. They are the ordinary responsibilities of running a real system, and naming them up front is how you avoid surprises after launch.

What this enables

Put together, the bridge pattern delivers three things that are genuinely hard to assemble on your own:

1. Standards-based cooperation without a rewrite. Any agent that speaks A2A can work with your existing agent immediately — discovering it, delegating to it, and tracking its progress — without that agent being modified. You adopt an open standard while keeping what already works.

2. Multi-tenant service with real isolation. One deployment serves many customers or business units, with data separation enforced at the database level. That is what lets you consolidate onto shared infrastructure without weakening security.

3. Governed autonomy across boundaries. Human approval gates travel with the work, so sensitive actions get a human in the loop no matter how many agents — or how many frameworks — the request passed through.

The working implementation is open source and fully documented: the bridge and its integration guide live in the a2a_daemon_engine repository (see the Hermes integration guide), and the controlled front door is documented in the SilvaEngine Gateway repository. The complete deployment is packaged in docker-a2a-hermes-agent-gateway.