Now I have strong material. The key themes are:

1. A system crossing from validation to production - both the content pipeline and the agent orchestration
2. Martin Fowler's what/how abstraction as external reference - the negotiation mode missing from single-agent mental models
3. Cognitive debt (Willison/Yegge) - the shift from "code nobody maintains" to "code nobody understands"
4. The revision loop as the real value - QA agents doing 67 shell commands, not just rubber-stamping

The essay shape is THRESHOLD: the line between a system that proves it works and a system that does real work. Let me write this.

The Line Between Proving and Doing

Every system has a moment where it stops demonstrating capability and starts producing outcomes. This transition is not gradual. It is a step function, and most teams miss the exact moment it happens because the work on both sides looks identical from the outside.

The distinction matters because the economics flip completely at the threshold. Below the line, every successful run proves the system works. Above it, every successful run produces something someone uses. The inputs are the same. The commands are the same. The outputs look the same. But one is rehearsal and the other is performance, and confusing which side you're on is one of the most expensive mistakes in software.

What Changes When the Audience Is Real

Martin Fowler's recent piece on the what/how conversation in LLM interactions describes a clean abstraction: you tell the model what you want, it figures out how. But Fowler's framing assumes a single agent with a single human. The moment you introduce a second agent, the interface stops being what-versus-how and becomes something harder: competing interpretations of "done."

I hit this exact boundary this week while running paired dev-QA agent workflows. The dev agent implements a feature. The QA agent reviews it. When QA posts NEEDS_REVISION to the shared blackboard, that's not a what/how conversation. It's a negotiation. The QA agent ran 67 shell commands during one verification pass: type checking, linting, targeted test files, commit history validation. It has its own model of what "done" means, and that model conflicts with the dev agent's model. The revision loop that follows is where the actual value lives.

This only works when both agents are operating on real code in a real repository. During the weeks I spent validating the coordination protocol, the same message exchange happened. Registration, heartbeat, blackboard write, signal. Structurally identical. But the QA agent's 67 commands were checking code that would ship, not code that existed solely to exercise the protocol. The ceremony is the same. The substance is not.

Backpressure as Architecture

Steve Yegge's "AI Vampire" essay, surfaced through Simon Willison's link blog, diagnoses what he calls agent fatigue: the exhaustion that comes from working alongside AI systems that never stop producing. His prescription is essentially personal. Pace yourself. Set boundaries. Take breaks.

This misses the structural problem entirely.

When you build a pipeline that ingests content from eight sources, synthesizes journal entries, generates blog posts, adapts them for three social platforms, and then ingests its own output as tomorrow's input, the issue is not human burnout. It is the absence of backpressure. The system has no mechanism to say "I have enough." Every content item gets processed. Every journal entry feeds forward. The pipeline is as eager on day 100 as day 1, and the human reviewing its output is not.

Backpressure is a concept from reactive systems design: when a consumer cannot keep up with a producer, the producer must slow down or the system fails. Jay Kreps wrote about this extensively in the context of Apache Kafka and log-based architectures. The same principle applies to any automated content system. Without explicit flow control, you get what distributed systems engineers call "unbounded queues": backlogs that grow until something breaks. In a content pipeline, what breaks is editorial judgment. You stop reading the output carefully. You approve drafts you should have revised. The quality degrades not because the generator got worse but because the reviewer got overwhelmed.

The fix is architectural, not motivational. Circuit breakers that pause generation when the review queue exceeds a threshold. Deduplication gates that suppress content too similar to recent output. Priority scoring that surfaces the pieces most worth human attention and quietly archives the rest. These are standard patterns in message-oriented middleware. They are almost entirely absent from AI content generation tooling.

The Revision Cycle Is the Product

The most counterintuitive discovery from running autonomous dev-QA workflows is that the revision cycle adds more value than the initial implementation. A dev agent writing a clean endpoint on the first pass is table stakes. The QA agent sending it back with specific findings posted to a shared blackboard, the dev agent reading those findings and correcting its work, the QA agent re-verifying: that loop is where quality actually enters the system.

This is not a new idea. Michael Feathers argued in Working Effectively with Legacy Code that the value of tests is not in catching bugs but in enabling confident change. The QA agent serves the same function. Its 67 shell commands are not primarily about finding defects. They are about creating a verified record that the code meets a standard someone other than the author defined. The dev agent writes code it believes is correct. The QA agent checks whether "correct" means the same thing to both of them.

Without the revision loop, you get what I had for weeks: agents completing tasks and signaling "done" without any friction. Every workflow succeeded. Every signal landed. And the output was mediocre, because nothing in the system disagreed with anything else. The protocol was flawless. The product was not.

Measuring the Threshold

The production threshold is visible in the data if you know where to look. Below the line, sessions cluster around validation patterns: the same tests run repeatedly, the same protocol exercised with minor variations, success measured by the absence of errors. Above the line, sessions diversify. Different files get modified. New problems appear. Error rates actually increase because the system is encountering real-world inputs it wasn't designed for.

The content pipeline's first production run processed 341 items from 20 sources. The entity extraction batched across multiple Claude invocations. The social publishers reformatted the weekly essay for LinkedIn, Twitter, and Slack with platform-specific voice and constraints. None of this was new code. It was the same architecture built over previous weeks. But the inputs were real RSS feeds with real formatting inconsistencies, real session logs with real debugging tangents, real editorial judgments about what deserved attention.

Error rates went up. That is the correct signal. A system operating below the threshold on synthetic inputs has an artificially low error rate because the inputs were chosen to succeed. A system operating above the threshold on real inputs encounters the messy, inconsistent, occasionally malformed data that production always delivers. The 78% error rate on sessions touching more than five files is not a problem to solve. It is a measurement confirming that those sessions are doing real work on real complexity.

The Step Function

The transition from proving to doing is a step function because it requires a decision, not an optimization. No amount of incremental improvement to a validation loop will turn it into production use. You have to point the system at real inputs, accept that some runs will fail, and commit to using the output rather than merely inspecting it.

The coordination overhead that seemed problematic during validation turns out to be negligible in production. Registration takes seconds. Heartbeats are background noise. Signal polling is mechanical. These costs felt enormous when the task being coordinated was "prove the protocol works." They feel invisible when the task is "implement this endpoint and ship it." The overhead did not change. The denominator did.

This is the threshold: not when the system is ready, but when you decide to use it. The system was ready weeks ago. What changed was the willingness to trust its output as input to the next real decision rather than the next validation run. Every builder of automated systems faces this exact moment. The temptation is to run one more test, add one more check, validate one more edge case. The threshold is crossed when you stop proving and start doing. The work looks the same from the outside. The economics are completely different.