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.
Stop the joke agent (Ctrl+C in its terminal). We’ll start both it and four more using a helper script:
./examples/gateway_test_fleet/start_fleet.sh
[joke_agent] started, pid=64945
[math_agent] started, pid=64958
[poet_agent] started, pid=64969
[research_agent] started, pid=64980
[faq_agent] started, pid=64993
| Agent | Port | Does |
|---|
joke_agent | 3773 | Tells jokes |
math_agent | 3775 | Solves math problems step-by-step |
poet_agent | 3776 | Writes short poems |
research_agent | 3777 | Web search + summarize a factual question |
faq_agent | 3778 | Answers from a canned FAQ |
joke_agent.py - and you’ll see a small configuration that wires a language model (openai/gpt-4o-mini, dispatched through OpenRouter) to a few lines of instructions (“tell jokes, refuse other requests”). Narrow scope on purpose so mistakes are visible.
A three-agent question
Paste this into your curl terminal. It asks something that genuinely needs three agents to answer:
curl -N http://localhost:3774/plan \
-H "Authorization: Bearer ${GATEWAY_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"question": "First research the current approximate population of Tokyo. Then compute what exactly 0.5% of that population is. Finally write a 4-line poem celebrating that number of people.",
"agents": [
{
"name": "research", "endpoint": "http://localhost:3777",
"auth": { "type": "none" },
"skills": [{ "id": "web_research", "description": "Web search and summarize a factual question" }]
},
{
"name": "math", "endpoint": "http://localhost:3775",
"auth": { "type": "none" },
"skills": [{ "id": "solve", "description": "Solve math problems step-by-step" }]
},
{
"name": "poet", "endpoint": "http://localhost:3776",
"auth": { "type": "none" },
"skills": [{ "id": "write_poem", "description": "Write a short poem" }]
}
]
}'
task.started events, in order - research first, then math, then poet. Abbreviated output from a real run:
task.started → research called with "What is the current population of Tokyo?"
task.artifact → "Tokyo's metropolitan area has approximately 36.95 million people..."
task.finished → completed
task.started → math called with "Compute 0.5% of 36,950,000"
task.artifact → "0.005 × 36,950,000 = 184,750"
task.finished → completed
task.started → poet called with "Write a 4-line poem about 184,750 people"
task.artifact → "In Tokyo's heart, where dreams align, / 184,750 souls brightly shine, / ..."
task.finished → completed
text.delta → "Step 1 - Population: 36.95 million..."
...
final
done
The gateway chose the order, extracted the right number from each reply, and passed it to the next agent - all without you writing a single line of glue code. That’s the whole point.
How it chose
The planner saw three tools available (one per agent-skill combination):
| Tool name | Description |
|---|
call_research_web_research | Web search and summarize a factual question |
call_math_solve | Solve math problems step-by-step |
call_poet_write_poem | Write a short poem |
Where do those tool names come from? The gateway builds them automatically from the name and skills[].id fields in your request: call_<agent-name>_<skill-id>.
call_research_web_research. It waited for the reply, re-read the question with the new context, decided the next step was math, picked call_math_solve, and so on.
All of this happens inside one HTTP request. The SSE stream is the gateway narrating what the planner decided.
What if you added a fourth agent it doesn’t need?
Try it. Add the joke agent to the catalog above and re-run:
{
"name": "joke", "endpoint": "http://localhost:3773",
"auth": { "type": "none" },
"skills": [{ "id": "tell_joke", "description": "Tell a joke" }]
}
task.started events for research, math, poet. The joke tool sat there unused.
The planner only calls what it needs. This matters in production: you can hand the gateway a catalog of 50 agents, and only the 2 or 3 relevant to a given question will actually be invoked.
What is the planner, actually?
Inside the gateway, there’s a single agent configuration file called gateway/agents/planner.md. It’s a markdown file with YAML frontmatter — this is the real shape from the repo:
---
name: planner
description: Planning gateway for multi-agent Bindu collaboration
mode: primary
model: openrouter/anthropic/claude-sonnet-4.6
temperature: 0.3
steps: 10
permission:
agent_call: ask
---
# System prompt body - the planner's own instructions.
/plan request, the gateway does this:
Read the planner's system prompt from the cached agent registry.
The registry is built once at boot by scanning gateway/agents/*.md. There’s no per-request reload — see gateway/src/agent/index.ts.
Add the user's question as a new user message.
Plus any prior turns the client sent in history (the gateway is stateless, so history travels on the request).
Build the tool list from your agents[] catalog.
One tool per agent.skill pair, named call_<agent>_<skill>.
Hand all of that to OpenRouter with streamText().
Claude (or whatever model you picked) drives the loop.
Stream the output back to you as SSE.
Text deltas + tool calls + tool results.
Edits to gateway/agents/planner.md require a gateway restart. The agent registry is populated once at boot and cached for the lifetime of the process. If you tweak the system prompt and want it to take effect, Ctrl+C and npm run dev again.
Gateway doesn’t run agents randomly -
it decides the order and connects their outputs.