BuildEx

The challenge

Every "AI for work" product is the same shape: a chat box in someone else's cloud. To get value out of it you upload your company (strategy, client notes, finance, decisions) into a system you do not control, cannot inspect, and cannot leave without losing the accumulated context. The knowledge that makes the tool useful is the exact knowledge you should be least willing to hand over.

Meanwhile the tool that is genuinely good at working across a company's files, a coding agent, is unusable by the people who run companies. It lives in a terminal, it has no concept of "do not email that client without asking me", and one bad autonomous decision is indistinguishable from a good one until after it lands.

So the operator gets a choice between a chat box that cannot do anything real, and an agent that can do too much with no brakes.

What I am building

BuildEx is the seam between those two. The company's brain is plain markdown in git repos on the operator's own machine. The agent that works on it is the operator's own signed-in Claude Code, driven by BuildEx but never owned by it. The cloud does one job: move commits between machines. It cannot read the brain and it never sees model traffic.

Git is the database. No shadow store, no vector index pretending to be memory. Every artifact is a file, every change is a commit, the whole history is inspectable and reversible with tools that already exist and will outlive the product.

Wide autonomy, few gates. The agent works on its own across local files, the web, and connected tools. A small operator-configurable set of actions covering money, outbound to people and anything irreversible stops and waits for a tap. The gate is the design centre of the whole system, so it is built to fail closed: every error path, including an unreachable daemon or a malformed response, maps to deny. A bug cannot silently let an action through.

The conductor bright-line. BuildEx never reads an agent's credential store, never proxies model tokens, never sets a provider API key. That is enforced by a test asserting the key stays undefined, not by a policy document. It is also the business model: no token resale, no margin on someone else's inference.

Trust surfaces are deterministic. The map, the history, the admin views render from repo state with zero LLM involvement. The parts of the product you consult when you are worried are the parts that cannot hallucinate.

Ten invariants hold the architecture. Five of them are backed by invariant test suites that are release gates and cannot be skipped, and a meta-test scans the monorepo and fails if that tagged set is not exactly those five, so the gates cannot be quietly removed either.

Where it is

Pre-alpha, v0.1.4, MIT, built in the open. This is the one case study here with no results section, because there are no results yet. What exists:

• The full operator console: sessions, brain, docs, history, map
• A signed and notarised one-click macOS download
• The agent reading and editing the brain, gated at outward actions
• Git-as-database with full history and restore
• An app store of capability packs installed per company
• Skills, which teach the agent a company's own verbs

Not there yet: in-app auto-update, live Gmail/Slack/Notion without bringing your own OAuth app, hosted sync and seats, a signed Windows build, and the fully self-serve onboarding a non-technical operator will need.

Why I am building it in public

The claims that matter here are security claims, and a security claim you cannot check is marketing. So the repo is MIT and every claim in the README points at the file that implements it and the test that pins it. If the approval gate does not fail closed, that is falsifiable in about ninety seconds by someone who has never met me.

It is also the honest version of what I sell. I advise companies on exponential operating models; BuildEx is that model compiled into software, running my own company while I build it.