2080668775796314331

Justy The model was never the bottleneck. The line you drew was — that is a very good sentence, and also exactly the kind of sentence that makes an AI engineering article start wearing a cape.

Cody Yeah, the cape is optional. The underlying claim is much less dramatic: inspect the dependencies in a workflow, remove the fake ones, and run independent work concurrently.

Justy Which matters right now because everyone is building these long agent workflows and then acting surprised when a twelve-step chain takes twelve-step-chain time. This is episode 857, and somehow we are still discovering that waiting is a feature people accidentally add.

Cody The article calls that graph engineering, but it admits the pattern is decades old. A node is a bounded job with a defined input and output. An edge means an actual result moves from one job to the next. That vocabulary is simple and old enough that I trust it more than a fresh paradigm label.

Justy The article’s real test is wonderfully boring. For every step, ask whether it actually needs the previous step’s result. Reviewing file A for bugs and reviewing file B for bugs can happen together, because the second review doesn’t consume the first.

Cody Exactly. The sequence in the prompt gets mistaken for a dependency in the work. If forty jobs are really four layers of ten, latency is closer to the slowest job in each layer than the sum of all forty. But that’s a best-case shape, not a universal fifteen-second button.

Cody You still pay for scheduling, model calls, retries, rate limits, serialization, and merging. The claim that real dependencies are usually only three to five layers may fit some research workflows, but it isn’t a law. A graph can be parallel on paper and serialized by the tools around it.

Justy That distinction is the product story for me. A team shouldn’t buy graphness. They should care whether a recurring market scan, code review, or research report finishes sooner without becoming impossible to inspect.

Cody The pattern it recommends is the diamond: fan out, reduce, synthesize. Independent workers gather different angles, ordinary code compresses the results, then a final agent writes the answer. The article says Claude’s research feature uses that shape in production. I’d treat that as an example, not proof every workflow should copy it.

Justy The reduce step is the bit people skip because it’s less exciting than adding another agent. They collect a hundred blobs of prose and hand the whole pile to one expensive model.

Cody That’s where context collapse shows up. The fix is layered fan-in: batch outputs, summarize each batch, then combine those summaries. It also recommends cheap models for routine nodes and stronger models where judgment lives. That’s real cost control, even if the skeleton sounds too universal.

Justy Also, I love that diagramming is having a comeback as an AI skill. Somewhere, a box-and-arrow chart just got promoted to senior engineer.

Justy No, genuinely. The useful shift is from asking how to make one agent do more steps to asking where work splits and where it has to merge. That changes what you inspect when a workflow is slow.

Cody And the checker is the strongest part. The worker shouldn’t verify its own result in the same context, because verification inherits the worker’s assumptions. The verifier needs a fresh context and should test the claim itself, not just accept that the task is complete.

Cody I agree with the direction, with one qualification: a fresh context isn’t automatically independent. It can share the same model weakness, bad source, or misleading prompt. Separate checks for correctness, currency, and source reality are better, but independence also needs different evidence or procedures.

Justy That lands with the judgment-layer thing we keep circling. More workers create more output. They don’t create more truth. If anything, they create a larger surface where missing results can hide.

Cody Yes, and graphs fail quietly in a way chains fail loudly. One worker can die among two hundred and the final report can still look complete. Every merge needs to know how many inputs it expected and flag the gap. Shared workspaces are another trap: agents can overwrite the same file or collide on a rate-limited API.

Justy That is such a glamorous future. A hundred brilliant agents, defeated by one shared folder.

Justy And this is where I push back on the article’s confidence. The diamond isn’t the only pattern you need. If the task is one bug, one small change, or something exploratory where you want to steer every move, graph coordination is overhead. If every step depends on the last, forcing breadth just adds handoffs.

Cody No, I think that’s right. The article says graphs buy breadth, not better judgment. The broader field keeps renaming orchestration patterns — another entrant in the same fight around selective routing and execution harnesses. The unresolved question is task shape: where is parallel work real, and where is it just a team costume?

Cody So my read is that the mechanism holds, the marketing frame is oversized, and the useful test is actionable. Draw the workflow, inspect each arrow, then measure whether removing one changes correctness or only waiting time.

Cody What?

Justy Nothing. We have been doing this since November, and after almost a year of Exploring Next, our grand frontier insight is still: check whether the thing is waiting for a reason.

Justy Okay, Cody, I’m keeping the boxes and arrows. You can keep the cape in the infrastructure closet. That’s enough graph engineering for one Wednesday.