What an AI Building System Needs: 12 Practical Parts

What changes when an AI task becomes a real workflow?

One person can usually keep a short AI task in their head. A real workflow has to survive time, handoffs, parallel work, review, and actions outside the chat.

Imagine a three-day product change. On day one, AI turns customer notes into a proposed requirement. On day two, the requirement changes while a product manager and engineer work from different versions. On day three, an automated status says the change is deployed, but approval is still pending.

No single answer from the model caused the problem. The team lacked shared answers to five basic questions: What is true now? What changed? Who owns the next step? What proves the work is finished? What can safely happen without human approval?

Those questions lead to seven jobs: keep truth, organize work, run it within limits, prove results, preserve context, control important actions, and learn from repeated mistakes. The 12 parts in the next section make those jobs concrete.

I developed this map while building and operating WarpOS, my agentic operating-system project. I use WarpOS to build multiple production applications, so these controls are tested continuously against real delivery work. For this article, I froze one public commit and documented the controls running in that version.

The 12 parts, in one view

This table is the operating map behind that work. Use it to see how the pieces connect, then start with the row closest to the bottleneck you need to solve. The last column gives a practical first implementation.

The table keeps the technical detail needed to build or audit the system. What you save means information that survives outside the chat. What checks it means the code or review step that actually uses the rule. A written rule becomes reliable when a runtime check or review gate applies it.

How do you keep one source of truth as the work changes?

The first question is simple: what is the team actually trying to do now? AI cannot protect the goal when source documents conflict, settings move, and requirement changes arrive as stray chat messages.

Keep the original request. Mark what was observed, assumed, or still unknown. Give each important requirement a stable ID. Record meaningful changes instead of quietly replacing the old wording. Together, those records create one shared current version, sometimes called canonical truth.

WarpOS does this in several places. A central path list generates downstream settings and detects stale files. Intake keeps the raw request and source material. A separate plan records assumptions, unknowns, scope, missing evidence, and approval limits. Requirement checks can stop corrupt relationships, stale requirements, and some changes that have not been processed.

Those controls make drift visible and already stop several corrupt, stale, or unprocessed states. As WarpOS expands across more applications, the next scaling step is to promote the highest-risk advisory checks into hard gates. The practical rule is straightforward: preserve the request, label uncertainty, give important requirements stable names, and make consequential changes visible.

How do you stop work from becoming falsely done?

A task tracker matters only when its fields affect what can happen next. If a task can jump to done without an owner, a linked requirement, or evidence, it is a formatted note.

The same applies to the wider workflow. A state machine is simply a list of allowed stages and moves. It might say that work can move from planning to building, but cannot move to released until review and verification are complete.

The frozen WarpOS tree contains 81 saved plan files (YAML) with 81 reports, 700 saved requirement files, and 360 saved task files. That volume comes from repeated use across real application work and gives the system a substantial operating history.

The phase runner is the backbone. It saves planning, design, execution, release preparation, retrospective, stop reports, checkpoints, and resume commands so a new session can see where the work stands. As the system scales, high-risk edge cases graduate from visible warnings into explicit stop conditions.

Start with one rule: a task cannot reach a final state until the required links and completion evidence exist. Once that check actually runs, the tracker starts controlling reality instead of describing it.

How should the system decide who does the work?

A list can say one model is good at planning, another at coding, and another at review. The work has not been routed until the system actually calls the chosen model or tool and records what ran.

The useful distinction is between a recommendation and an executed route. A real router chooses from known capabilities, sends a clear task package, applies limits, records the result, and returns evidence in a shared format.

WarpOS currently uses Claude as its proven top-level coordinator, while Codex and Gemini handle bounded review and specialist lanes. That is a deliberate current architecture built around the controls each lane can reliably support.

The code already performs real provider-aware dispatch in those bounded lanes. The next expansion is to give additional coordinators the same permissions, lifecycle, proof, and recovery contracts. OpenAI and Anthropic documentation supports the broader design choice of keeping routing, approval, tracing, recovery, and lifecycle checks in the surrounding application rather than hoping the model remembers them.

