Building in Stealth

Why build my own

The part of the work I like most is the beginning: a messy problem, no playbook, and something real to build. Inside a large company, that part is usually over by the time a project reaches you. Building my own product means owning all of it, from the first design decision to the security model.

It's also a chance to answer, from the first commit, the question my work at Meta kept coming back to: what does it take for people to trust an agent with real work? At Meta I came at it from the outside, with evals and standards around systems that already existed. Here it's in the foundations.

The spec is the first product

Before writing code, I wrote the product down. The design doc went through 9 drafts, the last one reviewed in separate passes for completeness, security and privacy, simplicity, and consistency. The build spec that came out of it runs to 6,000+ lines and covers the app, the server, and the staff console, down to the database schema and the tests that close each milestone.

The spec is written for a coding agent to build from, and that shaped how it reads. It sets an order of work. It sets a precedence rule for when sources disagree: the security invariants first, then the spec, then the design docs, then the agent's own judgment. And it says what to do when something isn't specified: choose the simplest option that keeps the invariants, record the decision in one line, and keep going.

That's the agent-ready idea from Meta at the scale of one product and one coding agent. What an agent reads is a production input, so it gets the same care as the code.

Trust, designed in

The 10 security invariants hold at every milestone. A change that breaks one can't merge, and each has its own test. A few of them say a lot about how an agent should be built:

• The model never sees credentials or secrets. Tools take ids, and the server looks up the rest itself.
• Every write to another system is gated, and needs the confirmation that action calls for.
• Prompts can't turn off security. The safeguards are code, and a prompt change can only take tools away.
• Staff can't read customer content without a grant, and the database enforces it.
• Every model call is metered and budgeted, before and after it runs.

Quality gets the same treatment. Every change to the agent's prompts, model settings, or limits ships as a new version, and evals gate it before it reaches anyone. Then it goes out in rings: internal first, then early access, then everyone. It's the release discipline I led evals for at Meta, built in from the start instead of retrofitted.

A deliberately small stack

Some of the most important choices are what's left out: no agent framework, no ORM, no vector database, no cache layer. The agent loop is code I own. SQL is the schema of record. One module talks to the model, so changing providers is a change in one place. The goal is a system small enough to hold in my head, with nothing in it I can't explain.