A Gmail-shaped inbox for the agent internet. Watch your agents send signed JSON-RPC to each other, verify identities inline, and reply to a swarm like it's a thread.
Here's the situation. You built an agent. It works. But to actually let it loose — talk to other agents, prove who it is, take money for the work — you'd be on the hook for a lot of boring plumbing. A DID library to integrate. An OAuth flow to set up. Payment middleware. An HTTP layer that follows whatever protocol the rest of the agent world is using.
Bindu is all of that plumbing, behind one function call. You wrap your handler with bindufy(), and a few seconds later your agent is online with its own cryptographic identity, speaking A2A (the protocol other agents already use), and ready to demand USDC on any EVM chain before it does any work (x402). Your handler stays as small as (messages) -> response. The framework inside the handler — Agno, LangChain, CrewAI, your own thing — Bindu doesn't care.
There are SDKs for Python, TypeScript, and Kotlin, and they all share the same gRPC core. The language is a choice; the protocol and identity are the same either way. When you're ready to go deeper, the docs are the next stop.
You'll need Python 3.12+ and uv.
uv add binduIf you're hacking on Bindu itself rather than using it:
git clone https://github.com/getbindu/Bindu.git
cd Bindu
uv sync --devTo run the examples you'll need an API key for at least one LLM provider — OPENROUTER_API_KEY, OPENAI_API_KEY, or MINIMAX_API_KEY.
Build the agent you want, hand it to bindufy(), and it's online. The block below is the whole thing — copy it into a file, set your OPENAI_API_KEY, run it.
import os
from bindu.penguin.bindufy import bindufy
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools
agent = Agent(
instructions="You are a research assistant.",
model=OpenAIChat(id="gpt-4o"),
tools=[DuckDuckGoTools()],
)
config = {
"author": "you@example.com",
"name": "research_agent",
"description": "Research assistant with web search.",
"deployment": {"url": "http://localhost:3773", "expose": True},
"skills": ["skills/question-answering"],
}
def handler(messages: list[dict[str, str]]):
return agent.run(input=messages)
bindufy(config, handler)The agent is now live at http://localhost:3773. expose: True opens an FRP tunnel so the rest of the internet can hit it without you setting up port forwarding.
TypeScript equivalent
import { bindufy } from "@bindu/sdk";
import OpenAI from "openai";
const openai = new OpenAI();
bindufy({
author: "you@example.com",
name: "research_agent",
description: "Research assistant.",
deployment: { url: "http://localhost:3773", expose: true },
skills: ["skills/question-answering"],
}, async (messages) => {
const response = await openai.chat.completions.create({
model: "gpt-4o",
messages: messages.map(m => ({ role: m.role as "user" | "assistant" | "system", content: m.content })),
});
return response.choices[0].message.content || "";
});The TypeScript SDK spawns the Python core in the background — you won't see it, and you don't need any Python in your own codebase. Same protocol, same DID. Full example in examples/typescript-openai-agent/.
Calling the agent with curl
curl -X POST http://localhost:3773/ \
-H 'Content-Type: application/json' \
-d '{
"jsonrpc": "2.0",
"method": "message/send",
"id": "<uuid>",
"params": {
"message": {
"role": "user",
"kind": "message",
"parts": [{"kind": "text", "text": "Hello"}],
"messageId": "<uuid>",
"contextId": "<uuid>",
"taskId": "<uuid>"
}
}
}'Then poll tasks/get with the same taskId until state hits completed.
Most agent frameworks treat security as your problem. Bindu treats it as transport.
When an A2A request lands on a Bindu agent, three different middlewares fire before your handler sees the body — and each one answers a question the other two cannot:
| Layer | The question it answers | What it actually is |
|---|---|---|
| mTLS | Is the socket itself encrypted and mutually authenticated? | X.509 cert from Smallstep step-ca, SAN = DID, 24-hour TTL, auto-renewed in-process |
| OAuth2 via Hydra | Is the caller allowed to perform this operation right now? | Ed-style bearer token, ~1-hour TTL, validated via Ory Hydra introspection |
| DID signature | Was this exact JSON body authored by the DID it claims? | Ed25519 signature over canonical body, carried in X-DID-Signature |
You don't pick one. You don't bolt them on. They ship together — and on the operator's personal agent, they're on by default as of 2026.21.1.
Why three layers, not one? Because each fails safe in a way the others can't:
- An attacker who steals a bearer token still can't decrypt your traffic — mTLS owns the wire.
- An attacker who somehow forges a cert still can't impersonate a DID — the signature won't verify against the claimed key.
- An attacker who breaks the signature scheme entirely still can't get past Hydra's authorization check.
The cert lives at the socket. The bearer token lives in the header. The signature lives in the body. Each one rejects a class of attack the others are blind to. No agent framework we surveyed ships all three out of the box.
→ The full story: docs/SECURITY_STACK.md walks through what each layer does, how a single request flows through all three, today's defaults, the five real bugs we hit shipping default-on mTLS, and a troubleshooting matrix.
Every row here links out to the guide that actually goes into it.
| Feature | What it does | Docs |
|---|---|---|
| A2A JSON-RPC | The protocol other agents already speak. message/send, tasks/get, message/stream on port 3773. |
— |
| mTLS transport | The socket is encrypted and mutually authenticated. Each agent gets a real X.509 cert from step-ca (SAN = DID), serves uvicorn over TLS, and renews itself every ~16 hours. On by default for the inbox personal agent in 2026.21.1. | SECURITY_STACK.md · MTLS_DEPLOYMENT_GUIDE.md |
| DID identity | Every response your agent sends is signed with an Ed25519 key. Callers verify with a W3C DID — there's no shared secret to leak, no central authority to query, and the same DID is the cert's SAN, the OAuth2 client_id, and the message signer. All three have to agree, or the request is rejected. | DID.md |
| OAuth2 via Hydra | Scoped bearer tokens (agent:read, agent:write, agent:execute) instead of one key that opens every door. Each agent self-registers as a Hydra client at boot — its DID IS its client_id, so authorization, identity, and transport-layer cert all point at the same actor. |
AUTHENTICATION.md |
| x402 payments | Flip a flag and the agent demands USDC before your handler ever sees the request. 5 chains pre-configured — Base, Base Sepolia, Ethereum, Ethereum Sepolia, SKALE Europa — and any other EVM chain (Polygon, Avalanche, Arbitrum, …) takes one extra_networks entry. |
PAYMENT.md |
| Push notifications | The agent webhooks you when a task changes state. Stop polling. | NOTIFICATIONS.md |
| Skills system | Declare what your agent can do; callers see it on the agent card before they spend a token asking. | SKILLS.md |
| Private skills | Keep your commercial skill descriptions out of the public catalog. Public crawlers see a generic "we do X" — allowlisted partner DIDs see your real menu at a second auth-gated endpoint. Useful when your skill descriptions ARE your product roadmap. | PRIVATE_SKILLS.md |
| Agent negotiation | Two agents agree on price, latency, and SLA up front. No surprise bills. | NEGOTIATION.md |
| Storage | Postgres for tasks and messages. Swap the backend if you've got a preference. | STORAGE.md |
| Scheduler | Redis-backed retries, timeouts, and recurring tasks. | SCHEDULER.md |
| Public tunnel | expose: true puts your laptop on the internet. No port forwarding, no router config. |
TUNNELING.md |
| Polyglot SDKs | Python, TypeScript, Kotlin — same gRPC core underneath, same DID, same auth. | GRPC_LANGUAGE_AGNOSTIC.md |
| Cloud deploy | bindu deploy agent.py --runtime=boxd ships your script to a microVM and prints the HTTPS URL. No Dockerfile. |
runtime/quickstart.md |
| Gateway | A planner LLM that orchestrates a fleet of agents over A2A and streams the result back. | GATEWAY.md |
| Observability | OpenTelemetry traces, Sentry errors, a health endpoint. The boring stuff that saves you at 2am. | OBSERVABILITY.md |
The operator inbox at the top of this page is in inbox/ — same auth, same DID signing, just visible. Run it with cd inbox && npm run dev.
A handful from examples/:
| Example | What it shows |
|---|---|
| Agent Swarm | A small society of Agno agents passing work to each other. |
| Premium Advisor | x402 in practice — the caller has to pay USDC before anything runs. |
| Hermes via Bindu | Nous Research's Hermes agent, bindufied in ~90 lines. |
| Gateway Test Fleet | Five agents and one gateway — the multi-agent story end to end. |
| TypeScript OpenAI Agent | A TS-only agent with zero Python in your repo. |
There are 20+ more covering CSV analysis, PDF Q&A, speech-to-text, web scraping, multi-lingual collaboration, blog writing, and so on. Browse them in examples/.
We're using Bindu in production to build the Trade Compliance OS — a swarm of agents that handles CBAM, EUDR, HS codes, and Digital Product Passports, so an SMB can ship coffee, textiles, or steel across borders without writing a six-figure check to a law firm. Every agent in that swarm is bindufied. The protocol, the identity, the payment rails — that's all the stuff we needed Bindu to solve in the first place.
If you've built an agent that touches any of this — customs paperwork, supplier audits, materials sourcing, regulatory filings, anything in the neighborhood — we'd love to have it in the network. Come find us on Discord and let's talk.
Bring whatever you already like writing agents in. Bindu doesn't care what's inside the handler.
| Language | Frameworks tested in this repo |
|---|---|
| Python | AG2, Agno, CrewAI, Hermes Agent, LangChain, LangGraph, Notte |
| TypeScript | OpenAI SDK, LangChain.js |
| Kotlin | OpenAI Kotlin SDK |
| Any other | via the gRPC core — a new SDK is usually a few hundred lines |
If your model provider speaks the OpenAI or Anthropic API, it works — OpenRouter, OpenAI, MiniMax, and the rest.
- Full docs site
- Security stack — mTLS + Hydra + DID — how the three identity layers compose, with a live walkthrough using the gateway test fleet
- Calling a secured agent — the shortest path: the two things you do when auth is on (token + DID signature), in one page
- Auth — long form and DID signing — long form — when the short version isn't enough
- mTLS deployment — DevOps-facing guide for standing up step-ca, OIDC provisioner config, and the cert lifecycle
- Cloud deployment —
bindu deploywalkthrough - Gateway — multi-agent orchestration
- Private skills — hide your commercial menu from the public catalog; show it only to allowlisted partner DIDs
- gRPC architecture — for anyone building a new language SDK
- Known issues — read this before you push to production
- Troubleshooting — the errors you'll hit, and how to get past them
uv run pytest tests/unit/ -v # fast unit tests
uv run pytest tests/integration/grpc/ -v -m e2e # gRPC E2E
uv run pytest -n auto --cov=bindu --cov-report=term-missing # full suitegit clone https://github.com/getbindu/Bindu.git
cd Bindu
uv venv --python 3.12.9 && source .venv/bin/activate
uv sync --dev
pre-commit run --all-filesThe full guide is in .github/contributing.md. Most of the day-to-day back-and-forth happens on Discord — come say hi.
 Raahul Dutta |
 Paras Chamoli |
 Chandan |
Bindu stands on the shoulders of a lot of good open source:
FastA2A · A2A · x402 · Hugging Face chat-ui · 12 Factor Agents · OpenCode · OpenMoji · ASCII Space Art
Apache 2.0. See LICENSE.md.
"We believe in the sunflower theory — standing tall together, bringing hope and light to the Internet of Agents."