Introducing the AI Architecture Casebook, a series on real-world AI design decisions
The system around the model
For years, my work has been about how systems talk to each other: who is allowed to call what, where trust is decided, what happens when a dependency fails, and what every call costs. Those questions shaped how I think about any system before a single line of code is written.
When I started working with AI, I noticed how often those questions go unasked. Permissions end up written into prompts. Costs grow with no budget. Answers ship with no way to tell whether they’re right. The model gets all the attention, while the system around it, where most failures actually happen, gets very little.
I’m not the only one noticing. In everyday conversations with friends and colleagues from different companies, AI scenarios keep coming up that made the people who designed them stop and rethink. Nobody has all the answers yet. Everyone is learning, me included. And each time, I catch myself asking the same question: what would I do in this situation?
This series is my answer to that question, one problem at a time. Each post takes a real-world AI scenario and works through it the way I’d approach any design: what must never go wrong, which options exist, what each one costs, and which trade-offs I’d accept. I record the decisions as architecture decision records, including the options I rejected and when I’d revisit them.
The companies and people in these stories are made up. The problems are very real. To keep each case study readable, I simplify on purpose: one company, a few rules, a clear scope. Your real systems are probably messier, with more roles, more exceptions and more history. Where a simplification would change the design at a larger scale, I’ll say so. If you’ve faced something similar, or you’d design it differently, I’d like to hear it in the comments. Learning together is the point.
Top comments (0)