Skip to content

feat(bindu): A2A microservice adapter for agent-to-agent calls#14559

Closed
raahulrahl wants to merge 4 commits into
NousResearch:mainfrom
raahulrahl:feat/bindu-adapter
Closed

feat(bindu): A2A microservice adapter for agent-to-agent calls#14559
raahulrahl wants to merge 4 commits into
NousResearch:mainfrom
raahulrahl:feat/bindu-adapter

Conversation

@raahulrahl

Copy link
Copy Markdown

What this adds

An optional adapter that lets you run Hermes as an A2A (Agent-to-Agent) microservice. Where hermes gateway makes Hermes talk to humans on Telegram/Discord/Slack/etc., hermes-bindu makes it talk to other agents over the open A2A JSON-RPC protocol — with a cryptographic DID identity, OAuth2 auth, and optional x402 micropayments.

Same agent, same skills, same memory, new interface. ~200 lines of glue.

pip install -e '.[bindu]'
hermes-bindu                           # → http://localhost:3773 (A2A)

Why would Hermes users want this?

Hermes is already excellent at the human-facing surface. What this unlocks is the other direction:

  • Let other agents call Hermes. A LangChain or AG2 agent can delegate a research task to Hermes and get back a DID-signed artifact — no one has to write an HTTP client for Hermes' internals. A2A is becoming a standard interop layer.
  • Cryptographic identity. Every response is Ed25519-signed by the agent's DID key, so the caller can verify authenticity without shared secrets.
  • OAuth2 with scopes. Ships with Ory Hydra integration and agent:read / agent:write / agent:execute scopes.
  • Monetization without Stripe. x402 support means you can charge 0.01 USDC per call with one config flag.

It's additive, not a replacement for the gateway. All three (hermes, hermes gateway, hermes-bindu) can run against the same config and share skills, memory, tools, and context files.

Scope I kept deliberately small

This touches five things, and only one of them isn't new:

Change Notes
bindu_adapter/ (new) Adapter code + detailed README. Mirrors the existing acp_adapter/ pattern.
pyproject.toml New [bindu] extra and hermes-bindu script. Added hermes-agent[bindu] to the [all] extra alongside [acp].
.gitignore Added .bindu/ — Bindu writes per-agent DID keys and OAuth creds there; never commit.
README.md One short section pointing at bindu_adapter/README.md. I did not add a hermes bindu subcommand in hermes_cli/main.py — happy to in a follow-up if you want parity with hermes acp, but I wanted to keep this PR reviewable.
(not touched) hermes_cli/main.py, run_agent.py, anything in agent/ Adapter is purely additive.

Design choices worth calling out

  • No hard dep on Bindu. It's an optional extra. Base pip install hermes-agent is unchanged. If a user runs hermes-bindu without installing the extra, they get a clean error pointing at the install command, not a stack trace.
  • Single AIAgent per process. The handler keeps one long-lived AIAgent so the provider's prompt cache stays valid across A2A calls. Bindu is the source of truth for conversation history; Hermes owns the live model state.
  • Safety tiers via HERMES_BINDU_TIER. Defaults to read (web search + extract only). sandbox adds file + moa. full exposes everything including terminal and code-exec — the adapter README calls out that you must never combine full with the public FRP tunnel.
  • Env config follows ~/.hermes/.env. Same dotenv loading as run_agent.py so users don't maintain two env files. Adapter-specific knobs use the HERMES_BINDU_* prefix.

What I tested

  • Full A2A round-trip locally: message/send → poll tasks/get → DID-signed artifact returned with correct answer.
  • Confirmed the adapter starts cleanly with no Bindu config beyond an OPENROUTER_API_KEY.
  • python -m bindu_adapter and hermes-bindu entry points both work.
  • Verified ImportError branch prints the install hint.

