Architecture

How Busbar Works

Three planes, cleanly separated. Purpose-built for Salesforce + GitHub DevOps, then extensible to any platform. Context feeds templates. Templates orchestrate calls. Calls produce audit frames. Results compose back into context.

CONTEXT PLANEKantextImmutable frames · Content-addressed · Blake3 sealed · Git-groundedFrame N→Frame N+1→blake3:a7f…~20MB/s composition · 150k-340k points/sec · 4-byte deduplicationcontext feeds templatesEXECUTION PLANERacks & ModulesEurorack-inspired · WASM + Monty sandboxes · Hot-swappableRACK: production-deploysf-authsf-restgh-actionspolicy-evalaudit-logjinja-tmplcedar-authorchestrated callsMEDIATION PLANEMCP GatewayZero-trust · Jinja2 orchestration · Cedar authorization · Signal routingModel writesJinja2 template→Cedar evaluatespolicy→Gateway routesMCP calls→Audit framesealedresults compose into new frameC∘VGateCCSignal types from the dashboard
Context Plane

Kantext

Kantext is the structured, living context that the entire system operates on. When a model writes a Jinja2 template to orchestrate MCP calls, Kantext provides the data those templates render against — and captures every result as a new immutable frame.

It's not configuration. It's not state management. It's the Meaning∘Data substrate — fusing context into data as content-addressed, cryptographically sealed snapshots of system reality. Every value has provenance. Every change is a new frame. Nothing is mutated. Nothing is lost.

Composes at ~20MB/s — 150k-340k points/sec
Blake3 sealed, git-grounded, 4-byte deduplication
Emergence detection via hash comparison across frames
What Helm would be if Helm understood what it was configuring
kantext compose
Frame 1
Frame 2
Frame 3
sealed:blake3:a7f2e9c4...
rack: agent-governance
mcp-gw
cedar
audit
policy
sf-rest
gh-act
jinja
—
Execution Plane

Racks & Modules

Inspired by Eurorack modular synthesizers — where Dieter Doepfer's open standard enabled 1,000+ manufacturers and 15,000+ compatible modules. Busbar applies the same principle to enterprise automation.

A Rack is a secure runtime container. Modules plug into standard interfaces. WASM and sandboxed Python (Monty) execution means plugins define intent — the host executes capability. Swap modules freely. The Rack provides isolation, state, and the host-function barrier that keeps credentials safe.

Salesforce-native modules — sf-auth, sf-rest, sf-metadata, sf-bulk work as a cohesive unit; other platforms use the same interfaces
WASM + Monty sandboxes — plugins can't see credentials
Hot-swappable at runtime — no redeployment needed
Community builds modules; Busbar provides the rack and the patch cables
Mediation Plane

MCP Gateway

The zero-trust chokepoint where all traffic flows. Models write Jinja2 templates to compose MCP tool calls. Cedar policies evaluate every invocation against identity, context, and risk classification. Signal routing handles C∘V (immutable facts), Gate (policy boundaries), and CC (change control).

This isn't a wrapper around MCP. It's the architectural bus — the thing that makes the modular system coherent and trustworthy.

Jinja2 templates — models orchestrate tool calls declaratively
Cedar authorization — fine-grained, context-aware policy evaluation
Signal routing — C∘V, Gate, and CC for real-time flow control
Every invocation: identity-verified → risk-classified → policy-evaluated → audit-sealed
busbar gateway

model writes template:

{% for account in sf.query("SELECT Id FROM Account") %}

{{ mcp.call("sf-rest", "update", account) }}

{% endfor %}

cedar evaluates:

permit(principal, action:"sf.update", resource)

gateway routes → 200 OK (47 records)

audit frame sealed → blake3:c4e8f1...

The Loop

Context in. Proof out.

Kan
feeds context
Jin
composes calls
Ced
authorizes
Gat
executes
Aud
seals frame
Kan
new frame

See it in action.

The MCP Gateway is demo-ready. Book a walkthrough or explore the code.

Start a PilotSee Use Cases