AI Is the Brain. You Still Have to Build the Backbone.

02 — THE REAL SHAPE OF THE PROBLEM

Two layers, and only one of them is trustworthy

To see why the spine matters, you have to be honest about what a language model actually is inside a production system, stripped of the marketing. It is a probabilistic engine. Given the same input twice it may give you different outputs. Given an adversarial input it may do something no one intended. Given a long enough conversation it will drift, forget an instruction it followed three turns ago, and lose the thread in a way now common enough to have a name: context rot. This is not a defect to be patched out in the next release. It is the nature of the thing. Probabilistic systems are probabilistic.

Most of what goes wrong in enterprise AI comes from a single category error: treating that probabilistic engine as though it were a deterministic component. We are trained by decades of software to expect that a function given the same input returns the same output, that a permission check either passes or fails, that a rule holds every time. Language models break all of those expectations, and then we deploy them into workflows, financial decisions, customer operations, access-controlled data, where those expectations are exactly the ones that must hold. The gap between what the component guarantees and what the workflow requires is where the failures live.

The resolution isn’t to make the model deterministic; you can’t. It’s to stop asking it to be. You let the probabilistic layer do the thing it’s genuinely good at, understanding language, synthesising, drafting, interpreting flexibly, and you build a deterministic layer around it that owns everything that has to be guaranteed rather than merely likely. The model formulates; the spine enforces. The model suggests; the spine decides what’s permissible. That division of labour is the whole game, and the Cisco team’s eight lessons are simply eight places they discovered they had to draw that line.

03 — THE PRINCIPLE

Authority belongs in the deterministic spine

Here is the principle stated as plainly as I can put it, the one thing worth taking away if you read nothing else. In any production AI system, every responsibility that carries consequence, anything a regulator, an auditor, a lawyer, or an angry customer could hold you accountable for, must be owned by deterministic code that the model does not control and often cannot even see. The model’s job is to be helpful within a cage it isn’t allowed to open. The spine is the cage, and building the cage well is the actual work.

Notice how cleanly this sorts the Cisco lessons, and by extension the lessons of every serious production team, into two piles. On one side, the things safe to leave to the probabilistic model: phrasing an answer, summarising a result set, interpreting a loosely-worded request, generating a first draft. On the other, the things that must never be left to it: who is allowed to see which data, whether a claim is true and where it came from, which rule applies, what an internal term actually means, what the system is genuinely capable of doing. The first pile is where the model earns its keep. The second pile is the spine, and the discipline of production AI is knowing, without flinching, which pile each responsibility belongs in.

This reframes the entire enterprise-AI problem away from the question everyone asks, which model is best, toward the question that actually predicts success: how well have you built the deterministic structure around whichever model you rent. That’s a liberating reframe, because it means your system’s trustworthiness is largely in your hands rather than the model provider’s. The rented intelligence is a commodity everyone has equal access to. The spine is yours, and it’s where your real engineering, and your real accountability, lives.

04 — THE SPINE CARRIES ACCESS

RBAC the model never sees

Start with the sharpest example, because it’s the one where getting it wrong is unambiguous and the Cisco team is refreshingly absolute about it: role-based access control cannot be delegated to a language model. Full stop.

The tempting shortcut is to tell the model who the user is and trust it to behave: “this user may see accounts A, B and C; only return data from those.” It reads like it should work. It does not. The model might honour that instruction, or it might not; it might honour it on the first query and forget by the third; it can be jailbroken into ignoring it; it can be confused into leaking data outside the user’s scope by an adversarial input the designer never anticipated. Prompt-based identity is not identity enforcement. And you cannot stand in front of an auditor and explain that your access control “usually” works, because “usually” is another word for “sometimes doesn’t,” and a control that sometimes doesn’t is not a control.

The deterministic answer is to make access control opaque to the model entirely. Before any query executes, code parses it and injects the access-control predicates, the boundaries that limit what can be returned, without the model’s involvement or awareness. The model formulates the query; deterministic code enforces the boundary; the model never makes an access decision and never sees the enforcement happen. This is exactly the pattern the wider 2026 production literature has converged on independently, that permission must be gated on every action in code, tied to a real identity, not asserted in a prompt, precisely because prompt-asserted permission is the single fastest path from “AI pilot” to “security incident.”

There’s a governance subtlety here that the best teams handle well and it’s worth stealing. When deterministic access-filtering removes data, the system shouldn’t silently return less; it should tell the user, “records matching your criteria exist but aren’t visible with your current permissions.” That transparency is itself a spine function, deterministic code explaining a deterministic boundary, and it’s the difference between a user who trusts the system’s limits and one who assumes it’s broken and routes around it. The spine doesn’t just enforce the rule. It owns the honest explanation of the rule, too.

05 — THE SPINE CARRIES TRUTH

Provenance, defaults, and grounded capability

