# Bindu

> Give an agent a cryptographic identity, A2A transport and payment rails in one call

- Category: Agents & Automation / Multi-Agent Systems
- Language: Python
- Licence: Apache-2.0
- Repository: https://github.com/GetBindu/Bindu
- Website: https://docs.getbindu.com
- Canonical page: https://ai-tldr.dev/tools/bindu/

## In short

Bindu is the identity, communication and payments layer for AI agents. It sits in the Multi-Agent Systems category of the Agents & Automation tools and is open-source, written in Python and licensed Apache-2.0. To get started: install.

## Overview

Bindu is the identity, communication and payments layer for AI agents. The problem it targets is the plumbing between a working agent and an agent that can actually operate in public: a DID library to integrate, an OAuth flow to set up, payment middleware, and an HTTP layer that speaks whatever protocol the rest of the agent world uses. Bindu packages all of that behind one call — you wrap your handler with `bindufy()` and the agent comes online with its own cryptographic identity, speaking A2A, optionally demanding payment before it does any work.

Your handler stays as small as `(messages) -> response`, and what runs inside it is up to you: the repository tests agents written with AG2, Agno, CrewAI, Hermes Agent, LangChain, LangGraph and Notte in Python, the OpenAI SDK and LangChain.js in TypeScript, and the OpenAI Kotlin SDK. All three SDKs share one gRPC core, so the language is a choice while the protocol and the identity stay the same, and a new SDK on top of that core is usually a few hundred lines.

Security is handled as transport rather than as an exercise for the developer. Three middlewares fire before a request body reaches your handler, each answering a question the others cannot: mTLS with an X.509 certificate from Smallstep step-ca (the DID as SAN, 24-hour TTL, auto-renewed in process) proves the socket is encrypted and mutually authenticated; an OAuth2 bearer token validated through Ory Hydra introspection proves the caller may perform this operation; and an Ed25519 `X-DID-Signature` over the canonical body proves who authored it. The same DID is the certificate SAN, the OAuth2 client_id and the message signer, and all three must agree or the request is rejected.

## What it does

- `bindufy()` puts an existing agent handler online with a W3C DID identity and A2A JSON-RPC (`message/send`, `tasks/get`, `message/stream`) on port 3773
- Three-layer default-on security: mTLS certificates from step-ca, scoped OAuth2 tokens via Ory Hydra, and Ed25519 DID signatures over the request body
- x402 payments — the agent can demand USDC before the handler runs, with Base, Base Sepolia, Ethereum, Ethereum Sepolia and SKALE Europa pre-configured and other EVM chains added through one `extra_networks` entry
- A skills system with an agent card, plus private skills that show a generic description to public crawlers and the real menu to allowlisted partner DIDs at an auth-gated endpoint
- Agent negotiation over price, latency and SLA; Postgres-backed task and message storage; Redis-backed retries, timeouts and recurring tasks
- Python, TypeScript and Kotlin SDKs over one gRPC core, plus an operator inbox UI that shows agents messaging each other with signatures verified inline
- `expose: true` opens an FRP tunnel so a local agent is reachable without port forwarding, and `bindu deploy` ships a script to a microVM with no Dockerfile

## Getting started

Bindu needs Python 3.12 or newer and uv. Running the examples also needs an API key for at least one LLM provider — OPENROUTER_API_KEY, OPENAI_API_KEY or MINIMAX_API_KEY.

1. Install

   Add the package to your project with uv.

```bash
uv add bindu
```

2. Or work on Bindu itself

   Clone and sync the development dependencies.

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

3. Bindufy an agent

   Build the agent you want, describe it in a config, and hand the handler to bindufy(). This example uses Agno, but the framework inside the handler is irrelevant to Bindu.

```python
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)
```

4. Run the operator inbox

   The inbox is a UI over the same auth and DID signing — agents messaging each other, with signatures verified inline.

```bash
cd inbox && npm run dev
```

5. Read the examples

   The examples directory covers an Agno agent swarm, x402-gated premium work, a bindufied Hermes agent in about 90 lines, a five-agent gateway fleet, and a TypeScript-only agent, alongside 20+ more.

```text
examples/agent_swarm/            # agents passing work to each other
examples/premium-advisor/        # x402: caller pays USDC before anything runs
examples/hermes_agent/           # Hermes Agent, bindufied
examples/gateway_test_fleet/     # five agents and one gateway
examples/typescript-openai-agent/
```

## When to use it

- Publish an agent on the open internet with a verifiable identity, so callers can check who authored a response instead of trusting a shared secret
- Charge for agent work directly, requiring USDC on an EVM chain before the handler executes
- Let agents built in different frameworks and languages interoperate over A2A without each one reimplementing identity and auth
- Keep commercial skill descriptions out of the public agent catalog while exposing them to allowlisted partner DIDs