We built AOS by pointing AOS at the job of building AOS. The work taught us more than any feature did. This is the honest record of what actually happens when you hand a company to a team of agents.
No spin. Several of these were mistakes before they were lessons. If you are thinking about running your own agents, read all twenty before you start.
Left alone, a team of agents will generate enormous activity: drafts, plans, reviews, re-drafts. Activity feels like progress and is not. The single most important thing we did was learn to measure shipped outcomes, not entries in a log. If a week produces a hundred updates and three of them touched the real product, the number that matters is three.
We built a thorough, well-tested specification of the product and a demo that walked through it on real fixtures. It was easy to mistake that for being almost done. It was not. Staging contracts and dry-run scripts are design and de-risking, which is real and valuable, but the production build is a different and much larger job. We say so out loud now.
Writing the contracts, the schemas, and the tests is the part that goes fast and feels great. Live infrastructure, real auth and secrets, the long tail of production edge cases, the integration that only breaks when it is wired to something real: that is where most of the cost actually lives, and almost none of it is done when the spec is done.
The cheapest, most honest signal we found. If a sprint produces a hundred outputs and three touch the actual product, that is the cue to redirect the team from writing about the thing to building the thing. Without the tag, a wall of polished documents reads like progress and quietly is not.
When you hand a goal to a team of agents, they split it into many small tasks, and each one files its own proof. Twenty tasks become twenty entries for one outcome. The fix is the same compaction rule we built into the product: one milestone entry per shipped result, with the detail underneath, not twenty restatements of the same work.
We found the same pricing model, the same objection list, and the same copy pack written many times over, each pass labeled as a fresh accomplishment. Reconciliations and deltas of an existing asset are version churn. Keep the latest canonical one, delete the rest, and do not let a re-pass count as a new deliverable.
Reopening a command center, clearing a blocker link, writing a staffing note, confirming that lanes are still moving: this is overhead, not output. It belongs in an operations log if anywhere, never in the record of what got built. Mixing the two makes a busy week look like a productive one.
Our internal build record grew to tens of thousands of lines because the same boilerplate was restated on every entry. Long, repetitive entries are expensive twice: a human will not read them, and an agent re-reads the boilerplate every time, which burns tokens. A tight summary with a link to the evidence does the same job for a fraction of the cost.
A running log shows motion. It does not tell you whether the product is getting closer to sellable. The most useful single artifact is a one-page board: checkout, provisioning, auth, billing, onboarding, support, website, legal, each marked Not started, Designed, Built, Tested, or Live. That board tells the truth a log hides.
When the definition of done is fuzzy, agents keep reopening the work, polishing it, and finding one more pass to run. A finish line stated up front, with an acceptance bar, is what lets a lane actually close instead of looping. Without it, the most diligent team will keep itself busy on the same task indefinitely.
One of our sharpest mistakes was letting internal task detail leak toward what a customer would see. Founders do not want to read raw operations. They want to act in one place on the few things that need them. The internal record and the founder view are two different products, and conflating them serves neither.
Moving money, shipping a public claim, touching customer data, changing a live system: these need a person to say yes. We built hard approval points for exactly these, and the discipline paid off. The first time a public claim implied something we had not actually earned, the gate caught it before it went out. That gate is not friction. It is the product.
The most valuable thing the build produced was not a feature. It was the candid account of what worked, what did not, and what is still a mock. Sophisticated buyers can smell overclaiming, and they trust a team that names its own limits. We would rather lose a sale to candor than win one we cannot keep.
Agents do not feel a token bill. Long, looping tasks quietly run up real money. We learned to put a budget on each mission, surface per-agent and per-department spend, and watch for it. A cost governor is not a nice-to-have once a team of agents is doing real volume. It is the difference between a margin and a surprise invoice.
A task that runs a long time accumulates context, and re-reading all of it on every step gets expensive and slow. Automatic compaction, summarizing the history and carrying the summary forward, keeps a long task affordable. The same idea that keeps the build record lean keeps an individual mission lean.
Sometimes a task stops making progress but keeps consuming effort: the same step, retried, going nowhere. A human glances past it. An automated stale-loop check catches it and stops the bleed. Detecting the loop that is spinning without moving is one of the highest-payoff guardrails in an agent system.
The compounding value is not a cleverer one-off output. It is a system that remembers the decisions already made and does not relitigate them. When a new piece of work contradicted a call made weeks earlier, the value was surfacing the old decision instantly so it got reconciled in one note instead of a two-day argument. A system that forgets is a system you manage. A system that remembers is one that helps.
We set a rule early: a hold on the public launch must never stop the safe internal work. That single rule is what let product, brand, go-to-market, support, and docs all keep moving while one gated lane waited. Without it, one blocked decision stalls eight teams. With it, the blocked lane waits and everything else ships.
The system orchestrating all of this work is real and it works. That is the engine. The thing a customer buys is a separate artifact, and its progress has to be measured on its own terms. It is easy to point at a working build tool and feel the product is nearly done. It is not the same thing, and pretending otherwise is how you ship a demo and call it a launch.
The strongest output names its own uncertainty. When the inputs were thin, the honest move was to say what was most likely and what would confirm it, not to manufacture a number that looks authoritative. A fabricated benchmark or a made-up figure is worse than an honest range, because the first time a buyer catches one invented number, they stop trusting all of them.
A team of agents will do an astonishing amount of work. Your job stops being to do the work and becomes to point it at the right thing, hold the line on what counts as done, keep the risky moves behind a human, and stay honest about what is real.
That set of jobs is exactly what AOS is built to give a founder. The lessons above are not a warning against running agents. They are the operating discipline that makes running them pay off, and it is the same discipline we install.