Fusion: A Process Model for AI-Driven Software Development

This is the second in a two-part series. The first article Beyond Agile: Project Management in AI-Driven Development examined why agile's assumptions break down in AI-driven development. This follow-up drafts a concrete methodology — built around goals, decisions, and sessions — and identifies the tooling requirements to put it into practice.

A Process Model for AI-Driven Software Development

This document defines a process model for software projects where AI agents handle implementation and humans handle direction, decisions, and review. It builds on the observation that when implementation is cheap, the bottleneck shifts to decisions — and the methodology must shift with it.

1. Core Concepts

A software project revolves around three poles and a process that connects them:

          Goal
        (Where to?)
          ╱╲
         ╱  ╲
        ╱    ╲
       ╱      ╲
Decisions ──── Artifact
(On what       (What
 basis?)       emerges?)

Goal — describes the state of the Artifact upon completion
Decisions — the basis on which the Goal is formulated and the Artifact is developed
Artifact — what materializes during Cobot, oriented by the Goal, grounded in Decisions

Coherence is the consistency between these three poles. Cobot is the process that moves between them. Rebalance adjusts one of the three when Coherence is not achieved.

Software development moves in circles. You start with assumptions (Decisions), orient toward an outcome (Goal), build something (Artifact) — and afterward understand both the problem and your own assumptions differently. The next round starts from this improved understanding, not from scratch. Each pass narrows the gap between what you intended and what the thing actually needs to be. This circular convergence is the reason the model's central unit is called a Cycle — not because it repeats, but because each revolution brings the three poles closer together. A single revolution is a Turn; the whole convergent movement is the Cycle.

1.1 Goal

Describes the state of the Artifact upon completion.

A Goal orients the Cycle toward an outcome and defines the conditions under which the Cycle closes. Goals can be revised during the Cycle.

Goals have no inherent size. What makes something a Goal is not its scope but whether it requires Decisions to be made. A Goal opens a Cycle because there are things to discover, understand, or decide before the outcome can be reached.

"Build a replacement for Microsoft Entra" is a Goal. It will quickly spawn Sub-Cycles as the outermost Cycle breaks down into authentication, authorization, directory services — each requiring its own Decisions.
"Build a website that displays the weather forecast" is also a Goal. It is smaller, but still raises questions: which API? what design? how does the user choose a location? Each question is a Decision that must be made before the Artifact can take shape.
"Add a 404 handler" is not a Goal — it is a Task. The Decisions exist (framework, conventions, error handling pattern). The path is clear. No Cycle needed.

The difference is not size but decidability: does the work require Decisions that don't yet exist? If yes, it is a Goal and opens a Cycle. If no, it is a Task and executes within one. Large Goals recurse into Sub-Cycles naturally; small Goals may close in a single Turn. Both follow the same process.

Completion: A Goal is fulfilled when Coherence between Goal and Artifact is established.

1.2 Decisions

The basis on which the Goal is formulated and the Artifact is developed.

Decisions encompass everything that grounds the project: architectural choices, technology selections, conventions, constraints. Decisions accumulate across Sessions and Cycles.

Decisions are necessarily provisional. You cannot start a Cycle without Decisions — but the Decisions you start with are the best you know now, not the truth. Every Turn can revise Decisions. This is not a defect; it is the nature of building in open problem spaces. A decision like "REST, not GraphQL" reflects your current best judgment. Three Turns later, you may discover that your mobile client's needs make GraphQL the better choice. Revising that Decision is progress, not failure.

Why Decisions, not tasks: In AI-driven development, implementation is not the hard part. The hard part is knowing what to implement. Every feature involves dozens of decisions — API contracts, authentication methods, error handling strategies, edge case behavior. Each Decision unblocks the AI to implement. Without them, the AI either guesses (risky) or asks (slow). The pace of a project is set by how quickly Decisions are made, not how quickly code is written.

Two layers: Decisions exist as both history and active state:

