Forcing functions for autonomous pipelines

Hook

Walk into a stalled autonomous-agent repo and look at the top level. Seventeen analysis documents. RISK-CHECKLIST-blog-infrastructure.md, PULSE_RISK_SCANNER_REPORT.md, PULSE_RISK_SUMMARY_EXECUTIVE.md, CODEBASE_SCOUT_REPORT.md, three WARDROBE-* files, five REQUIREMENTS* variants. Inside .planning/, thirty-three more — phase-1-plan.md, phase-1-plan-old.md, phase-1-plan-old-eventdash.md, phase-1-plan-spark.md.backup. The STATUS.md and TASKS.md files have drifted weeks behind git. The pipeline is technically running. Crons are firing. Agents are returning. No code has shipped in eleven days.

This is not a broken pipeline. It is a pipeline doing exactly what it was built to do — produce analysis. There was just nothing in it that ever turned analysis into a decision.

The pattern

Call this the analysis-as-progress fallacy: when an autonomous-agent pipeline lacks a forcing function, agents will produce analysis instead of progress. A PRD enters. Debates run. Planning starts. Scout reports get written. Risk checklists get written. Requirements analyses get written. And then — nothing forces the question given these analyses, are we shipping or killing? So the analyses pile up at the repo root and the project drifts off the daemon's radar.

The pattern shows up wherever (a) agents can produce documents, (b) agents have no explicit "decide" authority, and (c) "more analysis" is a valid move from any state. Every autonomous pipeline you build will have all three properties unless you design against them. Generating an analysis doc feels like progress to the agent, the operator watching the log, and the diff viewer reading commits. It is not progress. It is a phase that has no exit.

The graveyard is diagnostic. Three analysis docs at the repo root is a smell. Five is a stalled project. Seventeen is a project that has been stalled long enough that the daemon stopped trying to dispatch it and the human stopped checking. The names of the docs tell you what the project tried to plan and never shipped. Read them before deleting — that history is the lesson the next pipeline pays for if you lose it.

Why "more agents" is the wrong fix

The instinct, looking at this graveyard, is "we need a product manager." The instinct is directionally right. The proposed fix — add a great-pm-plugin with new PM personas — is the wrong shape. The PM personas, like every other persona in the pipeline, will produce documents. They will produce PM documents instead of risk documents. The great-pm-plugin ships an AGILE-FRAMEWORK-RECOMMENDATION.md and the project is now stalled at eighteen analysis docs instead of seventeen.

You do not have a missing-persona problem. You have a missing-decision problem. Adding more analysis-producing agents to a pipeline that already over-produces analysis amplifies the failure. The gap is structural, not staffing.

The forcing function

A forcing function is the thing in the pipeline that, at hour N or doc-count M, forces the question build, kill, or page a human? It is not an agent that produces a document. It is a structural mechanism that dispatches a decision-register persona — someone whose literal job is to decide, not to analyze.

Marty Cagan's four-risks framing is the worked example. For any project, ask: of the four product risks — value (will users want it?), usability (can they use it?), feasibility (can we build it?), viability (does it make business sense?) — which did the existing analyses test, and was the answer no? If the analyses tested feasibility seventeen times and never tested value, the project is stuck on the wrong axis and should be killed or restarted. If feasibility-no came back clear three docs ago, the project should have shipped a week ago. The four-risks lens is a finite ruler against an infinite analysis surface.

The mechanism that uses the lens is a stall-detector cron. Every four hours, scan projects/, classify each project GREEN/YELLOW/RED/BLACK by analysis-doc count, time-in-phase, and hours-since-last-commit. For YELLOW and RED, write a Cagan dispatch entry to .daemon-queue.json. For BLACK, escalate to the human. Cagan does not write another analysis. He reads the existing ones, applies the four-risks lens, and returns SHIP, KILL, or HUMAN-PAGE. The register is "decide, don't analyze," and the prompt is structured to refuse a fourth option.

Throttle the forcing function

A forcing function with no cap loops. Cagan dispatched at 4h, returns "more discovery needed" (he should not, but he sometimes will), the stall persists, the cron fires at 8h, dispatches Cagan again, repeat. You now have a faster version of the same problem. Cap it: max_per_project_per_window: 2. After the cap, the next firing is not Cagan — it is an escalation entry pinged at the human. The human is the ultimate forcing function. The cron's job is to triage what reaches them, not replace them.

Deliverable

Walk into your own autonomous-agent project and count the analysis docs at the root. If the count is over three, you do not have a missing-PM problem — you have a missing forcing function. Build the stall-detector with the four-risks lens and the dispatch cap before you add another persona to the roster. The pipeline that ships is the one that has somewhere "decide" can come from.

Cross-reference

l8 covers what to do when an individual agent crashes mid-task — that is recovery at the agent level. This lesson is recovery at the pipeline level: the agents are not crashing, they are completing successfully and producing the wrong kind of output. l7 establishes the brief as the unit of agent work; the forcing function is the brief equivalent at the pipeline scale, naming what counts as done so the system can refuse to keep generating.

Further reading

• "Personas Are Channels. Something Else Has to Decide When to Call Them." — the published version of why adding more personas does not produce more decisions, and what does.