JFM Jean-Francois Maes Security / Red Team / SANS

May 31, 2026

Your AI Workflow Needs a Flight Recorder

A practical agentic workflow that combines Superpowers, Memory Bank, Ralph-style loops, and dynamic workflow packets without turning every task into a paperwork simulator.

Technical control room where multiple AI agent workstations connect to a central traceability ledger
If the run cannot explain itself later, it was not autonomous engineering. It was autocomplete with confidence.

The problem with AI coding agents is not that they cannot write code.

They can write code. Lots of it. Fast.

The problem is that they can also write the wrong code, explain why it is right, skip the test that would have caught it, forget the constraint you gave them forty minutes ago, and then confidently announce that everything is done because the last command they remember running was green.

That is not autonomy.

That is a slot machine with a terminal.

I have been messing with the same family of tools everyone else in this corner of the internet has been messing with: Superpowers, Cursor Memory Bank, Ralph-style loops, Codex workflow skills, subagents, skills, AGENTS.md files, Claude prompts, implementation plans, reflection docs, archive folders, the whole circus.

Every one of those systems solves a real problem.

None of them, by itself, is the whole answer.

Superpowers is excellent at forcing discipline into the agent: brainstorm before building, write tests before implementation, review before shipping, verify before claiming victory.

Cursor Memory Bank is excellent at phase structure: VAN, PLAN, CREATIVE, BUILD, REFLECT, ARCHIVE. It gives the agent a shared memory surface instead of pretending a chat transcript is a project management system.

Ralph-style loops are excellent at sustained execution: take a plan, run it task by task, keep moving while the human does something else.

Dynamic workflow packets are excellent at orchestration: split the work, assign ownership, track state, integrate results, record verification.

The missing piece is not another giant prompt.

The missing piece is the thing that makes all of those ideas cooperate without loading a 1,000-line manifesto into every context window.

You need a flight recorder.

The agent does not need more freedom. It needs boundaries.

Most AI workflow advice quietly assumes that the agent will behave better if you give it more context.

Sometimes that is true.

Usually, past a certain point, it is a trap.

Big context windows do not magically create good engineering behavior. They create a larger room for stale decisions, abandoned approaches, half-remembered constraints, and old debug output to accumulate. The model starts well, then gets weird. It repeats itself. It contradicts the plan. It treats earlier speculation as fact. It “remembers” a test passed because something nearby passed twenty messages ago.

This is why always-loaded instructions should be tiny.

An AGENTS.md should not be a constitution, a diary, a playbook, a template library, a status report, and a therapy journal.

It should be a bootloader.

Something like:

# Agent Autopilot

For non-trivial work, use the ultimate-agentic-workflow skill.

Classify work by tier:
- T0: answer or tiny safe edit directly.
- T1: short approach, execute, verify.
- T2: spec and plan before implementation.
- T3: full traceability workflow.

Do not claim completion without fresh evidence.
Keep always-loaded instructions short.

That is it.

The big workflow should live somewhere else. A skill. A reference doc. A recipe. Something the agent loads only when the task actually needs it.

The agent does not need to recite the entire lifecycle when you ask it to fix a typo.

But when you ask it to build a feature, migrate an API, review a PR, or run overnight, it needs more than “be careful.”

It needs rails.

The workflow is not one tool. It is a stack.

Here is the stack I ended up with.

At the bottom: Superpowers.

Not replaced. Not forked. Not rewritten because we got excited and thought we could do better in a weekend. Superpowers already has the hard behavioral primitives: brainstorming, worktrees, TDD, writing plans, subagent-driven development, code review, verification before completion.

That is the engine.

Above that: Memory Bank.

Memory Bank gives the work a lifecycle. It says a task is not just “prompt -> code -> vibes.” It moves through initialization, planning, creative design, building, reflection, and archive. More importantly, it gives the agent files to update: tasks.md, activeContext.md, progress.md, creative decision records, reflections, archives.

That is the project memory.

Above that: Ralph-style execution.

Not for everything. Absolutely not for everything. Most work does not deserve a loop. But if you have ten or more clear tasks, strong acceptance criteria, and low design ambiguity, an autonomous loop is useful. Let the agent grind through the mechanical work. Make it commit atomically. Make it record what happened.

That is the background worker.

Above that: dynamic workflow packets.

This is the part from DannyMac-style workflow skills that I think matters most: every run gets a .workflow/<slug>/ directory with a human plan, machine-readable state, packet prompts, packet results, and a final report.

