Guides · Series · 5 parts
Choosing a GenAI Architecture
There are eight architectures and seven boundaries between them. Every boundary is a yes-or-no question about the task — not a judgment call about the design.
The book
The 7 GenAI Architectures
A Field Guide to Choosing the Right AI System — Before You Overbuild It
The seven architectures GenAI systems actually get built on, what each one is genuinely for, and how to pick the smallest one that solves your problem.
The decision nobody has a procedure for
Three weeks into building an autonomous agent, someone in a design review asks a reasonable question: what would have to be true for a workflow to be insufficient here? The room goes quiet — not because the question is hard, but because nobody has a way to answer it. There is no shared name for the alternative, no property of the task that would settle it, and no artifact anyone can point at. After a pause someone says the workflow would be "too rigid," someone else says the inputs are "too varied for a fixed pipeline," and the review moves on. The agent ships.
What makes that moment expensive is not that the team picked wrong. It is that the team had no procedure that could have picked right, so the decision defaulted to whoever spoke with the most conviction. The result is the most common failure mode in GenAI engineering, and it is not a modelling failure: systems over-engineered for their actual problem, autonomous agents built for tasks a prompt template would have solved, multi-agent orchestration added before the single-agent case worked reliably.
The fix is unglamorous. There are eight architectures — a deterministic floor plus seven that involve a model — and therefore seven boundaries. Each boundary is a yes-or-no question about the task, not a judgment call about the design. A team that can answer all seven knows what to build. A team that cannot has not yet understood the problem well enough to build anything at all, and the most useful output of a design review is often that finding.
Why this series covers four rungs and not eight
The rungs are not equally written about. Retrieval, tool use, and autonomous agents have had years of attention, and this site already has deep-dive series on each: RAG Engineering in Production for Level 2, the MCP and tool-use articles for Level 4, Harness Engineering and the AI Control Plane for Levels 6 and 7. Part 1 maps the whole ladder and links out to those.
The rungs nobody writes about are the ones you pass on the way up without stopping. Level 0 — the deterministic floor — is skipped because "unstructured input" gets read as "needs a model," which is how a dictionary lookup becomes a probabilistic remote dependency on your incident-paging path. Level 3, the LLM workflow, gets dismissed as too rigid on the strength of a compounding-error argument that turns out to describe the wrong risk. Level 5, multi-step reasoning, is invisible as a distinct rung at all, so teams jump from parallel tool calls straight to an autonomous agent and pay for autonomy they never needed.
And then there is the direction nobody goes. Climbing a rung has an artifact — a reproducible case the current architecture could not handle. Descending has none, which is why the rung your own metrics say is idle is still in production. The last part is about that asymmetry.
Which part solves my problem
The series reads in order, but if something is already broken, start here.
- “I cannot say what would have to be true for a simpler architecture to be insufficient.”Part 1 →
- “My router has a catch-all branch and I cannot say what share of traffic hits it.”Part 2 →
- “We ruled out a fixed pipeline because errors compound, and never measured whether they do.”Part 3 →
- “My tool-calling system misses the one query that depended on another query’s result.”Part 4 →
- “A rung in my system answers nothing additional and I still cannot get approval to delete it.”Part 5 →
The series
5 of 5 published
The 7 GenAI Architectures Every AI Engineer Should Know
Eight architectures, seven boundaries between them, and a decision procedure for each - so the choice stops defaulting to whoever in the design review spoke with the most conviction.
Why Your Default Branch and Your LLM Are the Same Architecture
Both answer every input. Neither is required to tell the caller which answers it invented. Until one of them is, every argument about climbing is an argument about taste.
Five Stages at 95 Percent Is Not 77 Percent
The compounding-error arithmetic is computed for the option it is used to reject, and never for the one it authorises. That is what makes it useless.
A Round Cannot Use a Fact It Has Not Received Yet
Every tool-calling schema obligates a literal value for every argument it declares. When that value depends on a fact only a sibling call's result can supply, the model does not fail to reason - the round fails to have it.
Descending: Why You Cannot Delete an Idle AI Agent Layer
Adding a layer is authorized by a proof. Removing one is authorized by a hope with a chart attached - and the chart cannot tell the difference between a layer nobody needs and a layer nobody has needed yet.
The companion code
The book rebuilds one system — an incident triage assistant — at every rung of the ladder, so the comparison between architectures is measured rather than asserted. The repo ships that system at each level, with the token counts, latencies, and failure cases reproducible locally.
View the companion repository on GitHub →Other guide series
Agentic AI with LangGraph
An eight-part guide to the part of agent engineering nobody demos: making the thing survive a restart, a concurrent write, a bad tool call, and a Tuesday deploy.
Harness Engineering
AI systems do not fail at the model layer. They fail in the code around it — and that code is a designable layer with its own architecture.
RAG Engineering
Most RAG failures happen upstream of the LLM, accumulate invisibly, and only surface as an incident. This series names each one.
Claude Code Playbook
Claude Code has four layers — context, skills, subagents, hooks — and the variable that decides which one you need is enforceability, not capability.
AI Control Plane
A fleet of agents needs a layer that is not itself an agent — observability, policy, orchestration, versioning, cost, and audit, built as infrastructure.
Agentic AI in the Data Center
In physical infrastructure, an agent’s autonomy is capped by reversibility and jurisdiction — not by how good the model is.
Codebase to Architecture Doc
A three-pass methodology for compressing any codebase into validated diagrams and decisions — and then a LangGraph pipeline that runs it for you.
