Inspiration
The AO Stack was inspired by a recurring problem with autonomous coding agents: they can produce impressive results, but their work is often difficult to trust.
An agent may edit files, run commands, and claim that a task is complete, yet important questions remain:
- What exactly did the agent do?
- Was the work within the approved scope?
- Which tests actually passed?
- What evidence supports the result?
- Should the agent continue, stop, or request help?
- Can another developer audit or reproduce the run?
Most coding-agent systems focus primarily on completing work. We wanted to explore a different question:
How can autonomous software engineering remain useful while also being bounded, inspectable, and verifiable?
That question became the AO Stack.
Our guiding principle is:
[ \text{Trust} = \text{Execution} + \text{Verification} + \text{Evidence} ]
Execution alone is not enough. A reliable agent system must also verify what happened and preserve evidence supporting the result.
What it does
The AO Stack is an evidence-first software factory that turns a software objective into a bounded, tested, and auditable Codex workflow.
Instead of giving one unrestricted agent a large prompt and hoping for the best, AO divides the development lifecycle into specialized stages:
- Records the objective, current state, and next action.
- Converts the objective into explicit requirements, assumptions, constraints, and acceptance criteria.
- Decomposes large objectives into dependency-aware tasks.
- Selects the next safe unit of work.
- Evaluates whether proposed commands, file changes, and side effects are allowed.
- Delegates approved implementation work to Codex.
- Verifies patches, tests, artifacts, and evaluator results.
- Publishes a read-only view of the run history, blockers, evidence, and next action.
- Benchmarks, hardens, monitors, and evaluates candidates before promotion.
The result is not only a code change. The AO Stack produces a replayable evidence trail showing how the change was planned, authorized, executed, tested, and evaluated.
How we built it
We built the AO Stack as a multi-repository architecture with explicit responsibility and authority boundaries.
Each component owns one part of the workflow. Planning systems do not automatically gain execution authority, observer systems cannot approve changes, and evidence storage remains separate from promotion decisions.
The primary workflow is:
Objective
→ Requirements
→ Workgraph
→ Safe task selection
→ Policy decision
→ Codex execution
→ Tests and evaluation
→ Evidence bundle
→ Operator readback
Codex performs bounded software-engineering tasks. We used GPT-5.6 during development to help clarify requirements, plan work, interpret results, evaluate outcomes, and improve the system’s documentation and operator experience.
The stages communicate through structured contracts and digest-bound artifacts. Important outputs are stored as machine-readable records rather than existing only in terminal output or chat history.
These records include:
- mission and routing records;
- requirements and authorization packets;
- dependency-aware workgraphs;
- policy decisions and approval tickets;
- execution plans and generated patches;
- test and evaluator results;
- evidence packs and cryptographic digests;
- safety and regression verdicts;
- promotion and rollback plans.
We also created read-only operator interfaces that explain what happened, what evidence was produced, whether the run passed its gates, and what should happen next.
For Build Week, we focused on presenting the AO Stack as one coherent goal-to-proven-change demonstration while strengthening the reliability, portability, and verification of that workflow.
Challenges we ran into
The biggest challenge was reliable agent execution.
Generating code was only one part of the problem. The harder task was ensuring that every transition remained correct as work moved across multiple repositories, tools, policies, and execution stages.
Preventing authority drift
A component that displays status should not silently gain the ability to execute work. A scheduler should not become an approval system, and an evidence store should not become a release authority.
We had to define and enforce strict boundaries between planning, policy, execution, observation, and promotion.
Knowing when an agent should stop
Autonomous systems can continue creating tasks even after the original objective has been satisfied. AO uses explicit acceptance criteria, readiness gates, blockers, leases, and stop conditions to prevent endless or invented work.
Preserving trustworthy evidence
Evidence is only valuable when it remains connected to the exact input, decision, command, patch, or test that produced it. We used structured records and content digests so that modified, stale, or mismatched artifacts can be detected.
Coordinating multiple repositories
Because AO is composed of specialized repositories, we needed to maintain compatible contracts, handoffs, version boundaries, and failure behavior across the entire stack.
Supporting multiple operating systems
File paths, line endings, shell commands, release archives, and verification scripts behave differently across Linux, macOS, and Windows. Making evidence and verification deterministic across these environments required significant portability work.
Accomplishments that we're proud of
We are proud that the AO Stack is more than an architecture diagram or a single-agent demonstration.
The system includes a runnable governed-execution workflow, structured policy decisions, dependency-aware planning, evaluator closure, evidence packs, operator readbacks, regression monitoring, and promotion gates.
We are especially proud of:
- separating planning, approval, execution, observation, and promotion authority;
- producing replayable evidence rather than relying on terminal scrollback;
- binding approvals and artifacts to exact content digests;
- supporting bounded Codex execution with explicit acceptance criteria;
- detecting blockers and returning precise next actions;
- implementing read-only dashboards and operator interfaces;
- creating benchmark, adversarial-testing, regression, and rollback workflows;
- strengthening cross-platform behavior across Linux, macOS, and Windows;
- demonstrating how multiple agentic components can cooperate without becoming one unrestricted autonomous system.
Most importantly, the AO Stack can return more than a vague “done” message. It can return a verified result, a clearly explained blocker, or a precise request for human input.
What we learned
The most important lesson was that verification cannot be added only at the end of an autonomous workflow. It must be part of the architecture from the beginning.
We also learned that stronger constraints can make agents more useful rather than less useful.
A bounded agent with:
- an explicit objective;
- limited file and command scope;
- clear acceptance criteria;
- independent policy checks;
- required tests;
- durable evidence;
- and a defined stop condition
is easier to operate confidently than an agent with unlimited freedom.
Another major lesson was that evidence should be treated as a product feature. Developers should not have to reconstruct a run from terminal output, partial logs, or a vague completion message. They should be able to inspect a concise record of what changed, why it changed, how it was verified, and what should happen next.
What's next for AO Stack
Our next product milestone is a governed autonomous GitHub issue-repair routine. AO already has the foundations for bounded issue-to-draft-PR work; the next step is to make that workflow practical for routine repository maintenance:
- Accept an explicitly authorized issue from an allowlisted repository.
- Reproduce and classify the problem before changing code.
- Convert the issue into acceptance criteria, scope limits, and a dependency-aware work plan.
- Create an isolated branch, implement the smallest justified repair, and run the repository's required tests and policy gates.
- Preserve the issue, plan, commands, patch, test results, and digests in an evidence pack.
- Open a draft pull request that links the issue and summarizes the evidence.
- Stop for human review before merge, release, deployment, permission expansion, or any action outside the original authorization.
The routine must also recover cleanly from interrupted runs, stale branches, failed tests, changed issue scope, and conflicting repository state. When AO cannot prove that a repair is correct and authorized, it should return a specific blocker or request for human input instead of publishing a change.
The long-term goal remains simple: a developer provides an objective or an authorized issue, and AO returns a proven draft change, a clearly explained blocker, or a precise request for human input. Every important action remains bounded, reviewable, and supported by evidence.
Log in or sign up for Devpost to join the conversation.