Things I'd love a reviewer to push back on

  • Should hermes bindu be a subcommand now? I left it out to minimize the diff against hermes_cli/main.py, but if you'd prefer parity with hermes acp in this PR I can add it — it's ~20 lines.
  • Version pin for bindu. I used >=0.3.18. Happy to tighten to ~=0.3.18 if you want stricter.
  • README section placement. I put it between "CLI vs Messaging" and "Documentation" because it's logically a third interface. Move it anywhere you prefer.
  • The long adapter README. It's currently ~200 lines with diagrams. If you'd rather that live on hermes-agent.nousresearch.com/docs instead of in-tree, happy to port it.

Thanks for the review — excited to see Hermes on the A2A network.

Adds an optional adapter that exposes Hermes' AIAgent as a Bindu A2A
microservice — same agent, same skills, same memory, new interface.
Where `hermes gateway` makes Hermes talk to humans on messaging
platforms, `hermes-bindu` makes it talk to other agents over the open
A2A JSON-RPC protocol with a cryptographic DID identity, OAuth2 auth,
and optional x402 micropayments.

Scope is deliberately small:
  - New `bindu_adapter/` directory, ~200 lines of glue.
  - New `[bindu]` extra in pyproject and `hermes-bindu` entry point.
  - Short section in the top-level README pointing at the adapter's
    own detailed README for the full story.
  - `.bindu/` added to .gitignore (Bindu writes per-agent DID keys
    and OAuth credentials there; never commit).

Nothing in existing install paths changes — base Hermes is untouched,
and the adapter only activates when a user opts in with
`pip install -e '.[bindu]'` and runs `hermes-bindu`.
Without this, `pip install -e '.[bindu]'` installs the [bindu] extra but
setuptools skips the bindu_adapter package itself — the hermes-bindu
console script then fails with `ModuleNotFoundError: No module named
'bindu_adapter'` on first invocation. Caught while testing the adapter
end-to-end. Mirrors how acp_adapter is listed.
@raahulrahl raahulrahl marked this pull request as draft April 23, 2026 13:32
Compress from ~210 lines to ~110 for faster review. Lead with a
"Verified working" table showing both the no-auth and auth-on round-trip
results, plus an abridged boot log excerpt so reviewers can see the
full auth stack came up cleanly. Drops the longer explanatory prose
from the value-prop section in favor of a crisper two-line
"additive, not replacement" framing, since the top-level README
already pitches the why.
Surface the Bindu source repo and its tagline up front so a reviewer
skimming the adapter README lands on the project context immediately,
without scrolling to the Links section. Also adds the docs URL to the
bottom Links list for completeness.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/acp Agent Communication Protocol adapter labels Apr 23, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #4135, #11025, and tracking issue #514 — multiple prior A2A protocol PRs. This one takes a different approach (Bindu adapter with DID/OAuth2/x402).

@raahulrahl

Copy link
Copy Markdown
Author

Thanks @alt-glitch — useful pointer, I wasn't tracking #4135 or #11025 when I opened this. Landscape as I understand it now:

What's genuinely different here rather than overlapping:

  1. Ed25519-signed artifacts + DID per agent — W3C-standard cryptographic identity on every response. Neither feat: add A2A (Agent-to-Agent) protocol integration #4135 nor feat: add A2A (Agent-to-Agent) protocol support #11025 has this.
  2. OAuth2 scopes (agent:read/write/execute) via Ory Hydra — not just bearer-token gated.
  3. x402 USDC micropayments — one flag and the agent charges per call.

Happy to retarget onto whichever A2A foundation lands first (this adapter would slot on top as an opt-in identity/auth/payments layer), or close if maintainers prefer a single-path solution. No strong opinion on the order — deferring to whatever direction you pick on #514.

@raahulrahl raahulrahl marked this pull request as ready for review April 23, 2026 13:41
@Ridwannurudeen

Copy link
Copy Markdown

Thanks @raahulrahl — clean breakdown. Three genuinely different shapes in one frame:

