Enterprise software teams are connecting AI agents to systems of record: CRMs, payment processors, ERPs, clinical systems. The connections work. The engineering doesn't. Failures return errors the reasoning layer can't interpret. Recovery logic gets invented on the fly, and billed by the token. State changes land with no reliable way to reconstruct what happened. Agents reach operations no one scoped them to.
The Seven Factors is an engineering methodology for building the control plane that sits between AI agents and enterprise systems: the deterministic layer that must be correct regardless of which model, framework, or agent architecture reasons above it. The reasoning layer owns intent. The control plane owns consequences. It is modeled on Adam Wiggins' Twelve-Factor App and synthesizes what the contributors have observed across over one trillion workflow executions at enterprise scale.
The problems these factors address are partly new and partly inherited. Agentic architectures introduce failure modes with no precedent, alongside familiar ones exposed at new scale. The solutions draw on decades of enterprise integration, distributed systems, and security engineering, applied to the novel boundary between probabilistic reasoning and deterministic systems.
The control plane between AI agents and enterprise systems is emerging infrastructure. The Seven Factors is a shared engineering methodology for getting it right, so no team has to reinvent it alone.
| # | Factor | Principle |
|---|---|---|
| I | Governed Operations | No enterprise concern delegates to an agentic protocol |
| II | Deterministic Mutations | All state mutations belong to the control plane |
| III | Intent-Based Communication | Tool boundaries follow intent, not implementation |
| IV | Bounded Access | Each caller sees only the capabilities its role requires |
| V | Safe Retries | Every mutation is safely retried by a probabilistic caller |
| VI | Recovery Contracts | The reasoning layer never guesses at state |
| VII | Structural Observability | Every agent action is reconstructable by architecture, not investigation |
Each factor has two layers.
The principle — a short, assertion-dense statement of the factor's core claim. Read these in sequence. Together they describe a complete architecture. Each is designed to be quoted, posted, and argued about.
The extended guidance — how to act on the principle. Diagnostic questions, named anti-patterns, worked examples, tradeoffs. Read these when you are assessing a system, designing a capability, or reviewing a pull request.
factors/
├── i-governed-operations/
│ ├── principle.md # The principle (~500 words)
│ └── guidance.md # How to act on it (~5,000 words)
├── ii-deterministic-mutations/
│ ├── principle.md
│ └── guidance.md
...
Start with the introduction if you are new to the framework. Start with Factor I if you want to understand the foundational architecture. Start with the factor closest to the problem you are debugging if you are in the middle of an incident.
The Seven Factors is a living framework. The principles are grounded in production evidence; the territory they map — the agentic control plane — is emerging infrastructure that grows more complex as the industry advances. The framework gets stronger as practitioners apply it across new domains, architectures, and failure modes.
There are several ways to contribute:
- Share what you've observed. Open an issue if you've encountered a failure mode the framework should name, applied a factor in a novel domain, or have production evidence that extends or challenges a claim.
- Join the conversation. Start or join a discussion for broader questions — how a factor applies in your architecture, where the framework's vocabulary maps to your experience, what the factors should address next.
- Propose editorial changes. See CONTRIBUTING.md and contributing/archetype.md for editorial standards and the guidance document structure.