Skip to main content

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.

“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 BinduWith Bindu
Agent Code15 lines15 lines
IntegrationCountless lines of boilerplate5 lines of configuration
Identity & AuthRoll your own DID, OAuth, key rotationBuilt in: DID + Hydra + mTLS
Time to DeployWeeks2 minutes
Developer FocusBecomes DevOps engineerStays 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.

​
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:
LayerThe question it answersWhat it actually is
mTLSIs 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 HydraIs the caller allowed to perform this operation right now?Bearer token, ~1-hour TTL, validated via Ory Hydra introspection
DID signatureWas 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

​
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

​
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 — 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

​
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

​
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

​
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

​
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 · Runtime

​
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. 
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.

​
Supported frameworks

Bindu doesn’t care what’s inside the handler. Bring whatever you already like writing agents in.
LanguageFrameworks tested in this repo
PythonAG2, Agno, CrewAI, Hermes Agent, LangChain, LangGraph, Notte
TypeScriptOpenAI SDK, LangChain.js
KotlinOpenAI Kotlin SDK
Any othervia the gRPC core — a new SDK is usually a few hundred lines
Model providers that speak the OpenAI or Anthropic API work out of the box — OpenRouter, OpenAI, MiniMax, 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

Architecture

The task-first execution model and the layered system that makes it work

Security Stack

mTLS + Hydra + DID on a single request — embassy analogy, env block, gotchas

Your first agent

From zero to a running agent in two minutes

Gateway

The planner LLM that orchestrates multi-agent flows
Sunflower LogoThe universe began with a dot.The Internet of Agents begins with Bindu.