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.

Your agent is online. You sent it a message. It came back with a DID-signed response. Now what? The honest answer is “depends what you’re building.” Here are the four paths the docs are organized around.

​
I want to ship this to other humans

Real users, real domain, real uptime. Read in this order:
  1. Install — uv add bindu was for your laptop. Production wants uv sync, a venv, and a .env file.
  2. Storage — switch from in-memory to Postgres so a restart doesn’t eat your tasks.
  3. Scheduler — switch from in-memory to Redis when you want more than one process.
  4. Authentication — Hydra OAuth2. Stop running open to the internet.
  5. Observability — OpenTelemetry traces, Sentry errors. The boring stuff that saves you at 2am.
If you only do two of these, do storage and auth. Everything else can wait until you have users.

​
I want this agent to talk to other agents

That’s the whole point of A2A. Read these:
  1. Skills — declare what your agent can do so other agents can find it without guessing.
  2. DIDs — how callers verify the response really came from you, and how you verify them back.
  3. Gateway — when you want a planner LLM to route a question across a fleet of agents.
  4. Negotiation — when two agents need to agree on price and SLA before doing the work.
  5. Notifications — webhook your caller when a long task finishes. Stop polling.

​
I want this agent to take money

x402, USDC, EVM. Bindu was partly built for this.
  1. Payment — the protocol, the chains supported, the wallet config.
  2. DIDs if you skipped it — payment without identity is just a tip jar.
The shortest path is examples/premium-advisor in the repo. Caller hits the agent, gets a 402 Payment Required with an invoice, pays in USDC, hits again with the receipt, gets the answer. End to end in 90 lines.

​
I want to build this in TypeScript / Kotlin / something else

You don’t have to write Python. Bindu has a polyglot gRPC core.
  1. gRPC overview — why the sidecar exists, how the two halves talk.
  2. gRPC quickstart — the TypeScript-side equivalent of your-first-agent.
  3. Building a custom SDK — for the language we don’t ship yet. Usually a few hundred lines.
Same DID, same A2A protocol, same payment rails. The language is your choice.

​
I’m stuck

The errors you’ll hit are almost always one of these:
  • address already in use on :3773 — another Bindu agent is already running. lsof -ti:3773 | xargs kill.
  • OPENAI_API_KEY not set — .env file isn’t being loaded. Add from dotenv import load_dotenv; load_dotenv() at the top of your script. (env_file appears in the bindufy() docstring but is not actually wired up — call load_dotenv yourself.)
  • ConfigError: 'author' is a required field in the agent configuration. — you typoed the key, or are missing one of author / name / deployment.url / deployment.expose. Re-read Config reference.
  • ConfigError: 'deployment.url' must be a valid http(s) URL, got '...' — your URL is missing the scheme or netloc. urlparse rejects anything not http:///https:// with a host.
  • DATABASE_URL environment variable is required when STORAGE_TYPE=postgres — you opted into Postgres without giving it a connection string. Either set DATABASE_URL or drop STORAGE_TYPE=postgres to fall back to memory.
  • Tunnel not working — expose: True needs outbound 443 open. Behind a corporate firewall this won’t fly. Use expose: False and a real domain.
Beyond that:
  • GitHub Issues for bugs and feature requests.
  • Discord for “is this supposed to work like this” questions. Maintainers hang out there.
  • Examples folder — 30+ working agents covering most patterns. When in doubt, find the one closest to what you’re building and steal the config.
That’s the whole map. Pick a row, read it, ship something. One sunflower at a time.