Access is the easy case because the failure is legible. The subtler and arguably more important work of the spine is carrying truth, the integrity of what the system tells the user, which is exactly where a fluent, confident model is most dangerous, because it fails plausibly rather than obviously.

Provenance over confident guessing

When a query returns nothing, a model left to its own devices will say “no data found,” which is worse than useless because it’s ambiguous: does the thing not exist, or does it exist but you can’t see it, or was the query malformed, or is the data simply not loaded yet? Each of those is a different truth requiring a different response, and only deterministic logic that inspects what actually happened, which filter eliminated the rows, whether the filter values even exist in the database, whether access control was the cause, can tell them apart. The Cisco team explicitly forbids their synthesis layer from ever saying “the query returned no results,” and instead has deterministic code diagnose the real cause and explain it. That’s provenance as a spine function: the system knows why, and says so, rather than letting the model narrate a plausible guess.

Defaults over interrogation

The same discipline shows up in how good systems handle ambiguity. Early versions asked users to clarify whenever a request was underspecified, and users hated it, because every clarifying question is another conversational turn where a probabilistic model can derail, and the research the Cisco team cites found roughly a 39% performance drop in multi-turn versus single-turn interactions. The fix was a deterministic precedence rule: proceed with reasonable, transparent defaults, assume “all” for a missing dimension, and only ask as a genuine last resort. The judgment about when to ask was taken away from the model’s instinct and handed to an explicit rule the team controls. Clarification requests fell from over 30% of queries to under 10%.

Grounded capability over imagined capability

And when their assistant suggests a useful next question, those suggestions aren’t generated freely by the model, because a model that doesn’t truly know your system will confidently propose analyses the system can’t perform, hallucinating capabilities and sending users down dead ends. Instead the suggestions are grounded in the system’s actual, known capabilities, constrained by deterministic code to things the system can definitely deliver. The model provides the fluency; the spine provides the guarantee that what’s offered is real. This is the same move as access control and provenance, wearing different clothes: the model proposes, and a deterministic structure decides what’s permitted to reach the user.

06 — WHY THIS EXPLAINS THE FAILURE RATE

The number nobody can shake

Step back from the engineering detail and this principle explains something the whole industry keeps reporting and struggling to account for: enterprise AI has a staggering failure rate that has almost nothing to do with model quality.

The figures have become their own genre. MIT’s research put the share of enterprise generative-AI implementations that fail to meet production expectations at around 95%. Industry surveys through 2026 repeatedly find that the large majority of AI agent pilots never reach production at all, with Gartner projecting that a substantial share of agentic-AI projects will simply be cancelled by 2027, citing unclear value and inadequate risk controls rather than weak models. A reliability study of thousands of production agents across millions of tests found an aggregate success rate hovering around the middle of the range, nowhere near what a business-critical system needs. The models in all these cases were often excellent. The systems built around them were not.

Read through the deterministic-spine lens, the failure rate stops being mysterious. These pilots don’t fail because the model wasn’t smart enough. They fail because teams poured their investment into the model, the exciting, fundable, demo-able part, and neglected the unglamorous spine that actually carries the trust. A demo needs no spine; it runs once, in front of a friendly audience, on clean data. A production system needs the whole skeleton, the deterministic access control, the provenance logic, the grounding, the precedence rules, and building that is boring, slow, and invisible in a slide deck. So it doesn’t get built, and the pilot dies in exactly the gap the Cisco architects named: the gap between a technically impressive demo and an actually useful tool, filled with the unglamorous work most teams won’t do.

The industry keeps diagnosing a model problem and buying model solutions for what is, over and over, a missing-spine problem. You cannot fix an absent skeleton by renting a smarter brain to sit where the skeleton should be.

This is the same structural error I’ve watched play out across every domain I write about. The connected estate breached not because a device was weak but because no one built ownership across the system around it. The AI advantage that turns out to be rented because the enterprise owns the interface but not the learning underneath. The pattern here is identical: the value, and the failure, live not in the impressive component you bought but in the connective, governed structure around it that you had to build yourself and didn’t.

07 — THE GOVERNANCE PROBLEM

Who owns the spine

Which surfaces the question this whole guide has been circling, and the one most organisations have no clear answer to: who, specifically, owns the deterministic spine? Because a spine that belongs to everyone belongs to no one, and that is exactly how it ends up unbuilt.

The trouble is that the spine sits across organisational boundaries that don’t want to share it. Access control is security’s domain. Data provenance belongs to data engineering. The business logic of defaults and capability grounding lives with the product team. The model integration sits with the AI or ML group. Each owns a vertebra; no one owns the spine. And so the guarantees that only make sense as a whole, that a user sees exactly what they’re permitted to see, that every answer is true and traceable, that the system never claims a capability it lacks, fall into the gaps between teams, each of whom reasonably believes it was someone else’s job. This is the same ownership vacuum that swallows so many AI initiatives, transplanted down to the architecture: the parts have owners, the integrity of the whole does not.

