The Orchestrator

Look back at the components in Section 3.9 — directives, skills, context, memory, tools, communication, learning — and a distinction appears that will matter for the rest of this book. Some of the parts are deterministic in intent: a permission check either grants access or it does not. A validation script either accepts the payload or rejects it. A health check either confirms the failure conditions or it does not. Scripts, schemas, permission envelopes, test runners, gate logic — conventional code reduces interpretation variance and can be tested under specified inputs and conditions, which is why they can be trusted to hold a boundary. They are not perfectly identical on every run — time, I/O, concurrency, dependencies, and external systems can still change a result — but their behavior does not depend on an inference engine’s judgment about what the rule meant.

Other parts are nondeterministic. The model interpreting a request, drafting a response, judging whether the evidence is sufficient, deciding which tool to call next — handed the same input twice, these can produce different outputs. That is not a defect to be fixed; it is the nature of statistical inference, and it is where most of the capability lives. But it means the parts of the system doing the interpreting and the proposing cannot also be the parts trusted to do the checking.

Knowing which parts of your system are which — and being right about it — is a core orchestrator skill. You do not ask a deterministic part to be flexible, and you do not ask a nondeterministic part to be reliable. The dependable arrangement pairs them: the nondeterministic parts interpret, propose, draft, and judge; the deterministic parts validate, gate, enforce, and record. A model can propose a routing change; a script confirms the failure conditions before anything ships. Chapter 8 takes up what it means to live with that nondeterminism at length.