Most teams don’t decide to build AI-native applications. They add one LLM feature, then another, then an agent — and one day discover their tidy request/response architecture is hosting components that don’t behave like services at all. The retries retry the wrong things. The tests can’t pin down outputs. Nobody can say what the system will do with a prompt it hasn’t seen.
This series is the architecture layer for that moment. Eight parts, written as one argument. It covers what changes when a reasoning model becomes a first-class component, and the decisions — context, memory, coordination, time, oversight, governance — that separate systems that survive production from demos that don’t.
This page is the map: what each part answers, the order they argue in, and where to start depending on what you’re building.
- AI-native is an architecture property, not a feature count: non-deterministic, stateful, probabilistic components break instincts built on deterministic services — Part 1 resets the mental model.
- The eight parts form one arc — paradigm → inputs → state → coordination → time → oversight → governance → judgment — and each is a decision you’ll face roughly in that order.
- You don’t need all eight today: the reading paths below map shortcuts by role, and every part links down to hands-on tutorials when you’re ready to build.
Why AI-Native Applications Break Your Architecture Instincts#
Two decades of service architecture trained us on a contract: same input, same output, stateless between calls, failures you can enumerate. AI-native applications void that contract. A model component is non-deterministic — same input, different output. It is stateful in effect — what it saw earlier changes what it does next. And it is probabilistic — usually right, a category classic error handling doesn’t have.
That doesn’t mean old instincts are worthless — idempotency, observability and least privilege matter more than ever. It means each one needs rethinking before it transfers. Even Anthropic’s guidance on building effective agents lands on the same theme: simple, composable patterns beat imported complexity.
Bottom line: AI-native applications don’t need new engineers; they need engineers willing to re-derive their defaults.
The Arc: Eight Decisions, One Argument#
Foundations — the component and its inputs and state:
- Part 1 · AI Agents vs Microservices — the paradigm shift. Why an agent is a different runtime contract, not a smarter microservice, and which architecture instincts still hold.
- Part 2 · Context Engineering Architecture — the inputs. The context window as RAM you assemble on a budget, and the failure modes that hit before the window is even full.
- Part 3 · AI Agent Memory Architecture — the state. What lives in storage versus the window, and why the hard work is recall and forgetting, not storing.
Coordination and time — when one agent becomes a system:
- Part 4 · Agent Orchestration Patterns — the coordination. Five patterns from supervisor to swarm, with a “skip this if…” for each; multi-agent as org design, not extra intelligence.
- Part 5 · Long-Running AI Workflows — the time dimension. Durable execution: resume, don’t restart, when work outlives the request.
Trust — the parts that make it shippable:
- Part 6 · Human-in-the-Loop Architecture — the oversight. Calibrated autonomy: gate the risky actions, not every action, before approval fatigue becomes a security bug.
- Part 7 · AI Control Plane Architecture — the governance. Identity, policy, observability, cost and audit — the layer that turns a pile of agents into a system you can defend.
- Part 8 · Agent Mesh vs Supervisor — the judgment call. The contrarian finale: why open agent meshes are losing to bounded supervision in production, and which patterns are cargo cult.
The order is the argument. Parts 1–3 make a single agent competent, 4–5 make several agents a system, 6–8 make that system something you can put in front of customers, auditors and a budget.
How to Read the Series#
| You are | Start at | Then |
|---|---|---|
| An architect evaluating the whole space | Part 1 | Read straight through — it’s one argument |
| Already building; answers come back wrong | Part 2 | Part 3 for anything that must persist |
| Wiring multiple agents together | Part 4 | Part 5 once work outlives a request |
| Facing compliance, approvals or runaway cost | Part 6 | Part 7 for the governance layer |
| Skeptical of the multi-agent hype | Part 8 | Part 4 for what to do instead |
Bottom line: read front to back for the argument, or jump to the row that describes your week.
Patterns Here, Implementations Next Door#
This series stays at the architecture level on purpose — patterns, trade-offs, decision criteria, mostly language-agnostic. The hands-on layer lives in our AI Engineering section, and every part links down to it at the moment you’d want code.
Start with what AI agents are and what RAG is for the concepts. Reach for the agent framework comparison when you’re choosing tools, and the build-series tutorials for working Python. Read the pattern here, build it there — neither post wastes your time repeating the other.
Bookmark this hub rather than individual parts — it’s the one URL that always reflects the current shape of the series, and the reading-path table above is the fastest route back in.
Eight decisions, one argument: AI-native applications reward architects who re-derive their defaults instead of importing them. Start where your system hurts.
- Start the argument: Part 1 — AI Agents vs Microservices resets the mental model everything else builds on.
- In pain right now? Jump via the reading-path table above — every part stands alone.
- Want code instead of patterns? Begin with What Are AI Agents? and the tutorials it fans out to.
