Mind the Cut: Where Your AI Strategy Quietly Breaks

Tool calls look clean in a demo.

A user asks for something. The model thinks. A browser opens. A database is queried. A spreadsheet is updated. A draft email appears. Everyone smiles, because apparently we now have an “AI agent.”

Then the production version fails for a reason that is somehow both tiny and catastrophic: a tool schema was renamed, a memory field was serialized differently, a retry policy changed, a prompt template compressed one instruction too aggressively, or a guardrail blocked the wrong intermediate step. The model did not become stupid overnight. The architecture quietly moved the steering wheel.

That is the useful discomfort in Tim Sainburg and Caleb Weinreb’s paper, “The Cartesian Cut in Agentic AI.”¹ The paper is not another benchmark race, and it does not claim that one agent framework beats another by 7.3 points on a leaderboard. Thank goodness. Instead, it asks a more structural question: where does control actually live in an AI agent?

For business readers, this is not academic decoration. It is the difference between an AI system that can be monitored through ordinary software controls and one whose decisive behavior has migrated into learned policy, opaque adaptation, and feedback loops that are harder to inspect. The paper’s central phrase, the Cartesian cut, names the boundary between a learned predictive core and the engineered runtime that surrounds it: tools, memory, permissions, retries, stopping rules, schemas, logs, and execution policies.

Most enterprise “agents” are not a single intelligent creature. They are a predictive model coupled to a control machine. The model proposes symbolic traces: text, plans, function calls, JSON arguments, rationales. The runtime turns those traces into consequences. That coupling is powerful. It is also where many strategies break.

The paper’s real contribution is not “agents are fragile”

Plenty of people already know that agents are fragile. Anyone who has watched an LLM confidently call the wrong function twice and then apologize with corporate sincerity has learned this lesson at low speed.

The paper contributes something more useful: a vocabulary for classifying agent architectures by control location. It argues that today’s LLM agents are commonly built through what the authors call Cartesian agency: a learned core, trained largely through predictive objectives on human traces, is retrofitted for control through engineered orchestration.

That phrasing matters. It avoids the lazy explanation that “the model is the agent.” In many deployed systems, the model is only one component in a larger control stack. The orchestration layer decides what context the model sees, which tools exist, what format actions must take, what memory is retained, when the loop stops, how errors are retried, and which outputs are allowed to touch the world.

The paper’s argument can be compressed into three contributions:

That last sentence is the impolite but necessary version: you are not choosing a perfect AI architecture. You are choosing the failure mode you can afford to manage.

Category 1: bounded services keep control outside the model

The first category is the least glamorous and often the most commercially sensible: bounded services, or “boxed cognition.” These systems use AI for planning, analysis, synthesis, verification, monitoring, and recommendation, but they keep actuation authority outside the model.

A bounded service might summarize legal documents, detect anomalies in invoices, draft alternative pricing scenarios, review a compliance checklist, or compare vendor proposals. It can be extremely useful without being allowed to commit funds, change records, message customers, delete files, or execute trades.

In the paper’s terms, control remains predominantly exogenous. Humans, institutions, and explicit software constraints retain the ability to decide, approve, reject, and act. The model is a cognitive scaffold inside a larger control loop.

This sounds boring until one remembers that most profitable software is boring. Bounded services map well to environments where the business value comes from cheaper diagnosis, faster synthesis, or better decision support rather than autonomous execution. A bank does not always need an agent that “does the whole workflow.” Sometimes it needs a system that finds the three suspicious clauses in a 90-page agreement before the associate’s coffee gets cold.

The risk does not disappear. It changes channel.

A bounded system can still influence action through recommendation. A model that cannot click “approve” can still shape what a human believes is worth approving. Bad uncertainty estimates, persuasive but wrong summaries, and user overreliance can leak control through the advisory layer. This is why bounded services should not be treated as “safe by default.” They are safer in one specific sense: direct actuation is limited. Their remaining risk is epistemic and organizational.

