The shape of the work is a graph, not a queue

I spent about a year running my prompt briefs one at a time, in the order I happened to write them, and calling that a method.

Then I looked at a plan I'd just filed — 6 briefs for one feature — and asked a question I'd never thought to ask. Does brief 4 need anything from brief 3? It did not. Did brief 5 touch a single file brief 2 touched? It did not. Three of the 6 were completely unrelated to each other, and I had queued them behind one another for no reason except that I'd typed them in that order.

The work had a shape. I just hadn't drawn it.

The straight line I was walking

A queue is the default because it's the thing you get for free. You write briefs top to bottom, you run them top to bottom, and nothing ever tells you that some of those arrows are imaginary.

The cost is invisible, which is why it survives. A build that takes 5 sessions in sequence still finishes. Nobody stands over it saying three of these could have run this morning. You only see it if you go looking, and the only reason I went looking is that the sequence had started to annoy me.

This isn't a new observation, incidentally. Data engineering worked it out decades ago and named the result a DAG — a directed acyclic graph, a set of jobs with arrows showing which genuinely depend on which. Tools like Airflow exist because someone noticed that a nightly data pipeline is not a list. What's new is that the jobs are now agents, and most people running them are still writing lists.

Nodes do the work, edges carry the result

Two words do most of the lifting, and both are simpler than they sound.

A node is one agent doing one bounded job. In C² you already have these — a node is a Prompt Brief, the atomic build unit, and the brief is what tells the node what it's for.

An edge is what crosses between two nodes. Not "this one comes after that one" — an edge exists when something actually moves. Brief B reads the schema brief A emits. Brief B can't start until that schema exists. That's an edge, and the thing that makes it real is the artefact, not the order.

The distinction matters because it's the whole test:

Stuart Leo

"PB-2 after PB-1" is a queue. "PB-2 consumes the schema PB-1 emits" is an edge. One of those is a decision. The other is just the order you typed them in.

Once you're naming edges by what crosses them, most of the arrows in a plan turn out to be nothing. They were habits.

The fan-out that was already in my brief set

Here's the part that reframed the method for me.

C² breaks a feature down through the Cascade — Platform PRD, then Feature PRD, then Prompt Brief × N. That × N is doing something specific: it produces several sibling briefs under one PRD. Siblings. No edge between them by construction, because each one was scoped to be an atomic unit of work in its own right.

That's a fan-out — several independent jobs that can run at the same time. It was sitting in the method the whole time, described as a decomposition step, and nothing anywhere said the resulting briefs could run at once.

Cascade is a waterfall word for a structure that was already a graph.

Not every set fans out, and this is where the honest test comes in. Two briefs are independent when two things are true: no edge connects them, and no surface is shared. A surface is everything a brief mutates or contends for — files, yes, but also a database, a rate-limited API, one deploy target. Two briefs whose file lists don't overlap can still both hammer one staging database, and that's the collision nobody sees coming, because nothing in either brief declares it.

The cheap part is that you've already written the evidence. An autonomous brief carries a pre-flight table listing exactly the files it will touch. That table is a declaration of the brief's surface. The arrows are derivable from something the plan already produces.

Barriers, and why you have to earn one

Work that fans out has to come back together somewhere. That point is a barrier — a step that waits for everything before it.

You already have barriers. The integration brief is one. The pull request is one. The review before a merge is one. What's worth knowing is that a barrier is expensive in a specific way: it makes every branch wait for the slowest one. Five briefs that each take an hour, plus one that takes four, means the barrier costs you three hours of idle.

So a barrier needs a reason. A real one looks like this step genuinely needs all of them at once — merging into one branch, deduplicating across the whole set, an early exit if the total comes back empty. A bad reason is "it's tidier." Tidiness is not a dependency.

And a caution that belongs in the same breath, because it's the one I'd want said to me: running wide buys breadth, not judgment. A graph gets more surface covered per hour. It doesn't make any individual result better, and it will happily produce 6 confident, useless outputs at 6 times the speed. If the work is exploratory and you need to steer, that's one agent and one loop, no matter how many you could spin up.

Drawing it: the fifth part of a filed plan

None of this is useful as a concept. It's useful as a thing you write down before you build, which is why it now has a home in the ceremony.

Flight Planning is the review where you file your plan before an agent burns a session. It used to have 4 parts — the line, the briefs, the journey, and an optional red line. It now has 5. The new one is the shape, and it states four things about the brief set:

The shape
  independent   PB-2 + PB-3 (no edge, no shared surface) — can run at once
  edges         PB-1 → PB-2  (the route table crosses)
  barrier       the PR — needs all three branches
  verified      PB-1's output gets a bench pass before it counts

That's a route. What I was filing before was a queue with dates on it.

The honest cost is small but real: it's one more thing to think about before you're allowed to start, at exactly the moment you want to start. It takes maybe 10 minutes. And some plans come back a straight line — which is a finding, not a failure. A line is just a graph with one edge in and one edge out. Filing "this is a line, and here's why" is fine. Never asking is the problem.

There's a second cost worth naming. If you can't find two briefs with no edge between them, there's nothing to spread, and forcing it produces a diagram rather than a speed-up. The answer then is one agent, working in sequence, which is the right answer most days.

The arrows you never checked

I'd been treating the order I wrote things in as the order they had to happen. That's the whole mistake, and it's an easy one, because a queue never complains.

Work has a shape. Nodes do the jobs, edges carry what crosses between them, and a barrier is where the parallel paths come back. Most of the arrows in a plan are real. Some of them are just the order you typed. The only way to tell is to draw it — and half the waits in your build were never necessary.

Start here: see how the Cascade breaks work down, how to isolate parallel agents with git worktrees, or read the method.