Missions & Approvals

The mission system: how one sentence becomes real work

The mission system is the core of AOS. It is how one sentence of founder direction becomes real, reviewed work, with an owner, an acceptance bar, non-goals, and the evidence required before anything ships. This article explains the moving parts. From a sentence to a scoped workstream You write a one-line priority in plain English. The CEO agent reads it, drafts a founder brief, and asks at most two clarifying questions. The brief always contains: - A working goal. What success looks like in one line. - Three non-goals. What this mission will deliberately not do, so scope does not creep. - The shape of acceptance. The rough bar the work has to clear. Nothing executes until you confirm the brief. Department leads write the operating plan Once confirmed, the brief moves to the right department leads. They assign specific owners, write the acceptance criteria, and mark which of the five approval points apply. A single mission often spans several departments. For example, Customer Success owning a target while BizOps owns the escalation path. The four-step review on every artifact Before anything reaches you, a four-step review runs on each artifact: 1. The builder reviews their own work. 2. QA tests it against the acceptance bar. 3. A department reviewer reads it with fresh eyes. 4. Security scans for anything that crosses a boundary. Evidence and memory Every artifact, draft, decision, and reviewer is captured in the evidence trail. Operating memory carries decisions and their reasoning across missions, so the next mission that touches the same territory inherits all of it. You get a founder summary written for you, not for an auditor; the audit lives on the dashboard, two clicks away. Running missions in parallel There is no technical cap on concurrent missions. The practical limit is your attention for the five approval points; three to five at a time is typical. You can pause any mission mid-flight, and if a mission fails it surfaces in the founder summary with the rationale so you can retry, pivot, or kill it.

Acceptance criteria: how AOS defines done

Every AOS mission has an acceptance bar, a written definition of what "done" means before any work begins. This is what keeps the 61 specialists producing real work instead of busy work, and it is the standard QA tests against before anything reaches you. If you read one thing about how AOS guarantees quality, read this. What acceptance criteria are Acceptance criteria are the specific, checkable conditions a piece of work must satisfy to count as complete. They are set when the department leads scope the mission, and they are visible on the Mission Control dashboard from the moment work starts. A good acceptance bar is concrete and testable. Not "improve onboarding" but "Day 1, 7, and 30 emails rewritten, activation measured weekly, deliverability verified above 95 percent, and a before-and-after comparison attached." Vague goals produce vague work. Concrete goals produce work you can check in a minute. Where they come from - The founder brief defines the working goal and three non-goals. - The department lead translates that into acceptance criteria with a named owner and a deadline. - QA adopts those exact criteria as its test plan, word for word. Because the same criteria flow from your brief to the builder to QA, nobody gets to quietly redefine success halfway through. How acceptance is enforced Work is not "done" because an agent says so. It is done when it passes the four-step review: 1. The builder self-reviews against the acceptance bar and fixes its own misses first. 2. QA tests against that bar and rejects anything that falls short, sending it back with specifics. 3. A department reviewer reads it with fresh eyes for quality and fit. 4. Security scans for boundary crossings and risky changes. Only after all four pass does the artifact land in your Friday founder summary. The evidence trail records each reviewer and their verdict, so you can always see why something was accepted, not just that it was. What a rejection looks like When QA rejects work, it does not silently retry forever. It records the gap, returns the work to the builder, and the loop runs again. If something keeps failing, it surfaces as a blocker in your summary instead of burning tokens in a circle. You see the stuck point rather than a mystery. Why non-goals matter The three non-goals in every brief are as important as the goal. They stop scope creep, keep token spend predictable, and make the acceptance bar honest. The team is graded on the thing you actually asked for, not a sprawling reinterpretation of it. If you find yourself wanting to add a fourth goal mid-mission, that is usually a sign it should be its own mission with its own bar. How to write a good acceptance bar yourself You do not have to, the department leads will, but if you want tighter control: state the deliverable, the measurable outcome, the format you want it delivered in, and what you explicitly do not want touched. The more specific you are, the less back-and-forth, and the closer the first draft lands to what you pictured.

