Why beads are replacing loops in agents

A pilgrim messaged my Camino agent last week with a question I've answered a thousand times on the trail myself: "What do I need to know for tomorrow on the Norte?" It's a great question because it isn't one question. She wants the next stage, somewhere to sleep in that town, and whether it's going to rain on her while she walks. Three separate lookups, one answer.

My agent handled it. It also took its sweet time, because under the hood it was doing the three lookups one after another, each one waiting for the last to finish before it even started. And when the weather API hiccupped on the third call, the whole turn started over. Route and beds, already fetched, thrown away and fetched again.

That's the loop showing its seams. And once you see it, you can't unsee it.

A loop is temporal repetition

Most agents you've built, including most of mine, are a loop. Call the model, let it pick a tool, run the tool, feed the result back, call the model again. Keep going until the model says it's done. The Claude Agent SDK that powers my Camino guide works exactly this way, and for a conversation it's the right shape. A pilgrim asks a follow-up, the loop turns once more, done.

The trouble is that a loop only knows how to do one thing: the same step, again. It's temporal repetition. When the real work needs three tools that don't depend on each other, the loop still runs them in a line, because a line is the only thing it can draw. You get correctness and you pay for it in latency, and you get all-or-nothing retries because the loop has no idea which step actually failed.

A bead is structural composition

A bead is a discrete unit of work in a graph. It takes an input, does one thing (calls a tool, runs the model, transforms some data), and hands its output to whatever comes next. String beads together with edges and you have a graph: the map of every path the work is allowed to take.

The shift is from when to how it's wired. A loop is temporal, it repeats over time. A graph is structural, it's composed in space. That sounds abstract until you list what the structure buys you:

• Each bead has defined inputs and outputs, so you can test one in isolation.
• Execution follows edges, so routing is explicit instead of buried in a prompt.
• Beads that don't depend on each other run in parallel.
• Branches are first class: different beads fire based on what a prior bead returned.

That third point is the one my Camino agent was starving for.

The day brief, drawn as a graph

Here's the same day brief as a loop and as a graph, side by side.

Left, the loop stacks three waits end to end and re-runs the whole turn on any failure. Right, the graph classifies once, fans the three lookups out in parallel, and merges them into one brief.

On the left, the loop does the honest thing and the slow thing. Classify, then search_routes, then wait, then search_accommodations, then wait, then get_weather, then wait, then write the brief. Total time is the sum of all three round trips.

On the right, one bead classifies the intent, then the graph fans out. search_routes, search_accommodations, and get_weather are independent, so they fire at the same time. A synthesize bead waits for all three, merges them, and writes the brief. Total time drops to the slowest single lookup instead of the sum of all of them. Same tools, same model, different shape.

A while loop can't express that fan-out and fan-in cleanly. You'd end up hand-rolling parallel calls and a join, at which point you've built a little graph engine anyway, just without admitting it.

Retrying one bead, not the whole run

The parallelism is nice. Re-entry is the part that changed how I think.

When the weather bead flaked in my opening story, the loop had no choice but to start the turn over, because a loop's only unit of progress is the whole turn. A graph tracks progress per bead. Route and beds already succeeded and their outputs are sitting right there. So I re-enter at get_weather alone, run that one node again, and the graph continues to synthesize as if nothing happened. I retry the step that failed, not the sequence that contained it.

This is exactly why LangGraph, CrewAI, and Anthropic's own agent patterns model work as graphs instead of loops. Real tasks branch, use different tools, and fail in specific spots. A graph gives you a named place to re-enter. A loop gives you a stack trace and a shrug.

When a loop is still the right shape

I'm not ripping every loop out of my code, and you shouldn't either. The conversational turn in my Camino agent is going to stay a loop, because a back-and-forth chat genuinely is temporal repetition. Pilgrim asks, agent answers, repeat. Forcing that into a graph would be architecture for its own sake, and I've shipped enough of that in my career to recognize the smell.

The rule I've landed on: if the work is "do this again until done," a loop is honest. If the work is "do these things, some in parallel, some conditional, and stitch the results," reach for beads. The day brief is squarely the second kind, which is why that's the piece of mycaminoguide I'm restructuring into a graph while leaving the chat loop alone.

The one-liner I keep coming back to

A loop is temporal repetition. A graph is structural composition. Say that back to yourself the next time an agent feels slow or brittle, and check which one you actually built. Half the time the work was branching all along and the loop was just hiding it.

Beads didn't kill the loop. They gave the loop a boss, something that decides what runs, in what order, and what to do when one piece falls over. My Camino agent is getting one, starting with the day brief.

If you want to follow that rebuild, subscribe at quintonwall.com and come find me on YouTube at @seeqcode, where I'll walk through the day-brief graph once it's live for pilgrims.