A layered path that wastes nothing:

  1. Gateway session model from feat: add A2A (Agent-to-Agent) protocol support #11025 as the foundation
  2. Orchestration from feat: add A2A (Agent-to-Agent) protocol integration #4135 on top — after feat: add A2A (Agent-to-Agent) protocol support #11025 lands, Hermes itself becomes an A2A endpoint that a2a_orchestrate could include in its target pool
  3. Bindu from feat(bindu): A2A microservice adapter for agent-to-agent calls #14559 as opt-in identity/auth/payments

@teknium1 — happy to coordinate merge order if you want to sequence rather than pick one.

@iamagenius00

Copy link
Copy Markdown
Contributor

Thanks @raahulrahl and @Ridwannurudeen for the detailed comparison — very helpful to see all three approaches side by side.

Quick update on #11025: we've shipped a v2 since the original PR. The architecture has changed significantly.

What changed:

The original #11025 required patching Hermes gateway source code — modifying gateway/run.py, gateway/config.py, pyproject.toml, etc. to register A2A as a platform adapter. That worked but was fragile across Hermes versions.

v2 is a hybrid plugin — 7 files dropped into ~/.hermes/plugins/a2a/, zero gateway patches, zero external dependencies (stdlib http.server + urllib.request only). The plugin runs its own ThreadingHTTPServer in a background thread and registers pre_llm_call/post_llm_call hooks.

The key addition is instant wake via webhook: when an A2A message arrives, the plugin POSTs an HMAC-signed webhook to Hermes' internal endpoint, triggering an immediate agent turn. The entire request → queue → webhook → agent processes → response cycle completes synchronously within the same HTTP call (120s timeout). No polling delay.

Other improvements since the original PR:

  • Security module consolidated (was duplicated across gateway adapter and client tools), now 9 injection patterns (added ChatML tokens, role prefixes, disregard/override variants)
  • tasks/get responses now go through filter_outbound() (was leaking raw responses)
  • Metadata sanitization on sender_name and structured fields
  • Bounded task cache with LRU eviction (prevents memory exhaustion)
  • Conversation persistence to ~/.hermes/a2a_conversations/

Updated repo: https://github.com/iamagenius00/hermes-a2a (README rewritten to reflect v2)

The session-injection design @Ridwannurudeen highlighted is still the core — A2A messages go into the agent's live session, not a clone. The difference is it no longer requires touching Hermes source to make that work.

Re: @raahulrahl's DID/OAuth2/x402 — those are genuinely orthogonal features. Cryptographic identity and payment rails aren't something #11025 or #4135 attempt. Could see those layering on top of any of the three approaches.

@Ridwannurudeen

Copy link
Copy Markdown

v2's plugin shape further reduces integration friction with #4135 — no gateway patches to coordinate around.

One coordination point worth surfacing for @teknium1: a2a_discover / a2a_call / a2a_list exist in both #11025 and #4135. Whichever lands first should own them; the other should defer to avoid duplicate registration. #4135's distinctive piece — a2a_orchestrate (modes all / first / best with skill matching) — would still slot on top either way.

Server-side, v2's plugin and #4135's a2a_adapter are genuinely different shapes (live-session injection vs session-per-task ThreadPoolExecutor) and could ship as separate run modes rather than one displacing the other.

The DID/OAuth2/x402 layer from #14559 attaches to either, agreed.

@teknium1

teknium1 commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Closing in favor of #41711, which consolidates the entire A2A protocol cluster into a single platform-adapter plugin with zero core edits.

This pr contributed the bindu microservice-adapter direction. The 'same agent, new interface' framing informed the inbound adapter. DID/Ed25519 identity, OAuth2 scopes and x402 micropayments are noted as future scope in the new plugin's DESIGN.md rather than dropped. Thanks @raahulrahl!

See #41711 — the PR body has a table tracing each requirement back to its source issue/PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/acp Agent Communication Protocol adapter P3 Low — cosmetic, nice to have type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants