Thinking in Agents: A Short Guide to Building Systems out of AI Agents

Most teams meet AI agents the same way. Someone builds a demo in an afternoon; it looks like magic, and everyone starts imagining where it could go. 

Then the team tries to put it into production and runs into questions the demo never asked. What exactly is this thing supposed to do? How will we know it's doing it? What happens when it does something different tomorrow? Who is accountable when it's wrong?

Those questions point to a real shift. Agents are a different kind of building block, and the habits we've developed over 50 years of building software only partly apply. 

This short guide, readable in about an hour, explains which habits need to change. It's written for architects, engineering leaders, product owners and developers who are being asked to build or approve systems that include AI agents and want a clear mental model before they commit time and budget.

Inside, you'll find:

• A working definition of an agent and a look at its parts: the model, persona, tools, memory, reviewers and guardrails
• A comparison of traditional and agent-oriented system design, plus the orchestrator, loop and peer network patterns and how to choose among them
• A practical approach to writing requirements for output that varies, using behaviors, boundaries, success rates and test sets in place of exact expected values
• A worked example that follows a warranty claims system from the first business conversation to a running solution with a human in the loop
• An overview of emerging methods, including an adaptation of Behavior-Driven Development, evaluation-driven development and risk-tiered autonomy
• Guidance for systems that must be deterministic, including where agents fit and where ordinary code should take over

Four ideas run through every chapter. 

Agents have a persona designed to deliver a particular outcome. 

They can run in parallel or as a network of peers, so you have to reason about how the whole system behaves when no single component is in charge. 

They're non-deterministic, so requirements have to account for variation. 

And some systems demand exact outcomes, which means knowing where agents belong and where code should make the call.

One technique recurs throughout: the second look. Instead of trusting a single response, you ask again, in a different way, whether the first one is any good. It works as a guardrail and as a source of confidence in a system that can't promise identical answers.

The guide closes with a one-page checklist you can take into your next design review.