From software factories to agent-native delivery
“Software factory” predates coding agents. A 2006 Microsoft article described a software factory as a collection of tools, reusable code, documentation, reference implementations, templates, and guidance that automates accepted patterns and standards. The emphasis was industrialized reuse and consistent construction, not autonomous agents. (Microsoft) The term later became common in enterprise delivery programs. In AWS’s BMW case study, “Software Factory” means a shared set of processes, methods, and tools supporting thousands of developers and a large continuous-integration workload. Those figures describe BMW’s program as reported by AWS. They are not benchmarks for every factory. (AWS) The current agent-native use keeps the repeatability and control, but changes who can perform the work. Agents can inspect repositories, draft plans, edit code, run tools, collect evidence, and revise their work. That makes context quality, delegated authority, stop conditions, evaluation, and traceable decisions part of the production system.Is an AI software factory the same as DevOps or platform engineering?
No. DevOps is a set of cultural and technical practices that joins software development and operations. Platform engineering builds and maintains an internal platform, often with paved paths that developers can use safely. CI/CD automates integration, testing, packaging, and delivery. (Google Cloud on DevOps and platform engineering, Google Cloud on CI/CD) An AI software factory can use all three. Its distinguishing scope is the controlled path from an incoming signal through intent, context, agent work, proof, judgment, shipping, and learning. In addition to “Can this change build and deploy?”, it asks “Why should it exist, what authority did the agent have, what evidence supports the result, and what should the next run learn?”Why one agent, specification workflow, or pipeline is not a factory
A coding agent can complete a bounded task without a standard intake, durable evidence, shipping authority, or feedback loop. A specification-driven workflow can structure intent and plans without executing or operating the resulting software. A CI/CD pipeline can test and deploy a change without deciding whether the change serves the right user problem. Calling any one of these a factory hides the missing controls.
The factory contains tools and workflows. It is not the name of one tool.
How an AI software factory works
The eight-stage model below is Plannotator’s independent editorial synthesis. It is not copied from a vendor architecture and is not a list of Plannotator product capabilities.
Eight-stage agent-native delivery loop
Each stage produces an inspectable input for the next. Learn feeds the next Signal, Intent, Context, or gate.
- 1. Signal
Capture a user need, incident, support pattern, obligation, or measured opportunity.
- 2. Intent
State the desired result, scope, constraints, owner, and observable acceptance criteria.
- 3. Context
Select current code, data, decisions, examples, conflicts, and freshness notes.
- 4. Plan
Order the changes, dependencies, risks, verification steps, and stop conditions.
- 5. Execute
Let agents and people make the bounded changes with least-privilege tools and checkpoints.
- 6. Prove
Run tests and scenarios, capture receipts, and expose failures instead of summarizing them away.
- 7. Judge and ship
Apply policy and risk-based judgment, then release, revise, reject, or hold.
- 8. Learn
Turn outcomes into better tests, context, instructions, templates, policies, and signals.
1. Signal
A signal is evidence that something may deserve work: a user complaint, an incident, a repeated manual step, a failing service-level objective, a security requirement, or a measured product opportunity. A model-generated idea is also only a signal. It is not approved intent. Good intake preserves the source, urgency, affected users, and uncertainty. It rejects work that has no owner or no plausible result.2. Intent
Intent turns the signal into a bounded outcome. It names the user problem, desired result, scope, constraints, owner, and acceptance criteria. A product requirements document can carry product intent for a substantial change. A smaller task may need only a few explicit criteria. Acceptance criteria should describe observable behavior. “Improve imports” is not enough. “An admin can preview a 100,000-row import without changing billing data” can be planned and proved.3. Context
Context is selected evidence, not a repository dump. Include the current code paths, interfaces, data rules, accepted decisions, representative examples, known conflicts, and freshness notes that affect the task. Rich references are useful when an agent needs exact prototypes, tests, code examples, or rubrics. The context packet should say which source wins when a stale plan conflicts with current code or an accepted decision.4. Plan
The plan converts intent and context into ordered changes, dependencies, risks, verification steps, and stop conditions. Larger work benefits from an explicit, reviewable plan because errors are cheaper to find before execution. Use an AI coding plan for the next implementation pass. Use a technical specification for durable behavior and design, an ADR for one consequential architecture choice, or an RFC when a proposal needs broader discussion. These documents have different jobs.5. Execute
Execution may involve one agent, several specialized agents, people, or a mix. The factory defines what each actor can change, which tools it can use, how work is isolated, what checkpoints exist, and when it must stop. Long-horizon tasks need durable state, explicit handoffs, bounded retries, and recovery after interruption. More runtime is not a substitute for clearer intent or fresher context.6. Prove
Proof links the result to the acceptance criteria. It can include tests, screenshots, accessibility checks, benchmark receipts, migration rehearsals, deploy evidence, and unresolved failures. A generated summary is an index to evidence, not the evidence itself. Deterministic checks should fail deterministically. Judgment belongs in an anchored rubric with reasons and source links. A coding-agent field guide can preserve reviewed, project-specific lessons, but enforceable rules should graduate into tests, types, schemas, linters, or policy.7. Judge and ship
This stage combines hard policy with a decision appropriate to the risk. The result may be release, staged rollout, revision, rejection, or hold. The decision record should name the evidence reviewed, the unresolved risks, the decision maker, and the scope of the decision. Shipping is not always deployment. It can mean merging a library change, enabling a feature for a cohort, publishing a package, completing a migration, or deliberately deciding not to proceed.8. Learn
The learning loop starts with observed outcomes. A failure might create a regression test, a corrected source, a narrower permission, a new stop condition, a better example, or a revised intake rule. A successful pattern might become a reusable skill or paved path. Saving a transcript or adding more text to a knowledge base is not automatically learning. The lesson must change a future input, control, or decision, and it needs an owner who can remove it when it becomes stale.What documents and controls does a software factory need?
The smallest useful control surface is often six Markdown files:
Copy the complete software factory control packet template and worked example. It is intentionally plain Markdown. A team can version it beside the work without adopting another platform.
The six files are not mandatory categories for every task. A one-line fix with a precise regression test may need only an issue, diff, and test receipt. Use the packet when work spans multiple actors, sessions, systems, or review decisions and the cost of losing the reasoning is greater than the cost of maintaining six small files.
Where should humans review?
Human review is useful where risk or ambiguity exceeds what a deterministic gate can settle. It does not follow that every change needs a person at every stage.
- Does the build, type check, test suite, contract check, or migration rehearsal pass?
- Does the change stay within an allowed path, permission, budget, or dependency policy?
- Does the artifact contain the required fields and evidence links?
- Did the release remain within error-rate, latency, or data-integrity thresholds?
- Is this the right user problem and is the proposed scope acceptable?
- Does a security, privacy, financial, legal, or irreversible data risk remain?
- Is the evidence representative enough to support the shipping decision?
- Should the team accept a known limitation, change policy, or stop the work?
Worked example: a resumable billing import
The following company, product, people, metrics, results, and identifiers are fictional. They illustrate traceability and do not report a Plannotator customer or product capability. Quay Billing is a fictional subscription-billing product. Its fictional operations team wants a resumable bulk price-adjustment import for billing administrators. The change touches a browser interface, an API, durable job state, tenant authorization, audit events, performance, and staged rollout.Intent and acceptance criteria
Plan, rubric, and stop conditions
The fictional plan creates an immutable upload record, a resumable validation job, a preview API, an idempotent apply ledger, an admin interface, audit events, and staged-release controls. Each implementation step names the acceptance criteria and verification it supports. The rubric treats data integrity, tenant isolation, and recovery as blocking. Accessibility and operability have named checks. The plan stops if a retry duplicates an adjustment, cross-tenant access succeeds, cancellation can leave a partial commit, or the fixed benchmark exceeds its limit twice.Evidence and decision
The fictional decision log records: proceed to 25%, keep the kill switch armed, and hold 100% rollout until E-6 contains a passing failover receipt. The packet does not turn an unresolved criterion into a green summary. It carries the open result into the shipping decision.
The full copyable example includes all six files.
How should a factory learn from failures?
Start by classifying where the failure entered the loop:
Do not reward the system for producing more artifacts. Measure whether the correction reduces repeated failures, false blocks, time to useful evidence, or recovery cost. Keep a counterexample and a removal condition for learned rules so one incident does not become permanent bureaucracy.
How current vendor models differ
Several vendors now use “software factory” for agent-native delivery, but their published emphases differ:- Factory.ai describes standardized intake, context, planning, execution, review, delivery, and observability. Its architecture article keeps people focused on intent, review, and policy, and recommends explicit reviewable plans for larger work. (Architecture, category guide)
- 8090 centers continuous context flow through a knowledge base, a unified assembly line, a factory floor plan with ownership, reusable roles and skills, and lifecycle feedback. Its article also says some parts remain experimental. (8090)
- StrongDM describes people defining intent, scenarios, and constraints while agents generate and validate software. It argues that scenario validation can replace code review within its own model. That is StrongDM’s position, not a general result established by this guide. (StrongDM)
Limits of the category and the search evidence
“AI software factory” can overstate the maturity of a workflow. Repeatable inputs do not guarantee good intent. More agent autonomy does not guarantee lower cost or higher quality. Evaluation can miss real behavior, feedback can reinforce the wrong objective, and a documented control can still be ignored. The search evidence behind this page is also limited. Query-volume and competition estimates are provider-modeled, change over time, and do not establish real adoption or reader intent. Much of the current agent-native literature comes from vendors describing their own systems. This guide therefore uses vendor sources only for what those vendors say, separates historical examples from the proposed model, and makes no universal productivity claim. Evaluate a factory with local evidence: lead time to a proved result, escaped defects, repeated corrections, rollback and recovery performance, human attention required, false blocks, cost, and user outcomes. Record the baseline and the conditions of the measurement.Where Plannotator fits
Plannotator can be the shared planning and human-judgment surface inside a larger software factory. On the product surfaces that support them, people and agents can inspect plans, PRDs, specifications, ADRs, Markdown, HTML, folders, annotations, comments, and versions. Plannotator is not an end-to-end software factory. It does not provide autonomous execution, model routing, CI/CD, deployment, monitoring, scenario validation, or a complete control plane. Those responsibilities remain with the agents, development tools, delivery systems, and operating controls a team chooses.Review plans and technical decisions in Plannotator
See the current shared-review workflow, or start with the open-source document review workflow.