Inside the Reasoning Core: Planning, Routing, Monitoring

Planning, routing and monitoring get drawn as three boxes with arrows running left to right. They only ever work as a circle, and the arrow that closes it — the one that carries a surprise back into the plan — is the one almost nobody builds.

A system is given a mission that any competent analyst would recognize: reconcile a month of vendor invoices against goods receipts, resolve what can be resolved, and escalate what cannot. It composes a plan, because that is what you do with an objective that spans several systems and cannot be answered in one step. Pull the ledger, pull the receipts, classify the mismatches by type, query the three vendors whose discrepancies look like short shipments, draft credit memos for the ones that clear, hold anything above the approval threshold for a human. Four steps in, a vendor portal returns a document that does not fit the plan at all: the shipment in question was returned three weeks ago and already credited, under a different reference number, by someone who never touched the ledger. The fact is not an error and not an exception in any schema sense. It is simply evidence that the classification made two steps earlier was wrong, and that the remaining half of the plan is now aimed at a problem that does not exist.

What happens in the next few seconds is the entire subject. One kind of system reads that document, extracts the field it was looking for, finds nothing useful, marks the step complete or failed, and proceeds to step five, because step five is what comes after step four. Another kind of system reads the same document and registers something categorically different: the world it planned against is not the world it is now standing in. Up to this moment the two systems were indistinguishable. They made the same plan, called the same tools, produced the same intermediate artifacts, and would have demoed identically. They diverge only at the point where reality contradicts the plan, which is also, inconveniently, the point where most of an enterprise's actual work lives.

A plan is a hypothesis, not a script

The word "plan" carries a confidence it has not earned. In enterprise work a plan is a hypothesis about a world made almost entirely of other people's systems — ledgers updated on someone else's cadence, portals that change their response shape without notice, records that were closed by a human who had a good reason and no obligation to tell anyone. The plan is composed at the one moment the system knows the least it will ever know, from whatever context was available before any work began. It is the cheapest artifact in the whole loop and the one most likely to be wrong, and treating it as an instruction set rather than a starting position is the original error from which the rest of the failure follows. A good plan is not one that survives contact; it is one that is legible enough to be revised when contact goes badly.

Routing looks, from the outside, like the mechanical part — the dispatcher that hands the third step to whichever Specialist Agent owns document extraction and the fifth to whichever one owns approvals. Described that way it is a switch statement with better manners, and if that were all it was, the sequence diagram would be honest. But routing is only trivial when the plan is holding. The interesting routing decisions are the ones made after a step returns something unexpected: whether the vendor query should go to a different source, whether this discrepancy has stopped being a reconciliation question and become a procurement question, whether the right next actor is not an agent at all but a person with authority the system does not have. Each of those is a judgment about what the last result means, not a lookup of what comes next, which is why routing cannot be separated from the thing that reads the results.

That thing is the part the diagram treats as a monitor — a passive dial on the wall, reporting throughput and error rates to whoever is watching. Framed as telemetry, it is genuinely useless to the running mission, because the mission finishes long before anyone reads the dashboard. Framed correctly, it is the mechanism that turns every returned artifact into an Observation with a question attached: does this match what the plan expected to find here? A tool result is data. An Observation is data compared against an expectation, and the comparison is what makes it possible to detect that the expectation has quietly stopped being true. This is why the three things are not stages. Planning produces the expectations, routing acts on them, and the reading of results is what tells you the expectations have decayed — at which point the plan is rewritten, the routing changes, and the loop has gone around once rather than advancing one box to the right.

Orchestration cannot notice that it is wrong

Workflow engines have handled failure for decades, and they handle it well, which makes it easy to mistake their competence for the capability being described here. A workflow encodes failure as a branch: if the API returns 404, take the other path; if the amount exceeds the threshold, route to approval; if the retry budget is exhausted, raise an alert. Every one of those branches represents a failure someone anticipated at design time and drew a line for. The failure that derails a real reconciliation is almost never one of those. It is the credit memo filed under a reference number nobody's schema knows about, the shipment recorded against a subsidiary that was merged last quarter, the perfectly valid response that means something different from what it meant when the integration was written. There is no branch for it, and a system whose entire vocabulary for wrongness is a set of predrawn branches will experience it as success.

This is the distinction that gets flattened when everything with a tool call attached is described as an agent. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, inadequate risk controls, and what the firm calls "agent washing" — existing rule engines and chatbots relabeled without the substance changing underneath. The useful reading of that forecast is not that autonomy is oversold but that the industry has been testing for the wrong property. Buyers evaluate whether a system can act on its own, and nearly everything now can. Almost nobody evaluates whether it can determine, mid-execution, that what it is doing has stopped being the right thing to do. A system that plans, dispatches, and executes without ever asking whether reality matched its expectation is not autonomous in any sense that matters. It is a script with a language model where the configuration file used to be, and it will complete every step of a plan that stopped making sense at step four, confidently, and produce a clean report.

The loop is what makes a human gate worth anything

Revisability is also what rescues Human-in-the-Loop from being theater. A gate placed on a fixed sequence asks a person to approve a step at the moment the system reached it, with whatever context the designer thought to attach, which in practice produces a rubber stamp — the reviewer has no basis to disagree and no signal telling them this instance is unlike the last two hundred. A gate inside a loop that reads its own results is a different object entirely. The escalation arrives because the system detected a divergence between what it expected and what it found, and the thing put in front of the human is not "may I proceed" but "the premise I was working from appears to be false, here is the evidence, and here is what I would do instead." The second question is answerable. It is also the only version of human oversight that scales, because it consumes human attention exactly where the machine's confidence broke down rather than at every checkpoint on a path.

None of this is exotic architecture, and the naming varies across platforms — StudioX calls the layer that holds the objective, composes the plan, dispatches to Specialist Agents and reads their Observations the Reasoning Core, and the whole of the writing gathered in the body of work on the autonomous enterprise circles the same structural point from different industries. What matters is not the label but where the responsibility sits. If the component that decides what to do next is the same one that reads what just happened, an AI Mission can change its mind. If those are separate concerns wired together by a pipeline, it cannot, and no amount of model capability at any individual step will supply the difference.

So the useful measure of a reasoning system is not how many steps it completed or how many tools it can reach. It is how long a wrong plan survives inside it. Give two systems the same mission and the same broken premise, and the one that carries that premise to a tidy conclusion has told you it cannot reason, however sophisticated each step looked along the way, while the one that stops at step four, discards half its plan, and comes back with a different question has told you something far more valuable about what it will do the night it encounters a situation nobody wrote a branch for. Orchestration is measured by what it finishes. Reasoning is measured by what it is willing to abandon.