Don't draw the graph on day one

Every time a new structural idea lands in agent development, the same thing happens. People read the piece, open a diagramming tool, and design the whole system before they've run any of it.

I've done it. I drew a beautiful 9-node workflow for a code audit, complete with parallel branches and a merge step, before I'd ever run that audit even once by hand. It was elegant, it was wrong in about 4 places, and I only found that out by running it — at which point the elegance was the problem, because a 9-node structure is much harder to change than a paragraph of instructions.

The structure encoded assumptions I hadn't checked. That's the failure, and it has an order that prevents it.

The most common mistake in the whole shift

Building the graph too early is the number one mistake in this transition, and it's worth being precise about why, because "don't over-engineer" is too vague to act on.

A topology is a set of claims. These two jobs are independent. This step needs everything before it. This result should be checked before it counts. Every arrow you draw is an assertion about how the work behaves.

On day one you have no evidence for any of them. You're not designing from observation — you're designing from a blog post about somebody else's work, which behaved the way it did for reasons specific to their codebase, their team, and their problem.

And the cost isn't just being wrong. It's that structure is sticky. A wrong instruction gets rewritten in 30 seconds. A wrong topology gets defended, because someone built it and it looks like architecture. Premature structure produces the thing YAGNI has warned about for 20 years — the cost isn't only the work you did, it's the work you now have to maintain and reason around.

Stuart Leo

Every arrow you draw is a claim about how the work behaves. On day one, you have no evidence for any of them.

The order that actually works

The sequence that holds, and I've now watched it hold across several projects:

1. Start simpler than feels sufficient. One agent, one brief, one loop. Yes, really.
2. Collect traces. Run it repeatedly and record what actually happened — what stalled, what collided, what you found yourself doing by hand every time.
3. Find the stable patterns. Look for the things that recur. Not the interesting one-offs, the boring repeats.
4. Formalise only what deserves control. Turn a repeated pattern into structure. Leave the rest loose.

Step 2 is the one everybody skips, because it feels like the un-fun part. It's the entire load-bearing step. Structure without traces is decoration.

The instinct to skip it is understandable — collecting traces sounds like tooling you don't have. Which brings me to the part I think C² gets to claim.

Your contextbase is already the trace collection

Here's the thing I didn't notice for a long time, despite it sitting in my own repo.

The contextbase — the folder of markdown your agent reads before it acts — is the trace collection. Not a substitute for one. The actual thing.

Every session brief is a record of a run: what was attempted, what changed, what blocked, what's next. Every gotcha is a recorded failure with its cause. Every prompt brief's pre-flight table is a record of which files a job actually touched. That's exactly the material step 2 asks you to gather, and if you've been running the method you've been gathering it by accident.

Read 50 of them together and the patterns are not subtle:

• Which surfaces keep colliding. Two areas that show up in the same session brief again and again, fighting each other, are one surface pretending to be two.
• Which briefs kept stalling. A brief type that always overruns is either badly scoped or it's really 2 briefs.
• What you did by hand every single time. That's your first automation candidate, and it's earned.
• Which jobs never once shared anything. That's your fan-out, evidenced rather than guessed.

None of that is available on day one. All of it is free by day 50, if you wrote things down.

Topology is earned by contextbase, not adopted from an article.

What 50 sessions buys you

A concrete example, because the general claim is easy to nod at.

I now run a code-audit workflow with a fan-out. It works well. But I didn't design it — I extracted it, and the extraction took about 20 minutes, because the evidence was already written down.

Reading back through session briefs, the same shape kept appearing: I'd audit for correctness, then separately for security, then separately for whether the docs still matched. Three passes, always the same three, always in whatever order I felt like. The briefs also told me those three never once touched the same files, because their pre-flight tables never overlapped. And the same two gotchas came up every time I did the security pass, because I kept forgetting them.

That's a fan-out with 3 nodes, a shared reading list, and 2 frozen rules — derived entirely from records I'd written for a completely different reason. I didn't need a design session. I needed to read my own notes.

The honest cost is that this is slow. You cannot shortcut to day 50. It asks you to write a brief at the end of every session for weeks before the payoff is visible, and for most of that time it feels like admin. That's the real price of the method, and I'd rather say it plainly than pretend the discipline is free.

What to do on day one instead

If you're at the beginning, the answer is not a smaller graph. It's no graph.

• Run one agent against one brief. Get that loop reliable — knowing what "done" means, having something checkable at the end.
• Write the session brief every time. This is the whole investment. Five minutes, at the moment you least want to.
• Capture gotchas as they bite. One file each, in git, so the next session reads them.
• Wait. For a few weeks. Genuinely.

Then, when you catch yourself doing the same 3 things in the same order for the fourth time, you'll have both the pattern and the evidence for it. That's when the structure is worth building, and it'll be right, because it came from what happened rather than what you imagined would happen.

There's a version of this rule stated in adoption terms too: if you aren't already running concurrent agents behind a verification loop you trust, the graph isn't your next move — the loop is. Same governor, different ladder.

The graph is the last thing you build

The enthusiasm is warranted. Running work wide genuinely is a capability that didn't exist a couple of years ago, and the demos are not fake.

The order is what people get wrong. The graph is where this ends up, not where it starts — and the thing that gets you there isn't a diagramming session. It's 50 sessions of writing down what actually happened, which is unglamorous, cheap, and the only real evidence you'll ever have.

Topology is earned by contextbase, not adopted from an article. Including this one.

Start here: see what a contextbase is, write your first session brief, or read the method.