We Built Martin Fowler's AI Feedback Flywheel Before He Named It

On April 9, 2026, Martin Fowler published a detailed article describing a pattern he calls the Feedback Flywheel — a system for converting individual AI interactions into collective team improvement.

We'd been running the same system for months.

Not because we copied it. We hadn't read the article yet. We built it because it was the obvious solution to a real problem: every AI interaction generates useful signal, and almost every team throws that signal away.

This post describes Fowler's framework, shows our implementation, and explains why this pattern is the difference between a team that gets 10% better at using AI each month and one that stays flat.

What Fowler Describes

Fowler's Feedback Flywheel has two layers: signal types and shared artifacts.

The four signal types he identifies:

• Context signals — facts about your codebase, domain, or project that the AI needs to do good work
• Instruction signals — prompts, commands, and phrasings that reliably produce good output
• Workflow signals — multi-step sequences that work well end-to-end
• Failure signals — cases where the AI did something wrong, so you can guard against it

Those signals feed into four shared artifacts:

• Priming docs — shared context files the whole team pulls into every session
• Commands — reusable prompt templates anyone can invoke
• Playbooks — documented workflows for recurring tasks
• Guardrails — explicit constraints that prevent known failure modes

The cadence runs at four levels: after each session, at standup, at retro, and quarterly. The key metric Fowler proposes: declining instances of "why did the AI do that?"

It's a clean framework. Respected source. But here's the thing — the pattern isn't new. Any team operating AI agents seriously in production has to build some version of this or watch the system degrade.

What We Built

Our implementation lives across three systems: the Obsidian vault, the autotron agent network, and AgentGuard.

Layer 1: The Vault (Signal Capture)

Every meaningful AI interaction — good or bad — gets logged. The vault has a structured Feedback/ directory that captures:

• What the prompt was
• What the output was
• Whether it worked
• What to do differently next time

This maps directly to Fowler's four signal types. Context signals become context/ files read by every agent at startup. Instruction signals become reusable prompt templates. Workflow signals become the scheduled task SKILL.md files that now run autonomously. Failure signals become guardrails.

The difference from most team setups: ours is written to be machine-readable, not just human-readable. Agents ingest these files. They're not documentation — they're runtime configuration.

Layer 2: The Agent Network (Signal Processing)

The autotron system runs a suite of scheduled agents: CMO, CFO, standup, deal monitor, market scout, and others. Each agent:

1. Reads the shared context files at startup
2. Executes its task
3. Writes findings back to the shared memory system
4. Updates queue files that other agents read on their next run

This is Fowler's flywheel operating autonomously. No human has to manually move signals from one place to another. The standup agent writes decisions that the CMO agent reads. The market scout writes intelligence that the deal monitor acts on. The system compounds.

Signal captured → shared artifact updated → next agent reads it → better output

Every cycle, the system knows a little more. Every agent run improves the baseline.

Layer 3: AgentGuard (The Guardrail Layer)

Fowler's "failure signal → guardrail" step is the hardest to implement in practice. Most teams write notes after an agent goes wrong. Notes don't stop the next agent from making the same mistake.

AgentGuard is our implementation of live guardrails. It enforces hard constraints at runtime:

• Budget limits — agents cannot spend beyond a defined threshold per session or per day
• Token limits — runaway context expansion gets caught before the bill arrives
• Time limits — agents that run too long get killed, not left hanging
• Rate limits — prevents API hammering on transient errors

This maps directly to Fowler's guardrail artifact. The difference: AgentGuard enforces guardrails programmatically, not through documentation. A failure signal doesn't become a note in a file — it becomes a guard condition that triggers automatically on the next run.

from agentguard import Guard

guard = Guard(
    budget_limit=5.00,       # hard stop at $5
    token_limit=100_000,     # no runaway context
    time_limit=300,          # 5 min max
)

@guard.protect
def run_agent():
    # your agent logic here
    ...

When a new failure mode is discovered, a new guard condition gets added. The system can't repeat the same expensive mistake twice.

The Weekly Cadence

Fowler recommends four cadence levels. Ours runs on a similar structure:

The weekly review is the most important cycle. It's where individual session learnings get promoted into system-level changes. A prompt that worked once becomes a template. A failure that happened twice becomes a guardrail.

Why This Matters for AI Adoption

Most teams use AI the way they used Google in 2005 — individually, episodically, with no shared memory. Every person starts fresh. The team collectively learns nothing.

The Feedback Flywheel is the answer to that problem. It's how you turn AI from a personal productivity tool into a team capability that compounds.

Fowler's contribution is naming it clearly and giving teams a vocabulary to talk about it. That's not nothing — named patterns get implemented. Unnamed patterns stay accidental.

But implementation is where it gets real. Building AI agents that run reliably in production requires exactly this kind of compounding infrastructure. Without it, each new agent starts from zero. With it, each new agent inherits the collective intelligence of everything that ran before.

What to Build First

If you want to implement a Feedback Flywheel for your team, start here:

Week 1: Create a shared context file. One document everyone pulls into every AI session. Put your domain glossary, common workflows, and "don't do this" notes in it. Update it after every session.

Week 2: Build a failure log. When an AI output goes wrong, write down what the prompt was and what went wrong. After 10 entries, you'll see patterns. Turn those patterns into constraints.

Week 3: Add a budget guardrail. If you're running autonomous agents, add a hard spend limit before they touch production. The cost of one runaway agent can wipe out a month of savings.

Week 4: Run a retro on your AI tooling. What prompts are people reusing manually? Turn them into shared commands. What workflows run every week? Turn them into scheduled agents.

By week 4 you have the skeleton of a Feedback Flywheel. It compounds from there.

FAQ

What is the AI Feedback Flywheel? A pattern for converting individual AI interactions into shared team improvement. Four signal types (context, instruction, workflow, failure) feed into four artifacts (priming docs, commands, playbooks, guardrails) on four cadences.

How do you implement it? Start with a shared context file. Add a failure log. Build budget guardrails. Run weekly retros to promote learnings into shared infrastructure. It compounds from there.

What does AgentGuard have to do with it? AgentGuard implements the guardrail artifact programmatically. Failure signals don't become notes — they become runtime constraints that trigger automatically.

Why does it matter? Without it, teams plateau. With it, every week's AI interactions make the next week's outputs better. That's the compounding advantage.

---

Building an AI system that actually compounds over time requires infrastructure, not just prompts. If you want help designing and implementing the right architecture for your team, start here.