Layer	Content	Purpose
Decision State	Current best-of-knowledge only	What the AI and human work against. Clean, non-contradictory, reconciled.
Decision History	Append-only log of all Decisions, including superseded ones	Traceability, rationale, learning from past revisions.

When a Decision is revised, the old Decision moves to History and the new one takes its place in State. The Decision State must never contain contradictory residuals from earlier provisional Decisions — it represents the project's current understanding, not its full journey. The History preserves the journey.

Reconciliation happens naturally at two points: during Rebalance (when a Turn reveals that a Decision needs revision) and at Session end (when Memory is updated). Both are moments where the human ensures that the Decision State reflects only what is currently held to be true.

1.3 Coherence

The consistency between Goal, Decisions, and Artifact.

Coherence has two aspects:

Aspect	Meaning
Coherence (status)	The achieved state of consistency
Coherence Review	The examination of whether that state is achieved

The Coherence Review exercises all three edges of the triangle:

Edge	Question
Artifact ↔︎ Decisions	Does the Artifact respect the architectural Decisions?
Artifact ↔︎ Goal	Does the Artifact move toward the Goal?
Decisions ↔︎ Goal	Are the current Decisions still appropriate for the Goal?

The most common failure mode in AI-driven development is the first edge: AI bypasses architecture. A team carefully builds a repository layer; the AI writes a direct SQL query in a controller. The project has centralized error handling; the AI adds a try-catch inline. Each instance looks harmless — but cumulatively, these shortcuts erode the architecture. Coherence Review catches this. The other two edges are equally important: an Artifact can respect all Decisions yet drift from the Goal, and Decisions made early can become inappropriate as the Goal sharpens through Turns.

Function: Coherence is the completion criterion of a Cycle. Without Coherence Review, no reliable completion.

Operationalization: Coherence is primarily a qualitative judgment by the human-in-the-loop. The human bears responsibility for assessing whether Artifact, Goal, and Decisions are consistent. AI can assist:

Role	Contribution to Coherence Review
Human	Judgment on overall coherence, validation against implicit knowledge, final decision
AI	Systematic checks against explicit Decisions, surfacing contradictions, checklist-based reviews

Formal approaches that complement the human judgment:

Checklist Review: AI systematically checks the Artifact against documented Decisions (e.g., "Are all architectural decisions respected?")
Divergence Analysis: AI compares Artifact state with Goal and flags deviations
Adversarial Review: AI deliberately argues against the Coherence thesis to expose weaknesses

1.4 Memory

The persisted knowledge structure that enables continuity across Sessions and Cycles.

Memory is the project's persistent context. It contains:

Active Goals — What is currently being pursued
Decision State — Current Decisions of the project
Project context — Architecture, conventions, constraints
History — Journal, completed Cycles, Decision changes

Memory is readable by both human and AI. It is loaded at Session start and updated at Session end.

Aspect	Function
For AI	Context that compensates for lacking long-term memory
For Human	Documentation, onboarding, traceability
For Process	Enables Rebalance across Sessions

Memory Management: The AI's context window is limited. Memory must therefore be actively managed: what gets loaded, what gets summarized, what gets archived. A growing project accumulates more Decisions, history, and context than fits into a single context window. Memory Management determines which slice of the project's knowledge is available in a Session — and thereby directly affects the quality of Cobot.

Loading priority: When the context window cannot hold everything, load in this order:

Decision State — without current Decisions, the AI cannot work coherently
Active Goals — without Goals, the AI has no direction
Project context — architecture, conventions, constraints relevant to the active Goals
Recent history — last Session's journal, recent Decision changes
Older history — summarized, not verbatim

Implementation: Memory takes the form of context files, journals, and architectural decision records (ADRs).

1.5 Artifact

What materializes during Cobot, oriented by the Goal, grounded in Decisions.

An Artifact is what emerges at the end of a Cycle (or as an increment within a Session). Artifacts are versioned, documented, and checked in the Coherence Review against Goal and Decisions.

Typical software Artifacts: functioning code, tests, API specifications, documentation.

2. Process Structure