The five approval points: the decisions only you should make

AOS does an enormous amount of work autonomously, but a small set of decisions should only ever be made by the founder. Those are the five approval points. When a mission hits one, it pauses that thread, writes a recommendation with the rationale and the alternatives, and waits for you to click yes or no. These are the only places customer data, secrets, and production access are allowed to cross. The five approval points 1. Money over a cap. Any spend, refund, discount, or commitment over a number you set. The defaults are $1,000 per move and $10,000 per week, both adjustable at install. 2. Public claims. Anything that goes out under the company name claiming a fact: press, website, decks, paid copy, or customer email blasts above 500 recipients. 3. Customer data leaving the boundary. Any move that puts identifiable customer information outside the workspace: a vendor integration, an export, a third-party share, or an AI training opt-in. 4. Production-touching changes. Code deploys, infrastructure changes, billing rules, and security policy. AOS drafts and reviews every one; you flip the switch. 5. Audit-trail edits. Deleting evidence or editing a logged decision after the fact. Rare, and the most important when it fires. What you see when one fires An approval point lights up in your queue with three things: the recommendation, the rationale behind it, and the alternatives. You decide, and the mission continues with that branch confirmed. Your decision and its reason are written into the evidence trail, and the next mission that touches the same area inherits the context. Adjusting your thresholds The money caps are set at install and can be changed at any time. If you find a particular approval point fires too often or not enough for your comfort, tune it. The goal is for approvals to capture exactly the decisions you want to keep and nothing else. How approvals relate to autonomy Everything outside the five approval points proceeds without you. The practical limit on how many missions you can run in parallel is your own attention span for these approvals; most founders comfortably handle three to five concurrent missions.

Guardrails: how AOS stays safe and on-track

Guardrails are how AOS lets an agent company move fast without letting it do something you would not want. The whole design assumes the team is capable and that a small number of decisions must always belong to you. This article explains the guardrails and how to tune them. The five approval points These are the only places work crosses your boundary, and each one waits for your explicit sign-off: - Money over your cap. Any spend, refund, or commitment above your limit (default 1,000 dollars per move, 10,000 dollars per week). - Public claims under your company name. Anything published, sent, or stated publicly that represents the business. - Customer data leaving the boundary. Integrations, exports, shares, and training opt-ins that move real customer data. - Production-touching changes. Deploys, infrastructure, billing, and security policy changes that affect live systems. - Audit-trail edits. Any change to the evidence record itself. Everything that stays inside these lines runs autonomously. Everything that would cross one stops and asks. The self-review loop Before anything even reaches an approval point, it passes a four-step review: the builder self-checks against the acceptance bar, QA tests against that bar, a department reviewer reads it fresh, and security scans for boundary crossings. Risky or low-quality work gets caught and sent back before you ever see it. By the time something waits on you, it has already survived four passes. Non-goals as a guardrail Every mission carries three explicit non-goals. They keep the team inside the lane you set, stop scope creep, and keep token spend predictable. A guardrail is not only about danger. It is also about staying on the thing you actually asked for. The evidence trail Every artifact, draft, decision, and reviewer verdict is captured and is two clicks away. This is the guardrail that makes the others trustworthy: if you ever need to know why something happened, the record is there. Nothing important is a black box. Tuning your guardrails Guardrails are dials, not walls you can never move: - Lower your money caps early when you want more control, then raise them as trust builds. - Keep public-claims approval on if your brand voice matters, which for most founders it does. - Tighten non-goals on any mission that drifted last time. - Start token caps conservative and adjust once you know your real burn. The point is calibration. Set the guardrails where you are comfortable, watch a few missions, and adjust. AOS is built to earn autonomy gradually so you are never surprised by what it did on its own. What guardrails are not They are not bureaucracy for its own sake. A good guardrail stops exactly the things that should stop and gets out of the way for everything else. If you find too much routing to you, that is a signal to raise a cap, not a flaw. You are in control of how tight the rails are.