The mental models you use for distributed systems, queues, and workflows apply directly to building systems around language models.
This might seem optimistic. The systems we’re talking about—AI assistants that remember conversations, agents that take actions in the world, applications that update their behavior based on past interactions—feel different from the software you’ve built before. There’s a temptation to think that working with large language models requires a new discipline, perhaps a new kind of engineering intuition altogether.
You already know the building blocks required to construct these systems.
You know how to store data and retrieve it later. You know how to route execution based on conditions. You know how to coordinate components that work on shared state. You know how to build systems that run on schedules, wait for external input, and maintain consistency across failures. These patterns are behind databases, web applications, distributed systems, game engines—behind most of the software that actually runs.
These same patterns, arranged around a language model, produce intelligent behavior.
The model is a new primitive. A function that takes text and returns text, but one that can follow instructions, reason through problems, and decide what to do next. What’s not new is the engineering. The system design principles that make software useful and reliable don’t change because one of your components can reason. The same computational concepts you use for problem-solving in other domains apply here: state, control flow, scheduling, and coordination.
Current discussions of these systems often emphasize tools and frameworks but underplay the underlying system design principles.
Imagine you want to build a virtual office—a system where tasks arrive in a backlog, AI workers claim and complete them, and some decisions require human approval before proceeding. The system should run on its own schedule, checking for new work every few minutes, whether or not anyone is watching.
You can picture how this should work. You’ve built systems with task queues before. You’ve written scheduled jobs, coordinated workers, implemented approval flows. The components—task queues, schedulers, workers, and approval flows—are the same as in systems you already build.
But when you sit down to build it with a language model, the path forward isn’t clear. You need to decide how workers maintain context about what they’re doing and where their memory lives between tasks. Some workers must wait for human input while others continue, and you have to coordinate their efforts on shared documents. You also need clear criteria for when a worker is autonomous versus just responding to requests.
These questions lack standard answers because the field does not yet have a shared vocabulary for these design choices. The industry has frameworks and tools, but not principles. Many guides show how to wire up tools and prompts, but they rarely explain how state, scheduling, and coordination interact.
This book provides that understanding. We’ll develop a systematic way to think about intelligent systems, grounded in computational concepts you already know. By the end, the virtual office won’t seem mysterious. You’ll see exactly what state it needs, how information should flow, and what patterns produce each capability.
We explore ten elements that make systems appear intelligent: Context, Memory, Agency, Reasoning, Coordination, Artifacts, Autonomy, Evaluation, Feedback, and Learning.
Each element names something you recognize in capable AI systems. For each element, we analyze concrete behaviors and then implement them step by step in code. Each chapter starts from a concrete example, analyzes what is happening, and then derives patterns you can implement.
The examples use Idyllic, a TypeScript runtime chosen to keep syntax overhead low and focus on system behavior. But the ideas aren’t bound to any technology. The patterns apply to whatever language you write, whatever framework you choose, whatever system you eventually build.
The scope of this book is narrow by design.
This is not a book about machine learning. We treat the model as a black box API that accepts text and returns text, without covering its internal architecture. You don’t need to understand transformers, attention mechanisms, or training procedures.
This is not a book about prompt engineering. Prompts matter, and we’ll discuss them, but the hard problems are elsewhere: what state to maintain, how information flows, how to coordinate work across interactions. With a clear architecture that manages state and data flow, prompts typically focus on describing tools and constraints rather than compensating for structural gaps.
This is not a book about AI personas in simulated conversation. We’re building systems with explicit information flow, clear state management, and well-defined coordination—the same rigor you’d apply to any distributed system.
We begin with context, the model’s entire universe for each reasoning step.