Enterprise AI Agents

The shelf of books on agents has grown quickly. Most of what sits on it falls into one of two shapes. The first is the vendor tutorial: a framework-anchored tour through a specific platform's SDK, its tool-call syntax, and its reference implementations. These books teach a reader to build something that runs on a particular product, and they age out of relevance the moment the product's next release lands. The second is the academic survey: a treatment of planning algorithms, memory architectures, and benchmark results, written for researchers rather than builders. Both shapes have their place. Neither answers the question an enterprise architect is actually asked.

The architect's question is different. Given a specific enterprise task, a set of systems of record, a governance regime that predates the technology by decades, and a portfolio that will outlive any single vendor, what is the right design? Which tasks warrant an agent at all? Where on the autonomy spectrum should the agent sit? How should its tool surface, memory, and eval be structured so the first version ships, the fifth version still makes sense, and the tenth does not collapse into maintenance debt? These questions do not resolve against framework documentation. They resolve against design principles that survive the next three vendor cycles and the next two pattern fashions.

This book exists to fill that gap. Its subject is the design of enterprise agents as an architecture discipline rather than a platform skill. Its content is principles, not code. Vendors, frameworks, and APIs appear as examples to make principles concrete, not as the substance of the guidance.

The primary reader is an enterprise architect or engineering leader making adoption and architecture decisions. These readers carry responsibility for decisions that cross business units, procurement, compliance regimes, and multi-year roadmaps. They do not need to be persuaded that agents are interesting; they need a principled framework for deciding which agents to build, how to design them, and how to operate a portfolio of them over time.

The secondary reader is a senior engineer or technical lead building an agent. This reader is closer to the implementation than the architect and farther from the portfolio. The principles still apply. The chapters on decomposition, tool design, memory, and eval speak as directly to a tech lead framing the second iteration of an agent as they do to an architect framing the first build decision.

The book assumes its readers know what a large language model is, can reason about distributed systems, and have shipped production software. It does not assume agent-specific prior experience.

Large language model and machine learning fundamentals are not covered. Transformer internals, training procedures, and model benchmarks belong in texts written for that purpose. Prompt engineering basics are not covered for the same reason.

Vendor and framework tutorials are not covered. Specific products are referenced only as examples, and the book asks the reader to retain the design reasoning behind each example. Consumer agent use cases — chatbots, NPCs, and personal assistants — are not covered. Model training and fine-tuning are treated as capabilities to use rather than disciplines to teach.

The book commits to principles and treats specifics as examples. Vendors will come and go, frameworks will merge and deprecate, and APIs that are canonical today will be legacy in three years. What survives is the reasoning. Whether an agent is the right architectural response to a task does not depend on which framework is current. A reader who internalises the principles and adapts the examples will still be making sensible architecture decisions three vendor cycles from now.