Provider-neutral means models or vendors can change without losing the task, permissions, progress, proof, or recovery plan. To reach that point, a technical team needs shared run, task, review, proof, and error formats; a working connector for each provider; portable checkpoints; outside checks for scope and approval; and the same conformance tests for every provider. A conformance test is simply one test that every connector must pass.

How do you prevent parallel work from colliding?

Parallel workers can touch the same files, repeat the same research, spend the same budget, or approve their own mistakes. Give each worker a clear lane before adding more parallel work.

A useful lane has an owned workspace, an allowlist of what may change, a time or cost limit, a required return packet, and a separate reviewer. In software, a worktree is one practical way to give each worker its own copy of the working files.

WarpOS requires worktrees for core build roles, requires completion claims to include supporting evidence and worker output, and separates creation from review. The next scale layer standardizes that owned-lane contract across every role, including concurrency, file scope, and budget controls.

Independent review is more than a label. The reviewer needs different context, its own verdict, and permission to reject weak evidence. Delegation is useful when checking the returned proof costs less than doing the task again. Otherwise the extra worker has created throughput theater.

How do you know the work is really done?

An AI tool saying done tells you what it believes about its work. It does not tell you whether the product passed its checks, the customer received the message, or the deployment reached the live site.

Define done before the work begins. Then connect each criterion to evidence such as a test result, validated file, receipt, screenshot, live check, or independent review verdict.

WarpOS already has validators for structured files and dispatch checks that require evidence. Its next proof layer joins acceptance evidence, approval validation, and execution receipts into one readiness decision. That is what a production-system audit is supposed to do: turn working controls into stricter production truth.

The fix is a proof ledger, which is a saved record behind the done claim. A deployed result needs a provider receipt or live verification. A passed requirement needs the exact test and result. A reviewed task needs a verdict from someone or something that did not create the work.

Use one completion format: criterion ID, check performed, observed result, file or receipt, reviewer, timestamp, and unresolved risk. When the evidence disagrees with the status, the status loses.

What should the workflow remember?

A confident summary can leave out the exact failure you need to understand. Logs can show which model actually ran, which tool failed three times, where recovery stopped, and what an independent review caught.

Keep five kinds of record separate. An event log says what happened and when. A proof ledger connects a done claim to evidence. A decision record keeps a choice and its reason. Failure history groups repeated problems. Operational memory contains lessons that were checked and are useful enough to apply again.

Raw logs are not memory. They are noisy, incomplete, and often sensitive. Because WarpOS writes structured operating history, the frozen audit could test the event writer against the query surface and define one versioned contract across both. The same scale layer adds stronger redaction, access, retention, and deletion rules for prompt data.

Vendor tracing does not close the gap by itself. OpenAI can record model calls, tools, handoffs, guardrails, and custom activity. Anthropic can export metrics, log events, and beta traces around model requests, tools, and hooks. Those records help explain what happened. They do not prove that the result was accepted or that a past pattern deserves to become a rule.

Logs become operational memory only when the system can search them, summarize the pattern, check it, remove sensitive data, promote useful lessons, expire old ones, and apply the result. Skip those steps and the workflow either forgets too much or remembers the wrong thing forever.

What needs to survive when a session ends?

Assume the current chat or coding session will disappear. A useful checkpoint saves the goal, current state, evidence, decisions, constraints, failed attempts, risks, exact next action, and a recovery point outside the conversation.

WarpOS uses file-based checkpoints, stop reports, resume commands, and handoff hooks. Across the frozen commit, 491 checkpoints show that the mechanism is exercised repeatedly. The recovery boundary is explicit: completed turns can leave durable state for the next session, while a mid-turn hard kill creates a measured loss window because no completion hook can save work it never sees.

Vendor recovery features preserve different layers. OpenAI documents conversational Sessions separately from sandbox state and workspace snapshots. Anthropic Managed Agents can checkpoint a full sandbox while a session is idle, with a documented retention window. These features can restore useful pieces of the work. They do not by themselves prove that outside actions, approval freshness, completion evidence, replay safety, and rollback have been reconciled.

