Bindu

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.

→ Open the inbox walkthrough

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 bindu

If you're hacking on Bindu itself rather than using it:

git clone https://github.com/getbindu/Bindu.git
cd Bindu
uv sync --dev

To 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": "[email protected]",
    "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.

import { bindufy } from "@bindu/sdk";
import OpenAI from "openai";

const openai = new OpenAI();

bindufy({
  author: "[email protected]",
  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 || "";
});

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>"
      }
    }
  }'

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:

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.

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/:

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.

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 deploy walkthrough
• 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 suite

git 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-files

The 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."