Build under containment
Agents work in an OS-sandboxed workspace with two-axis permissions and argument-level tool scopes. Every consequential action is a checkpoint a human can see, and stop.
The governance plane for small software
Ship, share, and run agent-built apps as easily as a Google Doc. Every release is published through five evidence-bearing gates, metered with its own keys and spend caps, and recorded on a signed audit chain. Wherever it was built. Wherever it runs.
The premise
Small software, the purpose-built tools that will only ever have one user or a handful, used to be hard to write. Not any more: an agent builds one in an afternoon, and every team has an endless backlog of them. The workflow tracker shaped like how you actually work. The sprint board. The intake form. The dashboard for the one number that matters. The prototype three colleagues need to try.
The incumbent clouds were designed for Big Software, and carry Big Software's complexity. And the hard part now is everything after the build: reviewing what the agent produced, deciding who may open it, knowing what it costs, proving what it touched, and turning it off when it misbehaves. Across a fleet of apps nobody read, that's the whole job.
“Small software should be as easy to share with your colleagues as a Google Doc.”
Agents work in an OS-sandboxed workspace with two-axis permissions and argument-level tool scopes. Every consequential action is a checkpoint a human can see, and stop.
Five gates run at publish and attach persisted evidence to an immutable release. A bundle with no dependency audit fails closed. Absence of proof is not proof.
Every app carries its own scoped, separately-metered key, a spend cap, a deploy target, and a signed audit trail, so a thousand of them stay legible.
The workbench
OpenCatalyst is an agent workbench first. Brief a task, and one model or a team of them plans, writes, and tests inside an OS-sandboxed workspace, pausing at approval checkpoints before anything consequential. The motion you already know. The difference is what sits behind the composer.
The demo · scripted, honest
A faithful slice of the product, three acts long: brief the agent, gate the release, govern the fleet. It pauses where the real thing pauses, on a human. And everything you press lands in the audit strip at the bottom, because that is the product.
Build a reconciler that matches our bank export against open invoices and flags anything it can't pair. Keep it a single package with tests. The export is in ~/exports.
auto → opus · turn 1Plan: read the export header for the real column names, scaffold the package, write the matcher, run the suite. Three vendors bill a flat $1,200.00, so amount-only matching collides. I'll add a date window plus a reference token.
read_file ~/exports/bank-export-2026-07.csv
run_bash npm init -y && npm i -D vitest
edit_file src/match.ts+11 −4
- invoice: open.find((i) => i.amount === row.amount)+ const near = open.filter((i) => Math.abs(i.amount - row.amount) < 0.005)+ return near.length === 1 ? near[0] : byReference(near, row.memo)
To verify against the real export I need to run the CLI over ~/exports. That's outside my write root, so it's your call.
node dist/cli.js --in ~/exports/bank-export-2026-07.csv --out ./out/unmatched.csv
run_bash node dist/cli.js --in ~/exports/… --out ./out/unmatched.csv
Done. Two unpaired rows flagged, both flat-amount vendors. The grant was once, so it's already expired.
denial returned as a tool error, not a crashUnderstood. I'll validate against a redacted fixture inside the workspace instead.
run_bash node dist/cli.js --in fixtures/sample.csv
Matcher verified on the sample. The real export stays untouched.
ed25519 9f2c…c41a
link token minted · app-scoped · hash stored at rest
A gate that can't produce evidence fails closed. The release never exists.
Deny an agent's command and it revises. Fail a gate and the release never exists. Enforcement isn't a report. It's the shape of the pipeline.
Access denials are audit events too. What was refused is as much of the record as what ran.
Portable governance
Governance that only works on apps built inside one tool is a feature. Governance that follows the app, wherever it was built and wherever it runs, is a plane.
The claim this product rests on is not that we can run inside your network. Everyone can, now. It's that running ungoverned software inside your network is the actual problem, and the governance has to follow the app.
Which is why we spend as much on gates, meters, audit, and revocation as on the agents that write the code.
Early access
We're onboarding a small group of design partners, agencies and platform teams that operate fleets of internal tools.