Cycle                          The whole: Goal → Closure
│
├── Turn                       One round: Cobot → Coherence Review → Rebalance
│   ├── Task                   Operative unit (Decisions suffice)
│   ├── Task
│   └── Task → Sub-Cycle       Escalation (Decisions don't suffice)
│
├── Turn
│   └── ...
│
└── Closure

Level	Unit	Governed by	Completion criterion
Cycle	Convergent whole	Goal	Coherence across all three edges
Turn	One revolution	Coherence Review	Coherence achieved or Rebalance triggered
Task	Operative work	Existing Decisions	Output produced

Session is orthogonal: it is the temporal frame in which Turns happen, bounded by context window, time, and attention.

2.1 Cycle

The entirety of the movement from Goal to Closure.

A Cycle is not a single iteration. It is the whole journey from a set Goal to achieved Closure. It contains Turns: repeated passes through Cobot → Coherence Review → Rebalance → back into Cobot. Each Turn changes the understanding of the Goal, the Decisions, or the Artifact. The Turn is the round; the Cycle is the whole.

┌──────────────────────────────────────────────────────────────────┐
│                            CYCLE                                 │
│                                                                  │
│   Goal ───────────────────────────────────────────► Closure      │
│                                                                  │
│        │         ┌─── TURN ──────────────────┐        ▲         │
│        ▼         │                           │        │         │
│   ┌──────────┐   │  ┌────────┐  ┌──────────┐ │        │         │
│   │Decisions │───┼─►│ Cobot  │─►│Coherence │─┼────────┘         │
│   │          │   │  │        │  │ Review   │ │       (coherent) │
│   └──────────┘   │  └────────┘  └────┬─────┘ │                  │
│        ▲         │                   │       │                  │
│        │         │    (Rebalance)    │       │ (not coherent)   │
│        │         └───────────────────┼───────┘                  │
│        └─────────────────────────────┘                          │
└──────────────────────────────────────────────────────────────────┘

Phases of a Cycle:

Set Goal — What should be built or achieved?
Explicate Decisions — What Decisions are in effect?
Cobot — Intensive exchange between human and AI (see 2.3)
Coherence Review — Does the Artifact match Goal and Decisions?
Rebalance — If not coherent: restore balance (see below)
Closure — Coherence achieved; Artifact complete

Rebalance:

Restoring the balance between Goal, Decisions, and Artifact.

The Coherence Review can uncover three kinds of discrepancy:

Discrepancy	Rebalance Action
Artifact does not respect Decisions	Back into Cobot with clearer Decisions
Decisions were incomplete or wrong	Extend/correct Decisions, then Cobot
Goal was unrealistic or unclear	Adjust Goal, potentially start a new Cycle

Rebalance is not failure. It is the normal mode of the Cycle. Each Turn sharpens the understanding of what should and can actually be built.

Bounded Closure:

Not every Cycle ends with full Goal fulfillment. A Cycle can end in Bounded Closure: the work has shown that the Goal is not (fully) achievable under the given conditions. The Bounded Closure documents what was built, what was learned, and what constraints prevented full completion.

Bounded Closure is a valid outcome of the Cycle itself — the knowledge of structural limits is an Artifact. But from the perspective of the Parent Cycle, it is a failure: the Child did not deliver what the Parent needed to proceed. The Parent must now Rebalance — find an alternative path, revise its own Decisions, or adjust its Goal. This requires human action.

Context	Bounded Closure means
Child Cycle	Goal not achievable; limits documented; Cycle ends cleanly
Parent Cycle	Expected input missing; Rebalance required; human decides how to proceed
Outermost Cycle	Project Goal not achievable; project ends

Example: A Goal to support offline-first sync may reveal that the chosen database engine cannot handle the required conflict resolution. The Child Cycle reaches Bounded Closure. The Parent must now Rebalance: choose a different database engine (revise Decisions), reduce the sync guarantees (adjust Goal), or accept the limitation (Bounded Closure propagates upward).

Recursion:

Cycles can spawn Sub-Cycles during Cobot. This happens not through upfront planning, but through discovery — a Turn reveals that a subproblem needs its own Goal, its own Decisions, and its own Artifact.

Parent Cycle
│
├── Turn 1: Cobot → discovers gap
│           ↓
│     ┌─ Child Cycle (own Goal, inherits Parent Decisions)
│     │   ├── Turn 1 ...
│     │   └── Closure → Child Artifact
│     └─ Child Artifact flows back as Decisions or
│        as part of the Parent Artifact
│
├── Turn 2: Cobot with new Decisions
│
└── Closure

The relationship between Parent and Child:

Child Goal derives from a gap that a Turn in the Parent uncovers
Child Decisions inherit from the Parent (plus own specifics)
Child Artifact flows back to the Parent upon Closure — as new Decisions or as part of the Parent Artifact
Child Closure (or Bounded Closure) enables the Parent to continue

Recursion depth is not predictable. You don't know at the start of a Cycle how many Sub-Cycles it will spawn. This is not a planning failure — it is the nature of building software in open problem spaces.

Anticipated Cycles:

The recursion above describes emergent Sub-Cycles: a Turn discovers a gap, and a Child Cycle is born from that discovery. But not all Cycles emerge this way. Projects have direction — and from that direction, future Cycles can be foreseen before Cobot produces them.

An anticipated Cycle has a provisional Goal but no Decisions yet. It is a statement of intent: "This will likely become its own Cycle." The provisional Goal is refined upon activation; Decisions are made only then.

Project Cycle (outermost)
│
├── Cycle 1 (completed)
│
├── Cycle 2 (active — own Goal, own Decisions)
│   ├── Turn 1 ...
│   └── Sub-Cycle (emergent, discovered in Turn 1)
│
├── Cycle 3 (anticipated — provisional Goal, no Decisions)
├── Cycle 4 (anticipated — provisional Goal, no Decisions)
└── ...

Property	Emergent Sub-Cycle	Anticipated Cycle
Origin	Discovered during Cobot in a Turn	Derived from an overarching vision
Goal	Specific, born from a concrete gap	Provisional, refined upon activation
Decisions	Inherits from Parent + own specifics	Not yet present; created upon activation
Ordering	Not plannable	Ordered by current assessment, revisable

The ordering of anticipated Cycles is itself a form of Decisions — it represents the current assessment of the project's path. After each completed Cycle, this ordering can be revised: new findings can shift priorities, render Cycles unnecessary, or introduce new anticipated Cycles. This is Rebalance at the project level.

Relationship to emergence: Anticipated Cycles do not replace emergent Sub-Cycles. Both coexist. An active Cycle can spawn emergent Sub-Cycles at any time, regardless of which Cycles are anticipated. Anticipation is orientation, not commitment — it guides without binding.

Comparison with PDCA and OODA:

The Cycle has structural similarity to Plan-Do-Check-Act (Deming) and Observe-Orient-Decide-Act (Boyd). The difference is in what can change:

Aspect	PDCA	Cycle
Unit	Process improvement	Knowledge gain and construction
Objective	Quality control	Coherence between Goal, Decisions, Artifact
Iteration	Error correction	Rebalance (Decisions, Goal, or Artifact can change)
Completion	Standard reached	Coherence achieved or Bounded Closure
Participants	Process actors	Human and AI as active participants

PDCA optimizes a known process. The Cycle navigates an open space where the problem statement itself can change (Goal revision). This makes it structurally closer to exploratory engineering than to quality management.

Duration: A Cycle can last minutes (small Goal) or days/weeks (complex Goal).

2.2 Session

A temporal frame, not a structural element of the Cycle.

A Session is a bounded work block in which progress on the Cycle is made. Sessions are limited by context window, time, and attention. They can start and end at any point in the flow — mid-Turn, mid-Task, even mid-prompt if a failure or timeout occurs.

Cycle flow (continuous):

  ┌─ Turn 1 ───────┐ ┌─ Turn 2 ────────────────────┐ ┌─ Turn 3 ──────────┐
  │ Cobot → Review │ │ Rebalance → Cobot → Review  │ │ Cobot → Review    │
  └────────────────┘ └─────────────────────────────┘ └───────────────────┘
       ┆                       ┆                              ┆
  ─────╂───────────────────────╂──────────────────────────────╂────────►
       ┆    Session 1          ┆       Session 2              ┆  S 3
       ┆                       ┆                              ┆

Session boundaries cut anywhere. They do not align with Turns.

Session boundaries are arbitrary cuts across the Cycle's conceptual structure. A Session does not "contain" Turns — it overlaps with them. A Turn can span multiple Sessions (context window fills mid-Turn), and a Session can span multiple Turns.

What a Session must do:

Phase	Activity
Start	Load Memory: active Goals, Decision state, project context
Work	Continue wherever the Cycle left off
End	Update Memory: journal entry, Decision changes, commit Artifacts

The critical contract: every Session end must leave Memory in a state from which the next Session can resume. This is what makes arbitrary breaks survivable.

Three functions:

Continuity — Maintain context across breaks via Memory
Increment — Achieve measurable progress within the Cycle
Checkpoint — Documented state for return

The natural rhythm of AI-driven work is the Session — a block of time where a human directs AI toward a goal. Sessions might last 30 minutes or 8 hours. They don't align with sprint boundaries, and they don't align with Turn boundaries either.

2.3 Cobot

The collaborative process between human and AI in which the Artifact takes shape.

Cobot is the intensive exchange in which human and AI work together on the Artifact. It is not instruction-execution. The AI is an active participant that brings its own patterns, raises concerns, and makes implementation choices.

Characteristics:

Collaborative construction — Not order fulfillment, but joint problem-solving
Counterpart dynamic — AI acts as an independent participant with its own "positions"
Intensive exchange — Numerous prompt-response pairs
Multi-agent capable — AI agents already spawn sub-agents internally (e.g., Claude Code's task delegation). The process implications of multi-agent Cobot (coordination, shared Decisions, Coherence across agents) are not yet modeled.

Internal structure of Cobot:

Prompts and Responses — The visible back-and-forth
AI-internal loops — Agent chains, tool usage, reasoning
Emergent findings — Arise through the exchange, not through individual effort

Events in Cobot:

During Cobot, situations arise that require a transition in the Cycle. These events are not yet fully formalized — the following taxonomy is a working draft:

Event	Trigger	Response
Decision Gap	AI or human identifies a missing Decision needed for progress	Cobot pauses; human clarifies the Decision
Decision Conflict	New finding contradicts an existing Decision	Rebalance: review and potentially revise the Decision
Scope Drift	Work visibly moves away from the Goal	Human decides: adjust Goal or redirect work
Confidence Erosion	AI signals uncertainty about the current approach	Pull Coherence Review forward before investing more in a questionable direction
Artifact Ready	An Artifact state is ready for review	Transition to Coherence Review

Open questions on Events:

How does the AI signal events? (Structured outputs, metadata, natural-language markers?)
Which events can the AI detect, which only the human?
Can tooling detect events and automatically trigger governance? (→ Steering Problem, Section 4)

Cobot ends (provisionally) when an Artifact state is ready for Coherence Review.

2.4 Task

The operative unit within a Turn.

A Task is a concrete work unit that arises during Cobot and is executable within the existing Decisions. Tasks implement what the current Decisions enable — they do not create new foundations, they work on existing ones.

Cycle
  └── Turn
        ├── Task 1  (Decisions suffice → execute)
        ├── Task 2  (Decisions suffice → execute)
        └── Task 3  (Decisions don't suffice → escalates to Sub-Cycle)

Task vs. Cycle:

	Task	Cycle
Decisions	Existing Decisions suffice	Own Decisions must be developed
Goal	None of its own; serves the Cycle's Goal	Own Goal
Artifact	Contributes to the Cycle's Artifact	Own Artifact that flows back to the Parent
Coherence	No own Coherence Review	Own Coherence Review
Duration	Typically completable within a Turn	Can span Turns and Sessions

Threshold criterion: The question that separates a Task from a Cycle is: Do the existing Decisions suffice to predict the outcome and determine the path? If yes → Task. If no — because something must be discovered, understood, or decided first — the Task escalates to a Sub-Cycle with its own Goal.

Decisions are primary, Tasks are derivative. Tasks flow from Decisions, not the other way around. Progress is measured by Decision growth and Coherence, not by completed Tasks.

3. The AI's Role

AI acts autonomously within boundaries set to keep the human in the loop.

Current AI coding agents (e.g., Claude Code) operate with genuine autonomy within a Session: they analyze code, choose tools, build and use utilities, make implementation choices, and structure their work independently. An AI agent acts — and in doing so creates facts that change the project state. This is not tool usage; it is delegated work.

Where AI is autonomous:

Domain	AI acts independently
Implementation	Chooses code structure, algorithms, patterns, libraries
Tool use	Selects, combines, and builds tools as needed
Task execution	Plans and executes steps within a Task without prompting
Problem analysis	Reads code, identifies issues, proposes solutions

Within these domains, AI is a genuine participant — it contributes judgment, not just labor.

Where the human stays in control:

The boundaries are deliberate. They exist because the Cycle's integrity depends on human oversight at specific points:

Boundary	Rationale
Goal changes	Only the human can redirect the Cycle's purpose
Decision revisions	Changing the basis on which the Artifact is built requires human judgment
Coherence assessment	The human bears responsibility for the final quality judgment
Memory authority	AI does not write to Memory autonomously — it proposes; the human decides what gets persisted

Advisory role between the boundaries:

AI can actively influence the Cycle's trajectory without crossing the boundaries:

Raise Decision questions: AI recognizes missing Decisions and escalates to the human
Voice Coherence concerns: AI signals when it detects inconsistencies between Artifact and Decisions
Propose Rebalance: AI can argue that a Goal is unrealistic or a Decision is incomplete

Consequences for the process:

Aspect	Implication
Documentation	AI contributions must be documented (who decided what?)
Review	AI output requires Coherence Review (not just "does it work?")
Delegation	Explicitly define which Decisions the AI may make independently
Sharing Decisions	The project's Decisions must be readable by AI in Memory

The question of how these AI impulses can be technically embedded as events that trigger governance processes is the Steering Problem (Section 4).

4. The Steering Problem

How does the human govern a process without structural intervention points?

The Cycle model (Section 2) assumes that events like Decision Gaps, Confidence Erosion, and Scope Drift (Section 2.3) can be detected and acted upon. The boundaries defined in Section 3 assume that the human can intervene when Goals, Decisions, or Coherence are at stake. Both assumptions require something that current tooling does not provide: reliable, rule-based intervention points.

The gap in current tooling:

Tools like Claude Code offer two mechanisms for human-AI interaction:

Mechanism	What it does	What it cannot do
Textual responses	AI communicates in natural language within the conversation	No structured event signaling; critical moments are buried in prose
Mechanical hooks	Shell commands triggered by tool calls (pre/post)	No semantic awareness; cannot detect Decision Gaps or Coherence concerns

Neither mechanism can enforce the boundaries this model requires. There is no way to define a rule like "pause and escalate when the AI is about to make a Decision that contradicts existing Decisions" — because current tooling has no concept of what a Decision is.

What is needed: an orchestration layer

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   AI Agent      │────►│  Orchestration  │────►│   Human         │
│                 │     │  Layer          │     │   Interface     │
│ Emits structured│     │                 │     │                 │
│ events with     │     │ Matches events  │     │ Displays        │
│ typed metadata  │     │ against rules,  │     │ decision points,│
│                 │     │ enforces        │     │ approves or     │
│                 │     │ boundaries      │     │ redirects       │
└─────────────────┘     └─────────────────┘     └─────────────────┘

This requires two things that do not yet exist:

1. A clear event specification. The events from Section 2.3 (Decision Gap, Decision Conflict, Scope Drift, Confidence Erosion, Artifact Ready) must be formalized as typed, machine-readable signals — not natural-language hints. Each event needs:

A type identifier
Structured payload (which Decision, which Goal, what deviation)
Severity / urgency classification

2. Extensions to agent tooling. The AI agent must be able to emit these events as part of its output, and the orchestration layer must be able to intercept them before the conversation continues. This is fundamentally different from current hooks (which trigger on tool calls) or textual responses (which the human must parse manually).

Events that trigger governance:

Event	Governance action
Decision Gap detected	Pause Cobot; escalate to human for Decision
Decision Conflict detected	Pause Cobot; human reconciles Decision State
Confidence below threshold	Pull Coherence Review forward
Scope Drift detected	Human decides: adjust Goal or redirect
Goal revision proposed	Revalidation of existing Artifacts
Decision change proposed	Impact analysis on dependent Artifacts

Status: This problem is the critical gap between the Fusion model and its practical application. The model describes what should happen; the tooling does not yet support making it happen. Solving this requires collaboration between methodology (event specification) and tooling (agent extensions, orchestration layer).

5. Concept Overview

Concept	Definition
Goal	What orients the Cycle — the desired end state of the Artifact
Decisions	What the work builds on — architectural choices, constraints, conventions
Memory	The project's persisted knowledge structure
Cobot	The collaborative process between human and AI
Coherence	Consistency between Artifact, Goal, and Decisions
Rebalance	Restoring balance when Coherence is not achieved
Artifact	The materialized result — code, tests, documentation
Cycle	The entirety from Goal to Closure
Turn	One round within the Cycle (Cobot → Review → Rebalance)
Task	Operative unit within a Turn (existing Decisions suffice)
Session	The technical-temporal work frame

6. Relationship to Beyond Agile

This process model implements the principles outlined in Beyond Agile: Project Management for AI-Driven Development (https://bit.ly/beyond-agile):

Beyond Agile Principle	Fusion Concept
"Goals, not stories"	Goal — the organizing structure of a Cycle
"Decisions, not tasks"	Decisions — primary over Tasks
"Sessions, not sprints"	Session as the natural work rhythm
"Review gets harder, not easier"	Coherence Review — checking all three edges of the triangle, not just correctness
"AI handles implementation"	The AI's Role — autonomous within boundaries, human in the loop
"CLAUDE.md-style context files"	Memory — the persistent interface between human intent and AI execution
"The tooling gap"	Steering Problem — event-based governance of natural-language interaction

7. Open Questions

Two-level architecture: Projects regularly operate on two levels simultaneously — building the system (operative) and evolving the architecture/process (meta). Is "meta" a separate mode or a natural part of every Cycle? The answer affects tooling: a mode implies context switching and explicit transitions; an integrated view implies that every Cycle naturally includes meta-reflection.
Event formalization: The event taxonomy (Section 2.3) and the Steering Problem (Section 4) identify the events that matter and the tooling gap that prevents acting on them. The open work is formalization: defining typed event specifications, structured payloads, and the orchestration layer that connects them. This is the critical path to making the model operational.
Parallel Cycles: The recursion model (Section 2.1) describes Parent-Child relationships. Can Cycles also run in parallel without a Parent-Child relationship? How does one Cycle's Decisions affect another's?
Task coordination: Tasks are defined as operative units within a Turn (Section 2.4). Open: how Tasks are coordinated within a Turn — sequencing, dependencies, parallelization. Is this a tooling implementation detail, or does it need conceptual guidance here?
Multi-agent Cobot: AI agents already spawn sub-agents internally (Section 2.3). The process implications are not yet modeled: how are Decisions shared across agents? How does Coherence Review work when multiple agents contributed to the Artifact? Who coordinates?
Session recovery: Sessions can break at any point (Section 2.2), including mid-Turn or mid-Task. The model requires that Memory enables resumption, but the mechanics of recovery — what gets rewound, what gets replayed, what gets discarded — are not yet specified.

This document is work in progress and will be refined iteratively.