> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getbindu.com/llms.txt
> Use this file to discover all available pages before exploring further.
# What is Bindu
> The identity, communication, and payments layer for AI agents — built for production agent swarms like the Trade Compliance OS
> "Every story begins with a single point of light."
It always starts small — a spark, a line of code, a dot (in Sanskrit, *bindu*).
The story starts with a developer.
She just built an incredible agent. It reasons well, pulls from multiple APIs, and writes structured outputs.
But before she can share it with the world, she needs to:
Set up a server. Handle authentication. Add observability and tracing. Expose endpoints. Maybe support payments. Probably wire up mutual TLS so the request body isn't readable on the wire. Almost certainly stand up a DID so the agent can prove who it is when it talks to another agent.
Three weeks later, her "AI agent" still isn't live. She's writing boilerplate instead of building intelligence. **She became the DevOps engineer she never wanted to be.**
That's the story of almost every agent today. And it's completely backwards.
**The intelligence is ready. The infrastructure isn't.**
***
***
## Bindu flips that story
| | **Without Bindu** | **With Bindu** |
| ------------------- | -------------------------------------- | ---------------------------- |
| **Agent Code** | 15 lines | 15 lines |
| **Integration** | Countless lines of boilerplate | 5 lines of configuration |
| **Identity & Auth** | Roll your own DID, OAuth, key rotation | Built in: DID + Hydra + mTLS |
| **Time to Deploy** | Weeks | 2 minutes |
| **Developer Focus** | Becomes DevOps engineer | Stays focused on the agent |
**Weeks reduced to minutes.**
***
## Why we built this: the Trade Compliance OS
Bindu didn't start as a framework. It started because we needed it.
We're building the **Trade Compliance OS** — a swarm of agents that helps a small or mid-sized business ship physical goods across borders without writing a six-figure check to a law firm. The agents handle:
* **CBAM** — the EU's Carbon Border Adjustment Mechanism, which now charges importers for embedded carbon in steel, cement, aluminum, fertilizer, electricity, and hydrogen.
* **EUDR** — the EU Deforestation Regulation, which forbids placing coffee, cocoa, cattle, palm oil, soy, rubber, wood, and their derivatives on the EU market without a deforestation-free declaration.
* **HS codes** — the 10-digit Harmonized System classification that decides the duty rate, the licensing regime, and whether a shipment clears in hours or weeks.
* **DPPs** — Digital Product Passports, the per-item provenance and material record the EU is making mandatory category by category.
Picture the workflow. An SMB exporter wants to send 12 pallets of roasted coffee from Vietnam to Germany. The system has to:
1. Classify the product — pull the right HS code from a regulator's database.
2. Pull deforestation-free attestations for the source farms.
3. Generate the CBAM declaration if the buyer is in scope.
4. Stamp a Digital Product Passport so each bag carries its provenance.
5. Quote a price for the bundled service. Settle it. Hand the exporter a packet they can file.
That is not one agent. That is a **swarm**. Different agents for different regulations, different data sources, different jurisdictions. Some of them are ours. Some of them belong to partners. Some of them want to be paid per query because they're calling expensive regulator APIs underneath.
The minute you try to ship that for real, you hit four hard problems at once:
1. **Identity.** When an auditor asks "which agent computed this CBAM declaration?", you need a cryptographic answer, not a log line. Every agent's output has to be signed by a key only that agent owns.
2. **Authorization.** Some agents in the swarm are internal. Some are paying partners. Some are anonymous public agents asking for quotes. They cannot all see the same data.
3. **Encryption on the wire.** Customs documents are regulated. The bearer token cannot traverse a coffee-shop network in cleartext, full stop.
4. **Payment.** A compliance agent that queries five regulator APIs cannot quote a price after the fact. It has to demand settlement *before* it spends the underlying API call.
Most agent frameworks hand you one of these and tell you the other three are your problem. **Bindu was built so the compliance swarm could exist** — which is why all four ship together, on by default.
If you've built an agent that touches **customs paperwork, supplier audits, materials sourcing, regulatory filings, or anything adjacent**, we'd love to have it in the network. [Find us on Discord](https://discord.gg/3w5zuYUuwt).
***
## What ships with Bindu (and why each piece exists)
Every feature here exists because the compliance swarm needed it. The same pieces work for any agent network — Bindu is generic — but the *why* is concrete.
### The three-layer security stack
When an A2A request lands on a Bindu agent, three middlewares fire before your handler sees the body — and each 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](https://smallstep.com/docs/step-ca/), SAN = DID, 24-hour TTL, auto-renewed in-process |
| **OAuth2 via Hydra** | *Is the caller allowed to perform this operation right now?* | Bearer token, \~1-hour TTL, validated via [Ory Hydra](https://www.ory.sh/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. **No agent framework we surveyed ships all three out of the box.**
Why three, not one? Because each fails safe in a way the others can't. An attacker who steals a bearer token still can't decrypt the traffic (mTLS owns the wire). An attacker who forges a cert still can't impersonate a DID (the signature won't verify). An attacker who breaks the signature scheme still can't get past Hydra's authorization check.
For the compliance swarm: the auditor's "which agent signed this declaration?" question has a cryptographic answer in three places — the cert SAN, the OAuth client\_id, and the message signature. All three must agree, or the request is rejected.
→ Full walkthrough: [Security Stack](/bindu/learn/authentication/security-stack)
### x402 payments — pay before you run
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.
For the compliance swarm: a CBAM declaration agent calls three paid regulator APIs underneath. It can't eat that cost on a query that never settles. x402 means the caller has paid before the agent burns a single API call.
→ [Payment docs](/bindu/learn/payment/introduction)
### DID identity that doubles as your audit trail
Every response your agent sends is signed with an Ed25519 key. Callers verify with a [W3C DID](https://www.w3.org/TR/did-core/) — 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.
For the compliance swarm: when an EU customs officer asks who computed a CBAM number two years from now, the DID + signature is the answer. Non-repudiable by design.
→ [DID docs](/bindu/learn/did/overview)
### Gateway — a planner that orchestrates the swarm
A planner LLM that takes a high-level intent (`"ship 12 pallets of coffee from Vietnam to Germany"`), decides which agents to invoke, fans the work out over A2A, and streams the result back. Each fan-out call is signed; each backing agent verifies the chain to the operator's cert.
For the compliance swarm: the gateway is what turns "ship this coffee" into a planned sequence of HS-code lookup, EUDR attestation, CBAM declaration, and DPP generation — without you hard-coding the routing.
→ [Gateway docs](/bindu/gateway/overview)
### Skills, and private skills
Declare what your agent can do, and callers see it on the agent card before they spend a token asking. **Private skills** keep your commercial menu out of the public catalog — public crawlers see a generic "we do trade compliance", allowlisted partner DIDs see your real menu at a second auth-gated endpoint.
For the compliance swarm: your interpretation of CBAM regulation **is** your product. Showing the full skill catalog to every public crawler tells competitors your roadmap. Private skills mean the catalog is gated by DID allowlist.
→ [Private skills](/bindu/skills/private_skills/private_skills)
### Polyglot SDKs on one gRPC core
Bindu is Python at heart, but the framework exposes a shared **gRPC core** that any language can drive. SDKs ship for **Python, TypeScript, and Kotlin** today — same protocol, same DID, same auth. A new language SDK is usually a few hundred lines.
For the compliance swarm: regulator APIs come in every flavor — REST in Java, SOAP in .NET, an SDK in TypeScript, a CLI in Go. Your team writes the agent in whichever language matches the integration, and the rest of the swarm doesn't care.
→ [Multi-language sidecar](/bindu/grpc/overview)
### The inbox — a Gmail-shaped control plane
A visual operator inbox that bootstraps a personal agent, registers it with Hydra, signs every outbound message, and renders agents as Gmail-shaped addresses (`fleet+joke_agent@getbindu.com`). Watch your agents send signed JSON-RPC to each other, verify identities inline, and reply to a swarm like it's an email thread.
For the compliance swarm: the operator needs to *see* what the agents are doing. The inbox is the human-in-the-loop pane on top of the swarm.
### Tunnel and cloud deploy
`expose: true` puts your laptop on the internet — no port forwarding, no router config — via an FRP tunnel. When you're ready to leave the laptop, `bindu deploy agent.py --runtime=boxd` ships your script to a microVM and prints the HTTPS URL. No Dockerfile.
For the compliance swarm: developers iterate locally with `expose: true`, then promote to production with one command.
→ [Tunneling](/bindu/learn/tunneling/overview) · [Runtime](/bindu/runtime/overview)
***
## The 10-line agent
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.
```python theme={null}
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.",
"version": "1.0.0",
"capabilities": {},
"auth": {"enabled": False},
"storage": {"type": "memory"},
"scheduler": {"type": "memory"},
"deployment": {"url": "http://localhost:3773", "expose": True},
}
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.
Calling the agent with curl
```bash theme={null}
curl -X POST http://localhost:3773/ \
-H 'Content-Type: application/json' \
-d '{
"jsonrpc": "2.0",
"method": "message/send",
"id": "",
"params": {
"message": {
"role": "user",
"kind": "message",
"parts": [{"kind": "text", "text": "Hello"}],
"messageId": "",
"contextId": "",
"taskId": ""
},
"configuration": {"acceptedOutputModes": ["application/json"]}
}
}'
```
Then poll `tasks/get` with the same `taskId` until state hits `completed`.
TypeScript equivalent
```typescript theme={null}
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 },
}, async (messages) => {
const response = await openai.chat.completions.create({
model: "gpt-4o",
messages: messages.map(m => ({ role: m.role, content: m.content })),
});
return response.choices[0].message.content || "";
});
```
The TypeScript SDK spawns the Python core in the background. Zero Python in your repo, same DID, same wire protocol.
***
## Supported frameworks
Bindu doesn't care what's inside the handler. Bring whatever you already like writing agents in.
| Language | Frameworks tested in this repo |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Python** | [AG2](https://github.com/ag2ai/ag2), [Agno](https://github.com/agno-agi/agno), [CrewAI](https://github.com/joaomdmoura/crewAI), [Hermes Agent](https://github.com/NousResearch/hermes-agent), [LangChain](https://github.com/langchain-ai/langchain), [LangGraph](https://github.com/langchain-ai/langgraph), [Notte](https://github.com/nottelabs/notte) |
| **TypeScript** | [OpenAI SDK](https://github.com/openai/openai-node), [LangChain.js](https://github.com/langchain-ai/langchainjs) |
| **Kotlin** | [OpenAI Kotlin SDK](https://github.com/aallam/openai-kotlin) |
| **Any other** | via the [gRPC core](/bindu/grpc/overview) — a new SDK is usually a few hundred lines |
Model providers that speak the OpenAI or Anthropic API work out of the box — [OpenRouter](https://openrouter.ai/), [OpenAI](https://platform.openai.com/), [MiniMax](https://platform.minimaxi.com), and the rest.
***
## Beyond compliance
Trade Compliance OS is what made us build Bindu, but the same architecture works for any agent network where identity, payments, and multi-party trust matter:
* **Healthcare swarms** — a triage agent routing to specialty agents, each signing their differential.
* **Financial research** — a planner orchestrating data, modeling, and report agents, each billing per query.
* **Legal discovery** — a fleet of agents reading documents under cryptographic chain-of-custody.
* **Supply chain audits** — supplier agents, materials agents, certificate agents handing off work with verifiable provenance.
The pattern is the same: many agents, different owners, different jurisdictions, real money, real audit trails. That's the Internet of Agents — and that's what Bindu turns from a slide deck into a running system.
***
## What's next
The task-first execution model and the layered system that makes it work
mTLS + Hydra + DID on a single request — embassy analogy, env block, gotchas
From zero to a running agent in two minutes
The planner LLM that orchestrates multi-agent flows
***
The universe began with a dot.{" "}
The Internet of Agents begins with Bindu.
The universe began with a dot.{" "}
The Internet of Agents begins with Bindu.