That is the flight recorder.

The combined shape looks like this:

AGENTS.md
  -> tiny bootloader

ultimate-agentic-workflow skill
  -> decides tier, loads only what is needed

Superpowers
  -> behavior primitives

memory-bank/
  -> live project memory

.workflow/<run>/
  -> orchestration state and evidence

docs / archive / reflection
  -> durable learning

No single file owns everything.

Each layer has one job.

The tier system is how you avoid paperwork cosplay.

This is where a lot of “serious” AI workflows go wrong.

They discover process. Then they apply all of it to everything.

Now every five-line CSS fix needs a spec, a plan, a risk register, a reflection, an archive, a review board, and probably a commemorative mug.

That is not engineering. That is process cosplay.

The workflow needs tiers.

T0: Just do it.
T1: Think aloud, then do it.
T2: Spec and plan before building.
T3: Full accountable loop.

T0 is the tiny stuff. Answer a question. Fix a typo. Rename a variable in one file. Do it, verify if you make a claim, move on.

T1 is the modest stuff. One to three files, clear scope, some judgment. State the approach in a few sentences, execute, run the relevant check, summarize.

T2 is real work. Multi-file changes. Design choices. Anything another contributor might reasonably care about. You write a brief spec, map acceptance criteria, plan the implementation, then build.

T3 is where the flight recorder comes out. Architecture. Migrations. Security-sensitive work. Multi-agent execution. Long loops. Anything you might need to audit later when someone asks, “Why did the agent do that?”

This matters because the goal is not maximum process.

The goal is minimum sufficient accountability.

The most important artifact is the traceability matrix.

Here is the boring table that makes the whole thing work:

| Req | AC | Decision | Task | Code/Diff | Test/Check | Review | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| REQ-001 | AC-001 | DEC-001 | TASK-001 | commit abc123 | VERIFY-001 | REVIEW-001 | done |

It looks like enterprise sludge.

It is not.

It is the antidote to the most common AI failure mode: plausible completion.

The agent says the feature is done.

Based on what?

If the acceptance criterion maps to a task, the task maps to a diff, the diff maps to a test, the test maps to a fresh run, and a reviewer looked at the result, then fine. We can talk.

If the answer is “the agent said so,” no.

That is not evidence. That is narration.

The traceability matrix changes the conversation. It forces every completion claim to point at something outside the model’s own confidence.

That is the whole game.

Never let the builder be the only reviewer.

The fastest way to get fooled by an AI agent is to ask it whether its own work is good.

It will often find issues. Modern models are not useless at self-review.

But they share context with the implementation. They know what they meant. They know the happy path they were optimizing for. They are anchored on their own explanation.

You want a different pass.

Two separate AI reviewers inspect the same code artifact while a human watches the approval gate
Builder, reviewer, verifier. Different jobs. Different evidence. Different failure modes.

In the combined workflow, review has stages:

  1. Spec compliance review: did the work implement what was actually requested?
  2. Code quality review: is the implementation simple, maintainable, and consistent?
  3. Risk review: did it create security, reliability, data, or operational hazards?
  4. Human review: do we ship, revise, or stop?

The order matters.

Spec compliance comes before code quality. A beautifully factored implementation of the wrong thing is still wrong.

The reviewer should inspect evidence: the requirement, the diff, the tests, the verification output. Not the builder’s inner monologue. Not a long explanation of why the builder thinks it is fine.

Evidence first.

Rationale later.

Verification is not a vibe check.

I want agents to stop saying things like:

This should work now.

That sentence should be illegal in a coding agent.

What command proves it?

Run it.

Read the output.

Map it to the claim.

Then speak.

The workflow uses a verification ledger because otherwise agents turn narrow evidence into broad claims:

| ID | Requirement | Check | Evidence | Expected | Actual | Status |
| --- | --- | --- | --- | --- | --- | --- |
| VERIFY-001 | REQ-001 | Unit test | npm test -- auth.test.ts | pass | 8/8 passed | pass |
| VERIFY-002 | REQ-002 | Build | npm run build | exit 0 | exit 0 | pass |

This is not bureaucracy. This is compression.

Instead of re-reading the whole chat, you can see exactly what was proved and what was not.

And skipped checks have to be visible.

If the agent did not run the browser smoke test because there is no dev server, fine. Say that. If the full test suite is too expensive and it only ran the focused tests, fine. Say that too.