A portable checkpoint points to files and observed outside-system state that survive the chat. A fresh controller that never saw the previous conversation should be able to read it and identify the next action.

Which actions need approval?

Some AI actions only create a draft. Others change the outside world by sending a message, spending money, pushing code, deleting data, or deploying to production. Engineers often call the second kind a side effect.

Approval should bind one exact action to one decision. Approve deployment is too vague if the file, environment, command, cost, or recovery point can change after approval.

WarpOS treats remote pushes, paid signups, production deployments, destructive migrations, and secrets entering tracked or remote storage as hard limits. Outside-service records can block work that is not ready or approved. As coverage expands, I am centralizing sensitivity classification and command coverage so every risky route passes through the same enforcement boundary.

The minimum approval record includes a fingerprint of the exact action, its target, data sensitivity, cost limit, approver, decision, expiry, execution receipt, verification result, and recovery command. Put the gate beside the tool that performs the action, not in a paragraph the model is expected to remember.

Release truth should move in one direction: the intent creates an action, the action creates a receipt, verification checks the receipt, and the report is generated from those records. A human report should not be able to disagree silently with machine state.

How should the workflow learn from mistakes?

Do not save everything and call it learning. Start with a repeated failure. Check the likely cause. Propose one workflow change. Name the code or review step that will apply it. Recreate the failure and prove the new check catches it without blocking valid work.

WarpOS already defines a path from logged pattern to validated lesson to implemented rule. I am extending that path so every promoted lesson names its runtime consumer, passes a recreation test, and carries retention, redaction, decay, and expiry rules. The goal is to turn useful operating history into checks the system can actually apply.

A learning record should keep supporting events, counterexamples, confidence, sensitivity, owner, test, the step that applies the rule, recovery plan, and expiry. A pattern that cannot meet that bar belongs in history or a decision note, not permanent policy.

The best improvement often starts with a boring question: which failure has happened three times, and what check could have stopped the second occurrence?

How is WarpOS getting stronger as it scales?

The frozen WarpOS commit is already a working system used to build multiple production applications. Its 45 release files, 15 release reports, 32 complete retrospective pairs, and 491 committed checkpoints show a system being exercised, measured, and improved through real delivery work.

First, I am expanding the top-level coordinator contract. Claude is the current coordinator. Additional coordinators will earn that role by passing the same tests for tool use, cancellation, approvals, session lifecycle, checkpoint restore, activity records, proof, and review verdicts.

Second, I am consolidating event writing, search, dashboards, and data controls around one versioned format. That includes redaction, access, retention, and deletion rules for prompt data instead of treating observability as unlimited storage.

Third, I am making evidence gates consistent across the full workflow. WarpOS already has the requirement records, task state, and validators; the scale layer applies the strict path wherever the risk justifies it.

Fourth, I am making one release record the machine source of truth and generating every report from it. That gives the release, receipt, verification result, and human-readable report one shared state instead of parallel stories.

Fifth, I am connecting delivery more tightly to launch feedback, product metrics, user interviews, and the post-launch hotfix loop. WarpOS already builds the applications. The next layer makes customer and production feedback part of the same operating system that planned and delivered them.

Where should your team start?

Do not start by recreating all 12 parts. Start where the current workflow spends the most time, loses the most confidence, or creates the most operating risk.

If a new session loses the goal, save the original request and a handoff packet. If parallel workers collide, give them separate workspaces and clear ownership. If done is unreliable, add named completion criteria and an evidence bundle. If nobody knows what happened, version the event format and make it searchable. If outside actions feel risky, put the approval check beside the tool.

Then connect the pieces. Shared truth creates work. Work runs within clear limits. The result returns evidence. The evidence and current state survive a handoff. Approval controls outside actions. Logs feed tested improvements back into the workflow.

A better model can improve the task. This surrounding system helps the work stay reliable after the model finishes its turn.