For business design, the key question is simple:

If the AI is wrong, does it directly change the world, or does it only change what a human considers next?

If it only changes what a human considers next, bounded service design may be enough. The control problem becomes review quality, calibration, audit trails, user interface design, and organizational incentives. Less cinematic than autonomous agents, yes. Also less likely to set fire to your CRM at 2:17 a.m.

Category 2: Cartesian agents mix model intelligence with runtime control

The second category is the current workhorse: Cartesian agents. These are the systems most companies mean when they say “AI agent.” A foundation model sits inside a runtime. The runtime supplies tools, memory, retrieval, policies, permissions, sandboxes, and loop logic. The model emits structured traces; the runtime parses and executes them.

A simplified version looks like this:

User goal
   ↓
Runtime builds context: instructions + memory + tool schemas + retrieved data
   ↓
Model emits plan / rationale / tool call
   ↓
Runtime parses and executes tool
   ↓
Tool output returns as observation
   ↓
Loop continues until success, failure, timeout, or handoff

This design is powerful because it exploits an asymmetry. Human text and code already contain the residue of human problem-solving. A model trained on those traces can imitate useful procedures without learning every task through physical or business-world trial and error. Then tools compensate for model weaknesses: calculators compute, databases retrieve, browsers search, sandboxes execute code, validators check formats.

That is the upside of the Cartesian cut. It makes agent engineering modular. Developers can add tools, restrict permissions, log trajectories, impose rate limits, inspect action calls, and patch behavior without retraining the model. For enterprise deployment, this is not a small advantage. It is the reason many agent systems can exist at all.

But the same boundary creates the paper’s main warning: control-relevant state must cross a narrow symbolic interface. The model does not directly inhabit the runtime’s control state. It sees whatever has been serialized into text, JSON, function tokens, or context. The runtime does not directly understand the model’s internal uncertainty, attention limits, or latent reasoning dynamics. It sees parseable outputs.

That interface is the symbol bottleneck.

The business version is uglier: your “agent intelligence” may depend on whether a field is called customer_status, client_state, or account_stage; whether memory is summarized before or after tool observations; whether the schema says “reason” or “justification”; whether retry happens after parse failure or after semantic failure. These look like implementation details. In Cartesian agents, implementation details are often control variables wearing casual clothes.

The misconception: more orchestration does not automatically mean more robustness

A common enterprise instinct is to fix agent instability by adding more scaffolding: more tools, more memory, more validation, more retries, more routing, more guardrails, more prompts explaining to the system that it should be careful, preferably in capital letters.

Sometimes this works.

The paper’s more useful point is that it can also deepen wrapper dependence. Every additional runtime component adds a new control surface. The model must understand tool affordances through descriptions. It must condition on memory through serialization. It must respond to feedback through observation text. It must infer when to stop from policies represented outside its own learned dynamics.

More scaffolding can increase reliability when the task is modular, tool outputs are verifiable, and the runtime exposes the right state. It can increase brittleness when the task requires continuous calibration, long-horizon adaptation, or subtle recovery under distribution shift.

The difference is not philosophical. It is operational.

This is where many AI strategies quietly lose discipline. They treat orchestration as a pile of reliability patches. The paper suggests treating orchestration as a control architecture. The distinction is expensive only if ignored.

The paper’s evidence is architectural, not experimental

Because the paper is conceptual, its evidence should be read correctly. Figure 1 is not a performance result; it is a schematic comparison. Its purpose is to make visible the inversion between biological intelligence and many LLM-agent stacks. Biological systems are described as layered feedback controllers where prediction serves action. LLM agents are described as prediction-first systems later coupled to action through a runtime.

Table 1 is also not a benchmark table. It is a design taxonomy. It compares bounded services, Cartesian agents, and integrated agents by control locus, capability upside, and primary liabilities. Its function is to support classification, not to prove that one pathway dominates.