The problem is not skipping a check for a good reason.

The problem is skipping it and then writing the final answer like nothing was skipped.

AGENTS.md is not the workflow. It is the ignition key.

This is the part I would actually install everywhere.

Not the whole document.

Not the diagrams.

Not every template.

Just this mental model:

AGENTS.md = always-loaded bootloader
Skill = operational behavior
Reference doc = detailed manual
.workflow/ = run evidence
memory-bank/ = live task memory
archive/ = historical record

If you put the full workflow in AGENTS.md, you lose.

The agent reads it every time. Your context gets polluted. Tiny tasks become slow. The model starts treating every request like a governance exercise.

Put the router in AGENTS.md.

Put the behavior in a skill.

Put the detail in references.

The agent should load the heavy stuff only when the task tier justifies it.

What a real run looks like

For a T3 task, the run should leave behind something like this:

.workflow/user-auth-hardening/
|-- plan.md
|-- state.json
|-- orchestration.md
|-- packets/
|   |-- 01-discovery.md
|   |-- 02-backend.md
|   |-- 03-tests.md
|   `-- 04-review.md
|-- results/
|   |-- 01-discovery-result.md
|   |-- 02-backend-result.md
|   |-- 03-tests-result.md
|   `-- 04-review-result.md
`-- final-report.md

The plan says what success means.

The state file says what is pending, running, blocked, or complete.

The packet files say who owns what.

The result files say what happened.

The final report says what was accepted, rejected, verified, and deferred.

Now kill the terminal. Compact the context. Come back tomorrow. Hand it to a different agent.

It can recover.

That is the bar.

If the workflow only works while one chat session is warm, it is not a workflow. It is a long prompt with good luck attached.

Reflection is where the system compounds.

Most teams do retros badly with humans.

Agents are worse unless you force the issue.

A useful reflection is not:

Everything went smoothly.

That is a waste of bytes.

A useful reflection says:

  • The plan was wrong because the existing helper already solved half the problem.
  • The agent tried to import a package that was not in the manifest.
  • The test command in AGENTS.md was stale.
  • The subagent packet was too broad and caused duplicated work.
  • The browser smoke test caught a layout bug the unit tests could not see.

Then it updates the right memory surface.

Project-specific command? AGENTS.md or OPS.md, but keep it short.

Current task status? memory-bank/tasks.md or IMPLEMENTATION_PLAN.md.

Design rationale? docs/decisions/ or memory-bank/creative/.

Cross-project lesson? AI_RETRO.md.

Historical record? Archive.

Do not dump everything into the always-loaded file.

That is how context rot starts wearing a fake mustache and calling itself institutional memory.

This is not about trusting AI less.

It is about making trust measurable.

I do not want agents that move slower because they are wrapped in ceremony.

I want agents that can move faster because they leave evidence.

The human should not be the executor. The human should not be manually checking every semicolon. That battle is over.

The human should be the architect, the reviewer of last resort, the person who decides when the risk is acceptable.

The agent should do the reading, planning, building, testing, reviewing, repairing, documenting, and archiving.

But it should do those things in a way that survives contact with reality.

That means:

  • small always-loaded instructions
  • contextual skills
  • tiered ceremony
  • explicit requirements
  • design decisions with rejected alternatives
  • task ownership
  • independent review
  • fresh verification
  • reflection that updates the system
  • archives that future agents can actually use

Not fire and forget.

Launch. Record. Verify. Review. Learn.

The installation I would actually use

If I were putting this into a repo today, I would do this:

  1. Keep Superpowers installed.
  2. Add a tiny AGENTS.md bootloader.
  3. Create an ultimate-agentic-workflow skill.
  4. Put the long workflow document under the skill’s references/ directory.
  5. Add memory-bank/ only when the repo needs persistent task state.
  6. Add .workflow/ only for T3 or multi-agent runs.
  7. Add Ralph loop scripts only if you actually plan to run autonomous batches.

The important part is restraint.

Use the whole machine when the work deserves it.

Do not start the whole machine to change a button label.

The best AI workflow is not the one with the most artifacts. It is the one where, six weeks later, you can answer the uncomfortable questions:

Why did we build this?

Who decided that?

What did the agent change?

What proved it worked?

What did we learn?

If your workflow can answer those questions, you can let the agents run.

If it cannot, you are not doing autonomous engineering.

You are gambling with autocomplete.