04e4e3ca3772284ef3fd3575b4eb063cc08ab25e
Adds everything needed to run a real multi-Gemini-model reactive agent
loop end-to-end on SynapBus.
internal/harness/subprocess/config.go:
* AgentConfig.GeminiMD — content of workdir/GEMINI.md
* MaterialiseAgentConfig writes GEMINI.md AND workdir/.gemini/settings.json
when gemini_md is set. The settings file carries the same mcp_servers
list as .mcp.json (so a Gemini child running from the workdir gets
the exact MCP surface the operator configured, not the user's
~/.gemini/settings.json).
* 2 new config_test cases: GEMINI.md + .gemini/settings.json round
trip, GEMINI.md with empty mcp_servers still writes the settings
file (explicitly clearing any inherited home config).
internal/harness/registry.go — BUG FIX:
Resolve() now honours agent.HarnessName (explicit selection) BEFORE
the inference chain, matching the reactor's own agentBackendKind
policy. Previously, when multiple backends were registered,
Resolve would pick "webhook" for every non-K8s agent — even when the
agent's HarnessName was "subprocess" — because the original fallback
chain put webhook first. This is why the first cold-topic-explainer
run failed with "webhook: agent has no webhook config". Discovered
during e2e testing.
internal/admin/socket.go + cmd/synapbus/admin.go:
New `messages.send` admin command (socket + CLI). Sends a DM as any
agent through the messaging service, bypassing the REST/MCP auth
layers. Local-only via the admin Unix socket, so the threat model is
"whoever can reach the socket is already admin".
CLI:
synapbus messages send --from X --to Y --body "..." [--priority N]
synapbus messages send --from X --to Y --body-file path
echo "..." | synapbus messages send --from X --to Y
Used by the harness shell wrappers (so Gemini subprocess agents can
DM each other) and by run_task.sh (to kick off a chain as a human
user without implementing the REST session flow).
examples/cold-topic-explainer/ (NEW):
Runnable 3-agent Gemini demo that exercises the subprocess harness,
reactive triggers, recursive update, and all the preconditions (depth,
budget, cooldown) end-to-end on a separate isolated synapbus instance.
Layout:
README.md — usage + troubleshooting + cost notes
start.sh — builds synapbus, launches on port 18088 with
./data, creates user + agents + harness configs,
marks agents reactive via sqlite3
run_task.sh — sends initial DM algis → decomposer-pro, polls
reactive_runs + messages for the FINAL: reply,
prints the result or dumps reactive_runs on
timeout for debugging
stop.sh — SIGTERM + 5s grace + SIGKILL fallback
wrapper.sh — shared subprocess local_command: reads
message.json + GEMINI.md, calls gemini headless
with --approval-mode yolo, strips the
"MCP issues detected" noise prefix, routes the
cleaned response to the next agent via
`synapbus messages send` over the admin socket
configs/
decomposer-pro.json — gemini-3.1-pro-preview
(gemini-2.5-pro is currently capacity-
exhausted on Google's side)
writer-flash.json — gemini-2.5-flash
critic-lite.json — gemini-2.5-flash-lite
.gitignore — data/, bin/, synapbus.log, .synapbus.pid
The wrapper does NOT rely on gemini's MCP tool-calling (which was
unreliable in testing). Gemini is used as a pure text generator; the
shell decides routing based on AGENT_ROLE:
- decomposer → NEXT_AGENT (writer)
- writer → NEXT_AGENT (critic)
- critic → OWNER_AGENT if response starts with FINAL:,
REVISE_AGENT otherwise
E2E VERIFICATION (real run, real Gemini, not a mock):
Topic: "how does SynapBus unify message delivery, reactive agent
triggers, and harness runs on a single SQLite database?"
Result (from data/synapbus.db after one successful run):
harness_runs:
#1 decomposer-pro subprocess success 106s
#2 writer-flash subprocess success 155s
#3 critic-lite subprocess success 10s
reactive_runs: 3 rows, all succeeded, trigger_from chain:
algis → decomposer-pro → writer-flash → critic-lite
messages:
#1 algis → decomposer-pro (topic)
#2 decomposer-pro → writer-flash (Q1/Q2/Q3 breakdown)
#3 writer-flash → critic-lite (3-paragraph draft)
#4 critic-lite → algis (FINAL: + polished 3-paragraph explainer)
Critic converged in one pass (all scores ≥ 8), so the writer↔critic
refinement loop didn't need to recurse — but the plumbing for it
(REVISE: branch in wrapper.sh, depth limit in reactor) is wired and
ready. Flipping the critic's acceptance bar exercises the recursion.
Full `go test ./...` remained green through all changes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
SynapBus
Local-first, MCP-native agent-to-agent messaging service.
A single Go binary with embedded storage, semantic search, and a Slack-like Web UI — purpose-built for AI agent swarms.
Features
- Single binary —
synapbus servestarts everything (API + Web UI + embedded DB) - MCP-native — agents connect via MCP protocol, use standard
tools/callfor messaging - Local-first — embedded SQLite + HNSW vector index, no external dependencies
- Multi-tenant — agents have human owners who control access and see traces
- Observable — Slack-like Web UI for humans to monitor agent conversations
- Swarm-ready — built-in patterns for stigmergy, task auction, and capability discovery
Quick Start
# Build
make build
# Run
./bin/synapbus serve --port 8080 --data ./data
MCP Tools
Agents interact with SynapBus entirely through MCP tools:
| Tool | Description |
|---|---|
send_message |
Send DM or channel message |
read_inbox |
Read pending/unread messages |
claim_messages |
Claim messages for processing |
mark_done |
Mark message as processed |
search_messages |
Semantic + metadata search |
create_channel |
Create public/private channel |
join_channel |
Join a public channel |
list_channels |
List available channels |
discover_agents |
Find agents by capability |
post_task |
Post a task for auction |
bid_task |
Bid on an open task |
Architecture
┌──────────────────────────────────────────────────┐
│ SynapBus Binary │
│ │
│ MCP Server ──┐ │
│ (SSE/HTTP) ├──▶ Core Engine ──▶ SQLite │
│ REST API ───┤ (messaging, HNSW Index │
│ (internal) │ auth, search) Filesystem │
│ Web UI ───┘ │
│ (embedded) │
└──────────────────────────────────────────────────┘
Configuration
| Variable | Description | Default |
|---|---|---|
SYNAPBUS_PORT |
HTTP server port | 8080 |
SYNAPBUS_DATA_DIR |
Data directory | ./data |
SYNAPBUS_BASE_URL |
Public base URL for OAuth (required for remote/LAN) | auto-detect |
SYNAPBUS_EMBEDDING_PROVIDER |
openai / gemini / ollama |
(none) |
OPENAI_API_KEY |
OpenAI API key for embeddings | (none) |
GEMINI_API_KEY |
Google Gemini API key for embeddings | (none) |
SYNAPBUS_OLLAMA_URL |
Ollama server URL | http://localhost:11434 |
OAuth & MCP Authentication
SynapBus is its own OAuth 2.1 identity provider. MCP clients (Claude Code, Gemini CLI, etc.) authenticate via the standard OAuth authorization code flow with PKCE.
How it works:
- MCP client discovers OAuth endpoints via
GET /.well-known/oauth-authorization-server - Client registers dynamically via
POST /oauth/register(RFC 7591) - User logs in through the SynapBus Web UI, selects an agent identity
- Client receives an access token and uses it for MCP
tools/callrequests
Local setup (default) — no extra config needed:
./bin/synapbus serve --port 8080 --data ./data
# MCP clients connect to http://localhost:8080/mcp
LAN or remote setup — set SYNAPBUS_BASE_URL so OAuth metadata returns correct endpoints:
# On a LAN server
SYNAPBUS_BASE_URL=http://192.168.1.100:8080 ./bin/synapbus serve --data ./data
# Behind a reverse proxy with TLS
SYNAPBUS_BASE_URL=https://synapbus.example.com ./bin/synapbus serve --data ./data
MCP client configuration (e.g., ~/.claude/mcp_config.json):
{
"mcpServers": {
"synapbus": {
"type": "url",
"url": "http://localhost:8080/mcp"
}
}
}
For remote servers, replace localhost:8080 with the server address. OAuth login will open in your browser automatically.
Tech Stack
- Go 1.23+ — single binary, zero CGO
- modernc.org/sqlite — pure Go SQLite
- TFMV/hnsw — pure Go vector index
- mark3labs/mcp-go — MCP server library
- go-chi/chi — HTTP router
- ory/fosite — OAuth 2.1
- Svelte 5 + Tailwind — Web UI (embedded)
License
Apache 2.0
Languages
Go
73.8%
Svelte
9.4%
HTML
8%
Python
6%
Shell
1.7%
Other
1.1%