The MADD Workflow
Every MADD cycle follows a three-phase pipeline. Artifacts flow between agents — each agent reads from the previous phase's output and writes for the next.
Phase 1 — Formalization Conductor + Architect
The Conductor receives the need and orchestrates the cycle. The Architect formalizes the intention, annotates tasks with domains, and produces the Executable Contract with validation criteria.
Phase 2 — Execution Maker + CI + Breaker (per fraction)
Work is decomposed into fractions. For each fraction, a domain-specialized Maker implements, CI validates the build, and a domain-specialized Breaker audits. If the Breaker rejects, the Maker iterates.
Phase 3 — Memory Witness
The Witness analyzes the produced code independently — without reading what the Maker claims to have done. The resulting retro-specification documents reality and becomes the starting point for the next cycle.
Each phase's output is the next phase's input. No agent validates its own work. The cycle is anchored in reality, not in promises.
The Intention Document
The entry artifact. Every MADD cycle begins with a formalized intention — not a chat message, not a vague request.
The Intention Document captures why and what — never how. It is produced by the Architect Agent and serves as the foundation for the Executable Contract.
Structure
Best practices
- One Intention Document = one coherent unit of work
- Every requirement must map to at least one validation criterion
- The "out of scope" is as important as the scope — it prevents agent drift
- Version the Intention Document with the code — it's a first-class artifact, not a disposable prompt
The Executable Contract
The validation artifact. What transforms a wish into a verifiable commitment.
A contract is "executable" when it can be verified automatically. No "looks good to me" — it either passes or fails.
The contract sits at the center of the MADD architecture. The Architect writes it alongside the Intention Document. The Maker implements to satisfy it. The CI runs it. The Breaker verifies compliance beyond automated checks. The Witness compares reality against it.
Contract types
The principle
If you can't write a test to verify a requirement, that requirement is poorly defined.
Fractions
The execution unit. Work is decomposed into small, independently deliverable fractions that each complete their own Maker → CI → Breaker cycle.
Instead of one monolithic "implement everything, audit everything" cycle, the Conductor decomposes tasks into fractions — small groups of 2-6 related tasks. Each fraction goes through its own cycle before the next one starts.
Decomposition rules
- Size — 2-6 tasks per fraction. Small enough for focused context, large enough for coherent delivery.
- Coherence — Tasks in a fraction should be related. A database schema change and its API endpoints belong together.
- Order — Foundations first. Infrastructure and database fractions before API fractions. API before frontend.
- Independence — Each fraction produces working, tested code. The system should be functional after every fraction.
Why fractions?
- Context control — Agents process 2-6 tasks per session instead of 20+, reducing hallucination and drift
- Focused audit — The Breaker reviews 3-4 related changes, not the entire codebase at once
- Crash recovery — If a session fails, resume from the last completed fraction, not from scratch
- Incremental delivery — Working code after each fraction, not a big-bang delivery at the end
The Retro-Specification
The memory artifact. What objectively documents what actually exists in the code.
The retro-spec is not what the Maker says it did. It's what the Witness — an independent agent that didn't participate in development — observes by analyzing the actual code.
Why it's different
Contents
- Current state — What exists in the code right now
- Gaps — Differences between intention and implementation
- Technical debt — TODO, FIXME, workarounds, identified shortcuts
- Dependencies — Libraries, versions, constraints
- Attention points — Risks, known limitations, areas needing future work
The cycle anchor
The retro-spec becomes the starting point for the next cycle. When a new Intention Document is drafted, the Architect consults the retro-spec to understand the real system state — not the marketing documentation, not the developer's optimistic description, but what actually exists. This is how MADD achieves zero drift: each cycle is anchored in the previous one's reality.
Operations
The execution artifact. How the system runs beyond development.
MADD doesn't stop at code delivery. The operations specification captures everything needed to deploy, run, and monitor the system in production.
What operations cover
Why operations matter in MADD
When AI accelerates development, the gap between "works locally" and "runs reliably in production" becomes the new risk. Specifying operations upfront — as part of the contract, not as an afterthought — ensures the Architect thinks about deployment constraints and the Maker builds with production in mind.