There’s a governance point here that goes beyond good engineering, and it’s the one that makes this a leadership issue rather than a technical footnote. The deterministic spine is, functionally, where your AI system meets your accountability. It’s the layer an auditor will actually examine, because it’s the only layer that can be examined, deterministic code enforces rules you can point to, while a model’s behaviour can only be sampled and hoped over. When a regulator asks how you guarantee a customer can’t see another customer’s data, “our access control is deterministic and the model never touches it” is an answer. “The model is instructed not to” is a confession. The spine is not just where the system works; it’s where the system is governable, and that makes owning it a board-level concern disguised as an implementation detail.

08 — THE PRACTICAL BASELINE

Questions to ask of your system

This is the working checklist, organised around the spine, to run against any AI system you’re building or buying before it reaches production.

Access: does the spine own the boundary?

1. Is access control enforced in deterministic code the model never sees, or is the model instructed in its prompt to respect permissions it could be talked out of?
2. Could you show an auditor exactly how a user is prevented from seeing out-of-scope data, as a code path rather than a model instruction?
3. When access filtering removes data, does the system transparently say so, rather than silently returning an incomplete answer the user will trust as complete?

Truth: does the spine own what the system claims?

1. When a result is empty or ambiguous, does deterministic logic diagnose why and explain it, or does the model narrate a plausible guess?
2. Are the system’s suggested actions and capabilities grounded in what it can actually do, or can the model invent capabilities that lead users nowhere?
3. Where the system resolves internal terms, data, or context, does that happen deterministically before the model sees the query, rather than relying on the model to guess correctly?

Ownership: does the spine have a name against it?

1. Is there a single accountable owner for the integrity of the whole spine, or does each guarantee fall between teams who each assume it’s someone else’s?
2. Have you invested in the spine proportionately to the model, or did the budget and the excitement both go to the model while the scaffolding was left as an afterthought?
3. Could your system survive contact with your own auditors, your own security review, and your own worst-case user, or only a friendly demo on clean data?

09 — THE HONEST CLOSE

The moat was never the model

I want to be fair to the model, because this guide has spent nine sections telling you not to trust it, and that could read as dismissal. It isn’t. The probabilistic model is the most remarkable general-purpose tool most of us will build a career on, and the fluency it brings is real and hard-won. The argument here isn’t that the model is weak. It’s that the model is general, and generality, by definition, cannot carry your specific guarantees. A rented, general intelligence gives you the same baseline capability it gives your competitor down the road. What it cannot give either of you is the deterministic structure that makes that capability safe, correct, and accountable inside your particular business, with your data, your rules, your regulators, and your customers. That structure you have to build, and it is the only part of the system that is truly yours.

Which is why the deterministic spine is not a constraint on your AI ambition; it’s the location of it. The teams that will still be running production AI in five years aren’t the ones who chased each new frontier model release. They’re the ones who understood early that the model is a commodity you rent and the spine is an asset you own, and who put their best engineering, and their clearest lines of accountability, into the part that compounds. Everyone has access to the intelligence. Almost no one is doing the unglamorous work of building the structure that makes it trustworthy, and that gap is the whole opportunity.

The intelligence is rented, and it’s the same intelligence everyone rents. The spine is built, and it’s yours. Trust the model with the fluency and nothing else, and put the weight on the skeleton you own.

This is, in the end, the same lesson that runs through everything in this series. The connected estate’s resilience lived not in the device but in the ownership of the system around it. The CISO’s survival lived not in the incident but in the mandate built before it. The enterprise’s real AI advantage lived not in the rented model but in whether it learned from the business around it. And a production AI system’s trustworthiness lives not in the brilliant, probabilistic brain at its centre, but in the deterministic spine you build to carry the weight that brain was never able to hold. Build the model in last. Build the spine in first. And decide, on purpose and by name, who owns the part that everything else depends on, because the day something goes wrong, it’s the spine, not the model, that will be asked to answer for it.

The Deterministic Spine - a working guide to why production AI works only when you stop trusting it with what matters.

The opinions here are a point of view; the guidance is grounded in published engineering write-ups from production AI teams, including Aman Sardana and Dr. Nadhem AlFardan's account of building the Cisco Customer Experience AI Assistant (Cisco Blogs, April 2026), alongside 2026 reliability and failure-rate research including MIT's work on enterprise generative-AI outcomes, Gartner's projections on agentic-AI project cancellation, and independent studies of production-agent reliability and security. Specific figures are directional and current as of 2026; the tooling moves quickly, so treat the deterministic-spine principle as durable and the numbers as a snapshot. This guide is the fourth in a set, alongside Past The Device on securing IoT, Before The Fire on positioning the CISO, and the piece on rented enterprise intelligence: the same thread runs through all of them, that durable value and real accountability live in the governed structure you own, not the capable component you buy.