Chains, graphs, and the multi-agent temptation.
Everyone is quoting agentic design patterns this month. Notes from actually building with chains and graphs — and why multi-agent should be earned, not assumed.
🕸️ Chains, graphs, and the multi-agent temptation.
Agentic workflows are having their moment — Andrew Ng's design-pattern series (reflection, tool use, planning, multi-agent collaboration) is being quoted in every AI conversation I'm in, along with his observation that a weaker model wrapped in a good agentic loop can outperform a stronger model prompted once. Having spent the past months moving our own systems from simple chains toward graph-based orchestration, some ground-level notes on what these words actually mean in production:
A chain is a conveyor belt. Prompt → retrieve → prompt → format. Fixed sequence, one direction. LangChain made this pattern almost free to build, and for a real class of problems — summarise this, answer from these documents — it is all you need. Our first production systems were chains, and the discipline they impose (every step explicit, every hand-off visible) is underrated.
Chains break where real work loops. Draft, check, revise. Retrieve, judge relevance, retrieve again differently. Ask a human when unsure, resume when answered. Force these into a chain and you get nested if-else spaghetti pretending to be a pipeline. This is precisely what graph orchestration (LangGraph being the tool we reached for) fixes: nodes for steps, edges for decisions, cycles allowed, and — the part I now consider non-negotiable — explicit state that travels through the graph, so at any moment you can answer "what does the system currently believe and why?"
The design insight that mattered most: decide where the LLM is allowed to think. Our better graphs use the model only at genuine judgment nodes — is this retrieval sufficient, does this draft meet the bar — and plain deterministic code everywhere else. Every unnecessary LLM node is added cost, latency and variance. The craft is not "add more intelligence"; it is placing intelligence precisely.
On multi-agent: it is the pattern everyone wants first and needs last. A "team" of agents debating sounds like the future; in practice it is the hardest thing on Ng's list to debug, evaluate or trust. What we found: most problems that look multi-agent are really one well-designed graph — the "reviewer agent" is a reflection node, the "researcher agent" is a retrieval branch. Genuine multi-agent earns its complexity only when roles need different tools, permissions or context that must not mix. Separation of duties is an architecture reason. Vibes are not.
And a human is a node, not an afterthought. The single most valuable edge in our graphs is the one that routes to a person — with state checkpointed, so the workflow pauses and resumes rather than dies. If your orchestration framework makes human-in-the-loop awkward, it is optimising for demos.
The leadership translation of all this gyaan: when a team proposes an "agent," ask to see the graph. Which nodes think, which nodes act, where it loops, where a human sits, what state it carries. A team that can draw that picture is building a system. A team that cannot is building a demo with extra steps.