AI-Native Software Engineering

Chapter 9. Agent Orchestration Patterns

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 9th chapter of the final book. Please note that the GitHub repo will be made active later on.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

Everything in this book so far has been about working well with a single agent. You’ve learned to engineer its context (Chapter 3), to write specs it can execute (Chapter 6), and to stay in the loop at the right moments (Chapter 2). One agent, steered well, is already a force multiplier.

This chapter is about what happens when one agent is not enough. Real work often outgrows a single context window, a single line of execution, or a single level of intelligence. When that happens, you stop talking to one agent and start designing how several agents work together. That design problem is called orchestration.

Orchestration is not a switch you flip. It’s a set of patterns, each with a cost and a payoff, from which you choose based on the job in front of you. This chapter gives you those patterns and, just as important, the judgment to know when not to reach for them.

This is not a chapter for AI engineers whose job is building agent products. I will not cover ...