FW-03 · Framework
Inference vs Orchestration
Separate the model-serving question from the system question. Governance has to watch both, or it will log tokens and miss the business process.
A model can be right and the operating model can still fail.
Ask an enterprise assistant: “Which of our customers are at risk, and draft actions for the account teams.” In the demo, a paragraph appears. In production, someone later asks which Salesforce records were read, whether the user was allowed to see them, whether ServiceNow tasks were created, and what evidence remains if the answer was wrong.
Those are not model questions. They are process questions. Prompt quality does not answer them.
What happens on a customer-risk request?
The loop starts before any model runs. The system may decide CRM data is required, query Salesforce, pull recent cases from ServiceNow, filter both by the user’s permissions, and only then construct a prompt.
Then the model is called. A paragraph comes back.
The loop resumes. It may notice the answer wants revenue numbers, call another system, invoke the model again, validate the result, format a table, and create tasks in ServiceNow. Creating the tasks is action. Permissions, retries, and the decision to create work at all sit around those calls, not inside them.
That loop has two jobs. The model calls are inference. Everything around them is orchestration:
orchestration → inference → tool call → orchestration → inference → action
The visible chat is a UI. The loop underneath is the operating system. If the room only talks about prompt quality, it is inspecting the smallest part of the loop.
What is inference, and what is orchestration?
The two jobs answer different questions.
| Inference | Orchestration | |
|---|---|---|
| Core question | What does the model answer? | What should the system do? |
| Example | Send a prompt and receive text, a class, a score, or a draft | Choose the model, fetch data, apply permissions, call tools, validate, retry, route, write back |
| Happens where | Model-serving layer | Application and agent layer |
| Typical concerns | Tokens, latency, context window, serving cost | Workflow, state, tools, permissions, routing, retries, memory, evidence |
Inference produces an output: a summary, a classification, a recommendation, or a draft. Useful, and still not the business process.
Orchestration decides the process. It gathers context, enforces entitlements, constructs the prompt, invokes the model, notices what the answer still needs, calls another system, infers again, validates, formats, and, when allowed, commits work.
Agents sit on that loop. That is why they confuse people. A worker-shaped interface can still be a contained inference product. A quiet background job can still be orchestration if it fetches, routes, or writes.
Why do inference-only designs fail in production?
Production is where “the model said so” stops being a sentence anyone will defend.
If the model gives the wrong answer tomorrow, what breaks? If nothing commits and no extra systems were touched, the use case may still be contained inference. If customer records were read, tools were called, or tasks were opened, orchestration is the operating problem whether or not a human clicked once.
Common production friction:
- Tool permissions are wide because the prototype needed to “just work.”
- The prompt is built from records the user was not entitled to see.
- Write-back has no idempotency, so retries double-post.
- The human in the loop has responsibility without policy, evidence, or authority.
- Exception paths were never modeled, so failures become emails.
- Nobody owns the workflow after the build team leaves.
The Enterprise Software Layer Model places inference and orchestration in different layers with different operating rules. AI Governance and Control Layers is the control consequence of the same split.
Why does governance have to watch inference and orchestration separately?
Monitoring inference tells you which model was called, token usage, latency, and sometimes prompt and response content. That is necessary. It is also incomplete.
Monitoring orchestration tells you the business process: which data the system accessed, which tools it invoked, what it decided to do next, and which actions it was allowed to take. If governance only watches the model-serving layer, it can produce a clean token report and still be unable to explain a Salesforce update or a ServiceNow task.
The working test: if the customer-risk workflow is wrong, what evidence proves the organization still followed policy? Prompt logs alone rarely answer that.
What belongs in the orchestration loop?
| Part | What it means | Why it matters |
|---|---|---|
| Context gathering | Fetching records, history, and tool results before or between model calls | Entitlements and systems of record enter here |
| Judgment | The model output itself | Useful, and still not a business action |
| Policy | The rule the business will defend | Without it, a reviewer is guessing |
| Routing | Who or what sees the work next, including another model or agent | Determines cycle time and ownership |
| Tool use | Calls out to CRM, ITSM, finance, or other systems | Data access and side effects begin here |
| Approval | The gate before state change | Matches control to consequence |
| Write-back | Committing an official fact or creating work | Cash, customers, and audit live here |
| Exception | What happens when the path fails | Production is mostly exceptions, not the demo path |
| Evidence | Log of identity, data access, tools, policy, and outcome | Makes review defensible and support possible |
How should leaders classify a use case before scale?
Write one sentence: the system answers or the system does work around answers.
Then walk the sequence:
- Name the business result.
- Name the official object and system of record.
- Name what data and tools the loop may touch before the first model call.
- Name what the model is allowed to judge.
- Name what, if anything, may change as a result.
- Name the approval, write-back, retry, and exception path.
- Name the evidence a reviewer would use next quarter: inference logs and orchestration logs.
- Name the production owner.
If the team cannot complete 3 through 8, keep the use case as contained inference. Contained inference is a legitimate product. Call it that, and stop dressing it as an agent program.
Where do teams mix the chat with the loop?
Is a chat interface orchestration because it feels like a worker?
No. Conversation is a UI. Orchestration starts when the system fetches, routes, calls tools, retries, or commits across systems.
Is the second model call still inference?
Yes. Every model invocation is inference, including the fifth call in a long agent loop. The surrounding decisions remain orchestration.
Is human-in-the-loop enough?
No. A human without policy, evidence, and authority is a speed bump with liability. The loop has to be a designed control, not a screenshot of a person.
Can vendors sell a model answer as if it were execution?
Yes. Suites will market assistants that way. Buyers still have to know which side of the line they are paying for, and which logs they are actually getting.
Where do agent programs break?
- A recommendation becomes action because the tool permission existed, not because the control model allowed it.
- Context is fetched without an entitlement check, so the model sees records the user should not.
- Write-back is assigned to engineering as “the API work” with no owner for the business fact.
- The same case can fire twice and nobody designed for it.
- Reviewers approve a queue they cannot explain.
- Governance watches tokens and never sees tool calls or data access.
- Success is measured by answer quality, not by whether the committed work improved customer effort, leakage, cycle time, or margin.
What should executives and investors inspect?
- Does the use case answer, do work around answers, or both, by design?
- What happens before the first model call?
- Which systems may be read or written in the loop?
- Which system owns the object after the agent runs?
- What evidence covers inference, and what evidence covers orchestration?
- Who supports an exception in production?
- If the model is wrong, what money, customer, or obligation moves?
Framework FAQ
What is the difference between inference and orchestration?
Inference is the act of getting a model to produce an output. Orchestration is the application and agent logic around that call: which model to use, what data to fetch, which tools to invoke, how to validate, when to retry, and what action the system is allowed to take.
When does an AI use case become orchestration?
As soon as the system decides what happens around the model: fetching records, applying permissions, calling tools, routing, retrying, writing back, or creating work. The LLM call is inference. The rest of the loop is orchestration.
Why does AI governance need both inference and orchestration?
Inference monitoring shows model, tokens, latency, and sometimes prompt and response. Orchestration monitoring shows the business process: which data was accessed, which tools ran, what decisions were made, and which actions were permitted.
Practitioner takeaway
Design the loop on purpose. Govern the model call and the process around it. If the room can only talk about prompt quality, the operating model is still a demo.