Writing · Dr. Kai Stalmann

Implementing Fusion: A Process Layer for AI-Driven Development

10 March 2026EnglishFirst published on LinkedIn

I have been building a tool called Fusion. It sits on top of Claude Code and adds structure to how I work with AI. This article explains what it does, why I think it matters, and what I learned along the way.

Why Organize Memory in the Filesystem?

Claude Code is stateless between sessions. Every time you start fresh, the AI knows nothing about your project except what it can read from files. This is by design, and it works well for simple tasks. But for anything that spans multiple sessions, you need persistent memory.

The obvious place to store that memory is the filesystem. Files are simple. They can be version-controlled. Both humans and AI can read them. They survive restarts, crashes, and context window limits.

Claude Code already supports this through CLAUDE.md files. Fusion extends this idea: instead of a single context file, it maintains a structured directory of project state. The AI reads this state at session start and writes to it as work progresses. The human can inspect, edit, or version-control any of it.

This is not a novel insight. Others have arrived at similar patterns. Nandish Naik describes maintaining action_plan.md and progress.md files per pull request. The principle is the same: make AI memory visible and persistent.

What Fusion Stores

Fusion creates a _fusion/ directory in your project root. Here is what goes inside, focusing on the parts that guide the process:

_fusion/
├── sessions/
│   ├── current.yaml        # Active session: start time, turns, activity
│   └── archive/            # Completed sessions
│
├── process/
│   ├── cycles/
│   │   ├── planned/        # Work items ready to start
│   │   ├── active/         # Currently in progress
│   │   └── completed/      # Done, with summaries
│   │
│   ├── decisions/
│   │   ├── global/         # Project-wide decisions
│   │   └── cycle-scoped/   # Decisions specific to each cycle
│   │
│   └── reviews/            # Coherence reviews per cycle
│
├── files/                  # Archived user inputs
└── _inbox/                 # Drop zone for raw input

Sessions track time and activity. When did you start? How many turns? What cycles did you touch? How many files where edited? This is the audit trail of your work.

Cycles are goal-oriented work units. Each cycle has a directive (what to build), decisions (constraints and choices), and eventually a coherence review (did the result match the goal and respect the decisions?).

Decisions are the constraints the AI works within. They accumulate as the project evolves. Global decisions apply everywhere. Cycle-scoped decisions apply only to that piece of work.

Reviews capture coherence assessments: does the artifact match the goal? Does it respect the decisions? Are the decisions still appropriate?

The data is stored in YAML. Human-readable, diff-friendly, easy to query.

Where This Came From

Fusion emerged from thinking about what changes when AI handles implementation. I wrote about this in two earlier articles:

Beyond Agile examines why agile assumptions break down when implementation is cheap. Story points measure the wrong thing. Sprint cadence becomes arbitrary. The bottleneck shifts from coding to deciding.

Fusion (the methodology) proposes an alternative built around three primitives: Goals, Decisions, and Artifacts. Coherence is the alignment between them. Cycles are the process of achieving that alignment.

The tool implements the methodology. It gives concrete form to concepts that would otherwise remain abstract.

What Fusion Does Not Cover

Fusion focuses on the process within a single project. It does not address how teams should structure repositories across an organization.

For that question, I recommend Martin Jahr's work on AI-driven development for enterprise codebases. He proposes a three-layer federation model: repository boundaries based on enterprise capabilities (not teams), integration patterns from domain-driven design, and AI workflows operating locally within each repository while respecting boundary contracts.

His key principle: "The thinner the coordination layer, the more it scales."

This matters because monorepos work well for AI (full context available) but break organizationally around 50 engineers. Multi-repo setups solve coordination but fragment context. Martin's federation model tries to preserve AI's contextual advantage while enabling organizational scale.

I am grateful for his thinking on this. It complements what Fusion does at the project level.

What the Industry Is Learning

The literature on AI-driven development is growing. A few observations that inform how I think about Fusion:

Bounded autonomy is emerging as consensus. McKinsey, Deloitte, and others converge on the same pattern: AI should operate autonomously within explicit constraints, with clear escalation paths when those constraints are insufficient. Fusion implements this through the Decision structure.

The orchestration layer is becoming strategic. Control of how AI work is governed and coordinated is now a competitive concern, not just infrastructure. Organizations that solve this well will move faster than those that do not.

Human-on-the-loop replaces human-in-the-loop. At AI speed and scale, approving every action is impossible. The shift is toward monitoring, exception handling, and policy governance. Fusion's Coherence Review is one form of this.

Multi-agent coordination remains unsolved. When multiple AI agents contribute to shared artifacts, how do they share decisions? How does coherence work across contributions? This is the next frontier, and Fusion does not yet address it.

What the Safeguards Achieve

Claude Code has its own configuration: CLAUDE.md for context, hooks for automation, permission settings for safety. Fusion builds on this but adds semantic structure that pure configuration cannot provide.

Decisions are first-class objects. They have IDs, categories, statements, and rationale. They can be queried, compared, and versioned. The AI can check its work against them systematically.

Cycles create bounded scope. Each cycle has a clear goal, specific decisions, and a defined completion criterion. This prevents scope creep and makes review tractable.

Coherence reviews are structured. Rather than asking "does it work?", Fusion asks three questions: Does the artifact respect the decisions? Does it advance the goal? Are the decisions still appropriate? This surfaces problems that functional testing would miss.

Session tracking creates accountability. Every session records what happened, when, and in which cycles. You can trace backward from any state to understand how you got there.

These are not things you can achieve with hooks and context files alone. They require data structures and process logic that Fusion provides.

What Working with Fusion Feels Like

The practical experience has two aspects: control and transparency.

Control comes from the Decision structure. When the AI proposes something that contradicts a decision, you can point to the decision. When you want to change direction, you revise the decisions explicitly. The AI respects what you wrote, not what it inferred.

Transparency comes from the session and cycle logs. At any point, you can answer:

  • How long have I been working on this?
  • What cycles did I complete?
  • What decisions did I make?
  • What did the coherence review find?

This matters more than I expected. When AI writes most of the code, it is easy to lose track of what you actually contributed. The logs make your work visible again. You made the decisions. You guided the direction. You reviewed the coherence. The AI implemented, but the project is yours.

I find this helpful for mental health. After two weeks where Claude wrote thousands of lines of code, I can look at the decision history and see my thinking. I can see the cycles I defined, the reviews I conducted, the course corrections I made. The work is traceable back to my judgment, not just the AI's output.

This is not a small thing. As AI takes over more implementation, the question "what did I actually do?" becomes harder to answer. Fusion provides one answer: you decided, you reviewed, you steered. That is documented, timestamped, and yours.

Current Status

Fusion is a work in progress. The core functionality works: session tracking, cycle management, decision storage, coherence reviews. I use it daily on real projects.

What is missing: multi-agent support, deeper integration with Claude Code's native features, better tooling for decision queries, and probably many things I have not yet discovered.

If this approach interests you, let me know. I can give a demo, or release a docker image, I am curious what others find useful and what they would change.

Related articles:

Acknowledgments: Thanks to Martin Jahr for his thinking on repository architecture for AI-driven teams. His articles on the agentic enterprise and federation models have shaped how I think about organizational scale.

Dr. Kai Stalmann · qantr GmbH All writing →