The boxes and glossary play a similar role. They define the components of a Cartesian agent and the relevant vocabulary: predictive core, orchestration layer, execution layer, exogenous control, endogenous control, wrapper sensitivity, symbol bottleneck, safety engineering, and alignment.

So the correct reading is not: “The authors tested three agent types and found the winner.” They did not.

The correct reading is: “The authors provide a control-location framework that can generate better product, governance, and evaluation questions.”

That matters for Cognaptus readers because business mistakes often begin when conceptual papers are treated like empirical proof. This paper does not tell a logistics company, a bank, or a SaaS vendor exactly which architecture will maximize ROI. It tells them what variable they probably forgot to include in the ROI calculation: the cost of locating, monitoring, and repairing control.

Category 3: integrated agents move control inside the learned system

The third category is integrated agents. These systems try to internalize more of the control stack: memory updating, arbitration, uncertainty handling, recovery behavior, action selection, and adaptation from feedback. Instead of depending primarily on external wrappers, the system learns more of the policy that connects perception, decision, and action.

This is closer to the biological contrast used in the paper. Brains do not send JSON tool calls to a separate orchestration server every time posture, breathing, attention, and planning interact. Control is layered, recurrent, and continuously calibrated by consequences. Prediction exists, but it is embedded in action regulation.

For AI, the integrated pathway is attractive when environments are feedback-rich, partially observable, and hard to decompose into clean tool calls. Robotics is the obvious case, but the logic extends to any domain where the system must adapt under disturbance rather than merely execute a known symbolic procedure. Examples might include autonomous lab systems, dynamic cyber-defense agents, high-frequency operational control, or complex multi-step digital workflows where the environment changes as the agent acts.

The upside is tighter intervention calibration. If the system learns when to seek information, when to backtrack, when to stop, and how to update memory from consequences, it may become less dependent on fragile wrapper heuristics.

The cost is equally clear: oversight moves inward.

With a Cartesian agent, some governance levers are exposed. You can inspect tool calls, restrict permissions, change schemas, block dangerous functions, log observations, and impose external stopping rules. With a more integrated agent, more of the decisive behavior may live inside learned representations and policies. The system may become more robust in action while becoming less transparent at the exact points where auditors want handles.

That is not an argument against integrated agents. It is an argument against pretending that increased autonomy is just a feature upgrade. Integration changes the governance surface.

A practical classification map for AI products

The category-based structure of the paper is useful because it can be turned into a product-design map. The categories are not moral rankings. They are regions in a design space.

The practical lesson is not “always choose bounded services” or “integrated agents are the future.” That would be a comforting slogan, and therefore suspicious.

The better lesson is: match control location to the task’s feedback structure and governance burden.

If a task is mostly cognitive and the cost of human review is acceptable, bounded services may dominate. If a task is tool-mediated, modular, and auditable, Cartesian agents are often the right compromise. If a task requires continuous adaptation under feedback, the Cartesian cut may become a performance ceiling, but weakening it raises the price of oversight.

What businesses should audit before scaling an agent

The paper implies a more precise agent-readiness checklist than the usual “does the model pass our test cases?” question. Passing test cases is nice. So is a clean office. Neither proves the building is earthquake-resistant.

Before scaling an agent, a business should map the control stack:

The most neglected item is sensitivity testing. If a small schema change materially changes behavior, that is not merely a QA issue. It is evidence that control is flowing through an unstable interface. The correct response is not always “write a better prompt.” Sometimes it is to redesign the boundary: make the tool contract clearer, separate planning from execution, reduce memory ambiguity, strengthen validation, or move a decision back into a human-controlled loop.

The industry may productize the cut instead of removing it

One subtle part of the paper is its discussion of drift. As tool-using agents are trained more directly on action-outcome feedback, some control logic that previously lived in wrappers can be absorbed into learned behavior. The model may learn tool choice, stopping conventions, recovery strategies, and memory-use patterns from interaction.

