The Software Factory.

Three tiers, each inheriting the one below. The company file holds mission, vision, and values, the things that tell anyone, human or agent, whether a piece of work was good. Each function file carries a craft, written once and reused. Each product file defines and specifies the customer surfaces.

Each tier inherits the one beneath it. A product file pulls in its function, and that function pulls in the company, so an agent reading any single file already carries everything above it. Change a value in the company file and every agent downstream sees it on the next run. Nothing is copied, so nothing falls out of sync.

Shared context is what lets a teammate tell a good day from a bad one. Every company that scales writes its operating context down so everyone works from the same understanding. Agents are no different, and you onboard a hundred a day, each ready the moment it reads the file.

Encode that context once and every agent works from the same version of the company. One source of truth keeps a hundred agents pulling in the same direction.

Three habits do the work. Lead with the answer, then support it: the pyramid principle. Split a problem into parts that do not overlap and leave no gaps: MECE. And run every task through the seven circumstances as a checklist, what, who, where, when, why, how, and how much, so it is adequately specified before any agent touches it.

The seven are not a style guide, they are a gate. Run a spec through them and any missing part shows itself. When a task answers all seven, it is ready to hand off.

Clarity is what carries teams, human or otherwise. A person fills a vague brief from a hallway conversation; a model fills it with the most probable token, so the more you specify, the more it gets right. Consultants built the pyramid principle and MECE precisely because a recommendation, like a prompt, gets one shot to land clearly.

An atomic, MECE, answer-first spec reads the same to everyone, so the agent builds exactly what you meant.

David Marr split any computational system into three levels, and the split decides who writes what and where it lives. The goal (what success looks like for the user) and the approach (the method and the hard constraints) live in the agent architecture, written once as durable, time-invariant specs. The implementation, the code, lives in the codebase and is volatile: it changes often. The architecture does not pin it, it keeps a pointer to a current example.

Write the approach down and the model has one path to follow, the same one every run. Pin the goal and the approach; let the implementation stay volatile, referenced as an example. Your half is time-invariant, the code is not.

Models are already near-perfect at anything specified to the algorithm level. Hand one a competitive-programming problem, fully stated, and it returns a correct solution. Raw capability is not the constraint here.

Your feature is the same kind of problem, just rarely specified that completely. Pin the goal and the approach to the level a contest problem states them, and the agent builds it just as cleanly. The spec is the lever, not the model.

Decompose the system into independent, composable parts, each with one job and an explicit contract: typed inputs, typed outputs, no shared state. The contract is the same whether a human or an agent does the work: you hand either one the inputs, the expected outputs, and the single thing it owns.

Composable parts form a directed acyclic graph, a flow of steps with no loops, and a graph you can instrument. Every node carries its own health metric: does it pass its tests, does it hold its contract. You can see exactly which part needs work and fix it in place, rather than debug the whole system at once.

Independent parts are easier to measure, test, and trust. A part with a clean contract can be handed to an agent without it needing to understand the whole system to change one piece, and you can verify that piece in isolation before it touches anything else.

Tight contracts keep each part self-contained. When a part owns exactly one thing, you can let an agent build it, test it alone, and trust the result. The behavior you want falls out of the structure you drew.

Five phases. You scope the work and, later, you resolve it. In between, the agent runs an unattended loop: plan, execute, assess against a rubric, then go again. Two human gates bracket the loop; everything inside runs without you.

Each assess pass is stricter than the last, so the output climbs toward a passing score. The loop stops when the rubric reads ten out of ten.

Once an agent can write the code, the work that remains is judging it. SPEAR moves that judgment to the stage that made the work: the assess rubric raises the bar inside the loop, where a fix is cheap, so what reaches you is already good.

The two gates put human judgment where it matters, deciding what to build and accepting what shipped. The work in the middle is mechanical, so it can run a hundred times unattended.

Give the agent two artifacts: the recipe, a durable process for how the work is done, and the checklist, the atomic steps that each get checked off. The recipe rarely changes; the checklist flips state on every run.

Done is when all the evidence agrees.

A checklist makes the optional-feeling step non-negotiable, so it gets done under pressure. Aviation answered this with the pre-flight checklist. Restaurants answered it with the recipe. A company I ran before answered it with a checklist for every task.

The checklist is how quality scales. Tie done to evidence a machine can read, and verification runs itself.

Drive the real interface the way a user would, assert the real output, and treat the implementation as opaque: what counts is what comes out the end. Define success as the end outcome, write it so a machine can check it, and anchor the assess rubric to that, and only that. Intermediate signals, tests green, types clean, the build compiles, are diagnostics that tell you where you are. The finish line is the outcome itself.

Test the whole surface, not a sample. This is the payoff for keeping parts small and composable: a small surface has a small span, small enough to cover completely. Cover it end to end and every case is accounted for.

Aim an agent at the real outcome and it works toward the real outcome. Aim it at a proxy and it gives you exactly the proxy: a growth team told to lift leads lifts leads, even when revenue holds still, because leads only stood in for revenue. Point the measure at what you want, and what you measure and what you want become the same thing.

So point the rubric at the end and leave the intermediates as instruments. Measure what the user feels, cover the whole span, and the only way to move the score is to do the real work.

Each turn starts with a production signal: a tracked error, a monitor, a customer report. It is triaged automatically into an error (something built wrong) or an omission (something missing), then diagnosed, fixed, and, the part that makes it a flywheel, captured as a permanent check.

Diagnose before you patch. Sort the symptom into one category with evidence, the way a clinician works from a manual, so the fix lands on the cause. A patch aimed at the symptom adds code; a fix aimed at the cause clears a whole class of problems at once, and the check you leave behind keeps it that way.

Capture each fix as a guardrail and the work compounds: every issue you resolve makes the next one less likely, and the error rate keeps falling. That is a flywheel, it spins faster the longer it runs.

SPEAR's assess loop catches errors and omissions before you ship. The flywheel catches anything that reaches production and feeds it back through the same diagnosis. Two nets, one at the gate and one in the field, and whatever the field surfaces becomes a test that guards the next build.

What the agent knows is the architecture. How work flows is SPEAR. Where work happens is the runtime: the process, the checklist, and the rubric that carry state from one iteration to the next. Wire the three together and you can hand off a goal and collect a pull request.

It runs two ways. Proactively, you scope a goal and start a run. Reactively, a failing check or a monitor fires and the same loop diagnoses the cause and repairs it. Same harness, different trigger.

Each piece is load-bearing, and together they compound. The architecture gives the agent the company; SPEAR gives it the gates; the runtime gives it a place to do the work. Apart they are a model with a prompt; wired together they are a system that ships.

This is the methodology behind Ambiguous: more than four million lines of code in thirty days, across fifteen SaaS applications, built this way.