Agents That Answer
Each Other

Peer-to-peer A2A for Amplifier, with a human in control

The isolation problem

A powerful agent that can't reach any other agent

An Amplifier session is capable on its own machine, but isolated. amplifier-bundle-a2a (microsoft/) implements Google's A2A protocol over peer-to-peer HTTP so two sessions can finally discover, message, and collaborate.

The capability is real — and it is substantial.

Before: an agent is powerful locally but cannot reach any other agent, on the machine or across the network.

After: two sessions talk over peer-to-peer HTTP using Google's Agent-to-Agent protocol.

Shipped, not a demo

Real code: two modules, backed by hundreds of tests

This is production Python across two shipped modules — a client tool and a server hook — with a substantial test suite, built over months of commits.

So how do two sessions actually reach each other?

2,328

lines of production Python

2

modules: client tool + server hook

308

test functions across 21 files

28

commits since 2026-02-23

The peer-to-peer wire

Every session becomes a peer — no central broker

Each session serves an Agent Card and receives messages directly over aiohttp. Peers talk to each other, not through a hub.

But opening that door has a cost.

# Each session serves, over aiohttp
GET  /.well-known/agent.json   Agent Card
POST /a2a/v1/message:send      receive
GET  /a2a/v1/tasks/{task_id}   status

The real problem isn't connection

A message from another agent is a request to run on your machine

Opening a peer-to-peer door is dangerous. Letting a remote agent talk to yours means letting it reach your machine — connection without control is a liability, not a feature.

So the first thing the bundle does is nothing.

Gate one — silence

Dormant by default; unknown senders blocked

The server is inert until you explicitly enable it per directory. Even then, a sender you haven't approved goes nowhere. Nothing runs until you say so.

Once a peer is let in, the next question is how much it can do.

enabled: false — master switch off by default; no HTTP server, no mDNS until set true, per directory.

Unknown senders blocked — a non-known sender is queued for approval before anything runs.

Access is earned, not assumed

Trust tier — not the sender — decides how much a peer can do

Once a peer is let in, its power is set by trust tier. Trusted peers get autonomy and full tools; known peers are scoped to tool-filesystem and tool-search. The sender doesn't get to choose.

That scoping is what makes autonomous answers safe.

unknown

blocked pending your approval

known · Mode A notify-and-wait

scoped to tool-filesystem + tool-search

trusted · Mode C autonomous

tools *

Confidence-gated autonomy

Autonomy exists — but it's confidence-checked and attributed

A trusted message is answered in a sandboxed child session scoped to its tier. If a confidence check fails, the answer is discarded and escalated to the human — and attribution records who really replied.

So collaboration never costs control.

1

Answer runs in a sandboxed child session, scoped by trust tier.

2

Low confidence → answer discarded and escalated to the human.

3

Attribution on every reply: autonomous · user_response · escalated_user_response · dismissed.

The pattern, generalized

Safe A2A collaboration is a chain of explicit gates

Connection is the easy part. Control is the design. Dormant, blocked, scoped, confidence-checked, attributed — at every step the default keeps a human in charge.

Connection is easy; control stays human.

Dormant — enabled: false by default

Blocked — unknown senders pending approval

Scoped — tools set by trust tier

Confidence-checked — low confidence discarded and escalated

Attributed — every reply records who answered

Sources

Sources & Research Methodology

Data as of: 2026-06-15 (most recent commit). Feature status: Active — implemented and shipped.

Repository: microsoft/amplifier-bundle-a2a, branch main, HEAD 14e5cc6. Verified from a fresh clone whose remote is the primary source repo; no local working copy exists under /home/ramparte/dev/ANext.

Research performed:

Repo: gh repo view microsoft/amplifier-bundle-a2a
Commits: git log --oneline | wc -l (28); first/most-recent via git log --reverse --format="%ai %an %s"
Contributors: git shortlog -sne --all → Brian Krabach 25, Salil Das 3
Production lines: find ./modules -name '*.py' -not -path '*/tests/*' | xargs wc -l (2,328)
Tests: grep -rh 'def test_' --include='*.py' . | wc -l (308) across 21 files
Endpoints: grep of server.py router + from aiohttp import web
Trust tiers: _get_tools_for_tier in server.py + README trust_tiers
PRs: gh pr list --repo microsoft/amplifier-bundle-a2a --state all (6 merged: #1,#2,#3,#4,#7,#8)

Gaps / caveats: README documents 290 tests; measured current count is 308 (cited). README references a demo_a2a.py that is absent from the repo tree — no runnable demo shipped. Tests were counted statically (def test_), not executed.

Primary contributors: Brian Krabach (25 of 28 commits), Salil Das (3).

Agents That AnswerEach Other