From the user’s perspective, the product becomes smoother. The agent feels less like a model bolted onto scaffolding and more like a coherent system. That is good for capability. It may also hide the cut.

The model/runtime boundary does not necessarily vanish. It may move inside the provider’s product. Downstream developers no longer see the scaffolding clearly. They interact with a polished agent interface while the deeper control architecture becomes proprietary infrastructure.

For businesses, this creates a procurement problem. Buying “an agent” from a vendor may mean buying an invisible control stack. The relevant due-diligence questions are therefore not only about model benchmarks, data privacy, or price. They should include:

• What actions can the system take without explicit approval?
• What control policies are externally configurable?
• What logs expose tool use, memory changes, and recovery behavior?
• How are updates to the agent’s internal scaffolding communicated?
• Can customers test wrapper sensitivity across versions?
• Where does vendor-managed control end and client-managed governance begin?

A vendor who cannot answer these questions may still have a powerful product. They just do not have a governable one. Minor distinction. Occasionally fatal.

The boundary condition: this paper is a lens, not a deployment manual

The strongest limitation is also what makes the paper useful. It is a conceptual architecture paper. It does not provide new experiments showing that bounded services outperform Cartesian agents in one domain, or that integrated agents outperform Cartesian agents in another. It does not quantify how much wrapper sensitivity exists across enterprise workflows. It does not offer a formula for the optimal amount of endogenous control.

Those are not flaws if the paper is used correctly.

The paper should be read as a diagnostic lens. It helps teams ask better questions before they invest in the wrong abstraction. It helps explain why two systems using the same foundation model can behave differently in production. It clarifies why adding tools can improve performance and increase fragility at the same time. It separates safety engineering from alignment: external constraints can reduce harm without proving that the learned core has internalized the intended objective.

Where the paper should not be overused is in making categorical predictions. A company should not conclude that integrated agents are always superior because they resemble feedback control more closely. Nor should it conclude that bounded services are always safer because they restrict actuation. Real deployments depend on task structure, environment volatility, audit requirements, institutional incentives, and the cost of human review.

The paper gives the map. It does not drive the truck.

The strategic question is no longer “which model?”

Most AI strategy discussions still orbit the model: bigger model, cheaper model, faster model, open model, closed model, fine-tuned model, agentic model. This is understandable. Models are visible. They have names. They appear on pricing pages. Executives enjoy nouns.

But agentic AI shifts the strategic center from model selection to control placement. The model matters, obviously. Yet in many business systems, the decisive question is whether control sits with the human, the runtime, the vendor’s hidden scaffolding, or the learned policy itself.

That choice determines the practical trade-off:

This is why “AI agent strategy” cannot be reduced to choosing a framework and connecting APIs. The wrapper is not packaging. The wrapper is part of cognition. The runtime is not plumbing. The runtime is part of control.

If a business treats these as secondary implementation details, the system will still make the decision. It will simply make it accidentally.

Conclusion: mind the cut before it minds you

The Cartesian cut is a useful phrase because it names the place where many AI projects pretend nothing important is happening. A model emits a tool call; a runtime executes it; a memory store updates; a policy allows or blocks; a retry loop continues; a human sees a neat answer. Somewhere in that loop, control moved.

The paper’s value is not that it tells every company to build one kind of agent. It is that it makes control location visible enough to debate.

For low-actuation knowledge work, keep control outside the model and design for calibrated human use. For modular workflows, use Cartesian agents, but test the boundary as aggressively as the model. For feedback-rich autonomy, recognize that more integrated control may improve robustness while making governance harder. And when vendors sell a seamless agent, ask where the cut has gone. It may not have disappeared. It may have been politely hidden behind the invoice.

The uncomfortable question for AI strategy is therefore not “how smart is the model?”

It is: who, or what, is steering once the model starts acting?

Ignore that question, and the answer will arrive in production.

Cognaptus: Automate the Present, Incubate the Future.