---
schema: "swft.publication/v1"
id: "software-factory-architecture"
title: "How an AI software factory works"
description: "A practical AI software factory architecture explained through task briefs, context engineering, agent harnesses, evals, release, and learning."
summary: "A software factory moves each product request through a clear path: define the job, give an agent the right context and tools, check the result, release the exact version that passed, and use failures or customer feedback to improve the next run."
canonical: "https://swft.io/software-factory-architecture"
author: "SWFT Editorial"
author_type: "Organization"
published: "2026-08-31"
modified: "2026-09-02"
kind: "guide"
section: "Guides"
tags: ["software factory architecture", "how AI software factories work", "agent harness", "context engineering", "AI agent evals"]
evidence_labels: ["INFERENCE", "SELF-REPORT", "STUDY"]
source_ids: ["ai-engineer-harness-engineering", "anthropic-agent-evals", "anthropic-effective-agents", "google-agent-behavior-taxonomy", "latent-space-factory-loops", "latent-space-vercel-agents", "uber-efficient-software-factory"]
authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections."
---

# How an AI software factory works

Follow a product request through its task brief, context, agent harness, proof, release, and learning loop.

> **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections.

## Quick answer

A software factory moves each product request through a clear path: define the job, give an agent the right context and tools, check the result, release the exact version that passed, and use failures or customer feedback to improve the next run.

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](https://www.youtube.com/watch?v=am_oeAoUhew) 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](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) 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](https://www.latent.space/p/vercel-agents-new-software) 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.

## How we know

- **First-party report (SELF-REPORT)** Anthropic, OpenAI, and Vercel practitioners describe complementary agent patterns, harness work, evals, and long-running software primitives in their own settings. Sources: [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents); [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents); [Harness Engineering](https://www.youtube.com/watch?v=am_oeAoUhew); [Vercel: agents as a new kind of software](https://www.latent.space/p/vercel-agents-new-software).
- **First-party report (SELF-REPORT)** Uber reports a layered agent environment, unified tool gateway, managed agents, and an organizational context graph. Sources: [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/).
- **Independent study (STUDY)** Google's agent-behavior taxonomy finds enterprise expectations extending beyond task correctness into process, reliability, problem solving, and collaboration. Sources: [Towards AI as a Collaborative Partner: A Taxonomy of AI Agent Behavior in Software Engineering](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/).
- **Analysis (INFERENCE)** The task-brief-to-learning-loop model and its seven-layer technical reference are SWFT's synthesis for making factory responsibilities understandable and inspectable. Sources: [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents); [Harness Engineering](https://www.youtube.com/watch?v=am_oeAoUhew); [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/); [AIEWF daily dispatch: loops and software factories](https://www.latent.space/p/aiewf-daily-dispatch-loops); [Towards AI as a Collaborative Partner: A Taxonomy of AI Agent Behavior in Software Engineering](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/).

## Sources

- **First-party report (SELF-REPORT)** [Harness Engineering](https://www.youtube.com/watch?v=am_oeAoUhew) — AI Engineer; published 2026-04-16; accessed 2026-09-01. Ryan Lopopolo's first-party account of how OpenAI prepared specifications, tools, feedback, and repository structure around coding agents in a bounded internal experiment.
- **First-party report (SELF-REPORT)** [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — Anthropic; published 2026-01-09; accessed 2026-08-31. Practitioner guidance on task suites, graders, transcripts, and evaluation lifecycle for agents.
- **First-party report (SELF-REPORT)** [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — Anthropic; published 2024-12-19; accessed 2026-08-31. Practitioner guidance distinguishing fixed workflows from agents and describing common orchestration patterns; Anthropic now warns that the 2024 tooling landscape described there has changed.
- **Independent study (STUDY)** [Towards AI as a Collaborative Partner: A Taxonomy of AI Agent Behavior in Software Engineering](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/) — Google Research; accessed 2026-08-31. Research deriving enterprise expectations for coding-agent behavior from developer rules and interviews.
- **Observed artifact (OBS)** [AIEWF daily dispatch: loops and software factories](https://www.latent.space/p/aiewf-daily-dispatch-loops) — Latent Space; published 2026-07-01; accessed 2026-09-01. A dated field dispatch connecting software-factory practice to the complete loop from signals and prioritization through execution, review, deployment, and learning.
- **First-party report (SELF-REPORT)** [Vercel: agents as a new kind of software](https://www.latent.space/p/vercel-agents-new-software) — Latent Space; published 2026-07-03; accessed 2026-09-01. An operator interview covering agent context, tools, resumability, sandboxes, skills, evals, and agent-readable documentation.
- **First-party report (SELF-REPORT)** [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/) — Uber Engineering; published 2026-08-27; accessed 2026-08-31. Uber's account of factory layers, adoption, token economics, managed agents, quality signals, and context infrastructure.

## Read next

- [What is a software factory?](/what-is-a-software-factory)
- [How to build a software factory](/how-to-build-a-software-factory)
- [Software factory metrics that matter](/software-factory-metrics)