An AI software factory connects a request to implementation, checks, release, and feedback. A practical architecture gives each part an owner and keeps the work history available as the task moves between them:
task brief → context engineering → agent harness → proof loop → release → learning loop
Guardrails surround the complete path. They decide what an agent may do on its own and where a person must step in.
How does work move through an AI software factory?
1. The task brief turns a need into a testable job
A customer request, incident, or product idea enters as a task brief. It names the outcome, limits, owner, risk, and definition of done. A good brief separates settled product decisions from questions the agent must not guess at.
2. Context engineering supplies what matters now
Context engineering selects the code, product rules, examples, decisions, and live facts the agent needs for the next step. The supplied context should be small enough to use and complete enough to prevent avoidable mistakes. The system should also record where sensitive information came from and what the agent may do with it.
3. The agent harness lets the agent act safely
The agent harness combines the model with instructions, tools, context, memory, a sandbox, and a way to resume after interruption. A sandbox is an isolated workspace with limited access. The agent can edit and run code there without automatically gaining access to every secret or production system.
Harness Engineering describes how one OpenAI team prepared its environment for coding agents. The account suggests concrete questions for another team: Is the repository easy to navigate? Are checks fast? Can the agent see the result of its actions? Can it recover cleanly? HarnessTax examines how different harnesses affect performance and cost on two benchmarks.
4. The proof loop checks and repairs the result
The agent makes, checks, and corrects its work before asking a person or the continuous integration (CI) system to review it. Tests, screenshots, policy checks, and evals can all take part. An eval is a repeatable product scenario with a scoring rule, such as “an expired discount code preserves the cart and explains what happened.”
Anthropic's evaluation guide describes tasks, graders, and traces: realistic practice cases, rules for judging the result, and a record of how the agent reached it.
5. Release carries the checked version to users
The tested version must be the version that is reviewed, merged, deployed, and observed. A green check for yesterday's code cannot prove today's release. The release record should connect the exact change to its checks, approvals, deployment, and user-visible result.
6. The learning loop improves the next run
Production feedback, failed checks, and review corrections become better briefs, context, tools, evals, or guardrails. AI engineers sometimes call the work cycle the inner loop and this system-improvement cycle the outer loop. The outer loop matters because fixing one bad patch does not prevent the same failure next week.
Where do people stay in control?
Human steering should be attached to decisions, not sprinkled vaguely across the process. Product and engineering leaders should be able to answer:
- Who chooses the goal and definition of done?
- What may the agent read, change, spend, or release?
- Which product, security, legal, or architectural choices need approval?
- What uncertainty makes the run stop?
- Who owns the result after it reaches users?
The Vercel operator interview connects long-running agents with resumability, sandboxes, skills, current documentation, and feedback cycles chosen by risk. It is one operator's account, not a universal recipe.
The technical reference
Teams that need a deeper architecture can divide the same flow into seven responsibilities:
| Layer | Product question | Concrete record |
|---|---|---|
| Intent | What outcome are we asking for? | Task brief |
| Context | What does the agent need to know? | Supplied context |
| Orchestration | What happens next, and when does work stop? | Run plan |
| Execution | Where can the agent act safely? | Reproducible sandbox |
| Verification | What proves the result is acceptable? | Run evidence |
| Delivery | Did the checked version reach users? | Release record |
| Learning | What should change before the next run? | Reviewed correction |
A small team can keep these responsibilities in one repository. A larger organization may split them across platforms and owners.
What is the smallest useful architecture?
Start with one recurring job, one repository, one safe workspace, one deterministic check, one protected release path, one run record, and one named person for exceptions. Add multiple agents, persistent memory, proactive triggers, and dynamic routing only when measured results show they improve the work.