Bindufy a research agent with cryptographic identity, A2A messaging, and x402 USDC payments

What they did

They had a working Agno research agent (OpenAI model plus DuckDuckGo search tools) and wanted it reachable by other agents without hand-rolling identity and payment plumbing. Instead of integrating a DID library, an OAuth flow, payment middleware, and an A2A-compliant HTTP layer separately, they installed Bindu with `uv add bindu`, kept the handler as a simple `(messages) -> response` function, and passed the agent to `bindufy()`. That single call brought the agent online with its own cryptographic identity, A2A protocol support so other agents could address it, and x402 payment gating so it can demand USDC on an EVM chain before doing work. They set an LLM provider key (OPENROUTER_API_KEY, OPENAI_API_KEY, or MINIMAX_API_KEY), ran the script, and then used the Bindu inbox walkthrough to watch signed JSON-RPC traffic between agents, verify identities inline, and reply to a swarm as if it were an email thread. The framework inside the handler stayed swappable — Agno here, but LangChain, CrewAI, or custom code would work the same way.

How it went

The agent went from a local script to a network-addressable, identity-bearing, payable endpoint in one function call, with no bespoke DID or payment code. The inbox view made the inter-agent traffic legible: signed messages, inline signature verification, and thread-style replies. Polish level is a working prototype — the quickstart is short and the handler contract is minimal, so the result is a live agent rather than a hardened production service.

Worth knowing

Requires Python 3.12+ and uv, plus an API key for at least one LLM provider. Payment setup (which EVM chain, USDC receiving address, pricing) is not spelled out in the quickstart and needs the docs. Identity keys and any secrets need their own handling before exposing the agent publicly. The inbox walkthrough is a demo surface, not a production monitoring stack. Multi-language SDKs (TypeScript, Kotlin) share a gRPC core but were not exercised here.

Wiring

Order: install (`uv add bindu`, or clone and `uv sync --dev` for hacking on Bindu itself) → set an LLM provider key → define the agent (e.g. Agno Agent with instructions, OpenAIChat model, DuckDuckGoTools) → define the handler as `(messages) -> response` → call `bindufy(agent, ...)` with identity/skill config → run the script. Bindu then stands up the HTTP/A2A layer, generates and manages the agent's DID-based cryptographic identity, and inserts x402 payment middleware so calls can require USDC on an EVM chain before the handler executes. Other agents address it over A2A using signed JSON-RPC; signatures are verified inline. The Python, TypeScript, and Kotlin SDKs share the same gRPC core, so protocol and identity behavior are consistent across languages. The inbox UI is the observation surface for watching and replying to inter-agent threads.

Try it yourself

In this repo, take my existing agent handler and make it network-addressable with Bindu. Steps: 1) Confirm Python 3.12+ and uv are available; add bindu as a dependency. 2) Locate my agent entrypoint (an Agno/LangChain/custom handler with signature (messages) -> response). 3) Wrap it with bindu.penguin.bindufy.bindufy, keeping the handler unchanged. 4) Add config for the agent's name, description, and skills so other agents can discover it over A2A. 5) Wire x402 payment gating: read the receiving address and price from env vars, and document which EVM chain is used. 6) Ensure the LLM provider key is read from env (OPENROUTER_API_KEY / OPENAI_API_KEY / MINIMAX_API_KEY) and never hardcoded. 7) Add a smoke test that starts the agent, sends a sample A2A message, and asserts a signed response comes back. 8) Write a short README section on running it locally and viewing traffic in the Bindu inbox. Do not change my agent's internal logic.