Picture a checkout bug entering the system as a clear request and leaving as the exact fix that passed its checks. The path between those points can fit on one line:
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 is a current first-party account of this systems work around coding agents. The exact design belongs to one bounded OpenAI experiment, but the underlying questions transfer: Is the repository easy to navigate? Are checks fast? Can the agent see the result of its actions? Can it recover cleanly?
4. The proof loop checks the result before attention is spent
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. In friendlier language: give the system realistic practice cases, define what good looks like, and keep a record of how it reached the answer.
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 |
These are responsibilities, not a requirement to buy seven services. A small team can keep them 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.