five systems · five different reasons
A compliance boundary. A blind agent. An empty tool registry. A studio that stops when one person is out. A stack nobody wants to rent. Different problems, different people — same pair of hands.
Governed agent execution
No agent tooling could be adopted that was unable to say who did what. So I designed the governance as the substrate rather than a wrapper: every action executes under the requesting human’s identity, passes a tiered authorization gate, and is written to an append-only, hash-chained ledger.
Designed this way because nothing off the shelf survived the compliance review.
product · shipping
Brainbow
Agent browser tools hand the model a DOM snapshot and hand the human a log file, so neither sees what the other did. Brainbow streams a real Chromium at 30fps to a viewer while the agent drives that same session over MCP or REST.
Built because debugging a headless agent by reading transcripts is miserable.
live capture · running system
Synth
Every agent platform eventually stalls waiting on someone to write the next connector. Synth lets the agent synthesize the tool it needs at runtime — and refuses to execute any of it without an explicit human approval, recorded.
Built because the tool registry was always the thing holding the work up.
live capture · running system
PatchBay
In most studios one person knows why that cable goes there, and when they are out the session stops. PatchBay makes the room itself the record — real gear, real jacks, real signal paths, captured once and readable by everyone.
Built for musicians, not engineers. If a patch is hard to explain, the patch is wrong.
product · shipping
OpenAgentics
Plenty of teams cannot put an agent runtime behind someone else’s login. This is mine, MIT licensed and self-hosted end to end. Building it in the open forced every enterprise assumption out of the core and into configuration.
Built because "trust us with your infrastructure" is not an answer for everyone.
live capture · running system
design problems, and how I solved them
These are the hard parts of running autonomous agents inside a regulated boundary — the places where the obvious approach quietly fails an audit. Each is a problem I hit and the design I chose, with the tradeoff stated rather than hidden.
Chain each action into the operator’s own datastore so a replay detects mutation. An audit trail nobody can quietly edit is worth more than a verbose one.
On-behalf-of identity so a cloud action lands in the audit trail as the signed-in person, never a shared service principal. Attribution has to survive the audit, not just the demo.
Inject secrets at call time and discard them; the model never sees a credential. Synthesize, run, discard.
The whole design has to hold inside a disconnected enclave — no egress, local models, identical governance. Air-gap is an architecture constraint, not a deployment flag.
A run may only report success when the downstream check actually passes. Grading reliability honestly is the difference between automation and theatre.
Let a local model carry the routine 80% and escalate to a frontier model only when the work earns it — with per-team metering so the cost is attributable.
The governance architecture runs in production inside a FedRAMP-High-aligned boundary at a federal health agency. Brainbow, Synth, PatchBay and OpenAgentics are mine and public. The interesting part is the decisions underneath — what got rejected, and why.
The background →