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 →
- “There is a model on a path where the answer was always a dictionary lookup.”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
1 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.
Level 0: the floor you skipped
The Floor Test: the deterministic slice every other rung is measured against, and what it costs to put a probabilistic remote dependency on the path that exists to tell humans things are broken.
Level 3: compounding error is the wrong argument against pipelines
Five stages at 95 percent gives you a 77 percent pipeline — the arithmetic every architecture review repeats. The real Level 3 failure is the opposite: a later stage silently corrects an earlier one, the pipeline is right anyway, and no stage is accountable.
Level 5: a round cannot use a fact it has not received yet
The boundary between parallel tool calling and multi-step reasoning is whether the next query depends on the last one’s result. Get it wrong and your investigator has both halves of the answer in context and still reports that the telemetry does not explain the incident.
Descending: why you cannot delete the idle rung
A case for building the next rung is an existence proof — one reproducible failure closes it. A case for removing a rung is a universal claim over traffic you have not seen yet, and no amount of evidence closes it. That asymmetry is why overbuilt systems stay overbuilt.
Parts still marked in progress are covered in full by the book today — the chapter ranges above are exact. The articles are being written against those chapters.
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.
