Part III: The Model States Intent, the Server Owns the Rest

Give a model a raw SQL tool, an unbounded API proxy or a free-form “run this” tool, and sooner or later it will compose something you would never have approved: a SELECT * over your largest table, three hundred API calls in a loop, a restart in the middle of a deploy. It isn’t malicious. The server handed it a decision the server should have kept.

The four chapters in this part share one rule: the model states intent; the server owns composition, state, limits and consequences. The model says “show me overdue tickets” or “restart checkout”. The server decides which query runs, which calls it makes, how many rows come back, what state survives between calls, how often an action may run, and who must approve it. Each chapter moves one of those decisions to the server:

• Chapter 8: composition over data. The server writes the query.
• Chapter 9: composition over APIs. The server holds credentials and rate limits, and it handles partial failure.
• Chapter 10: state and consequences over time, meaning sessions, approvals and long-running jobs.
• Chapter 11: two complete servers that make all of those decisions at once.

Under every pattern sits Response Shaping, from Chapter 9: return what the question needs, not everything the backend has. A tool that composes exactly the right query and then returns a hundred fields per row has only moved the problem into the context window.

What “pattern” means here. A pattern is a named, reusable split of responsibility between model and server, with its code, the decision it takes over, and the way it fails. It isn’t a recipe to paste. If you can’t name the decision a pattern takes away from the model, you don’t need it yet.