The Short Answer
A Ness Digital Engineering survey published in August 2026 found 99% of companies plan to put AI agents into production while only 9-14% have fully done so. The blocker is not model capability — it is that agents need a machine-readable model of how work actually happens, including authority, exceptions, and systems of record, which most organizations have never documented. On ibl.ai you own all the code and the data, including that model of your own operations.
The gap between intention and production is not evidence that agents do not work. It is evidence that the prerequisite for agents is organizational, and it was skipped.
What does the 99% versus 9% figure actually measure?
The figure measures the distance between planning to deploy AI agents and having them fully in production, and the two numbers come from the same survey.
Ness Digital Engineering reported that approximately 99% of companies plan to put agentic AI into production, while only about 9-14% have fully done so.
The report characterises the space between proof of concept and production as "Death Valley," and links the stall to a lack of visible change and to trust in probabilistic systems.
Two things are worth reading carefully. The 99% is intent, not deployment — it says the category has universal executive buy-in, which is a different claim from universal adoption.
And the production figure is a band rather than a point, because "fully in production" is judged differently across organizations.
What survives both caveats is the shape: near-total intent, single-digit-to-low-teens completion.
Why is model capability rarely the real blocker?
Model capability is rarely the blocker because the pilot already proved capability, and the pilot is what got the project funded.
Organizations do not reach Death Valley because the model could not summarise the document or draft the reply. They reach it because the demo ran on a curated happy path, and production is mostly exceptions.
There is also a category error underneath the enthusiasm. A retrieval chatbot needs documents; if the corpus is indexed, it works. An agent needs to act, and acting requires knowledge the document corpus does not contain:
- Who is authorised to approve a refund above $500, and who approves it when they are on leave
- Which system holds the authoritative customer record when the CRM and the billing platform disagree
- What the correct behaviour is when a contract is missing a renewal date
- Which exceptions require a human, and who that human is at 2am
None of that lives in a document store. It lives in the working memory of the people who have been there longest.
What is the prerequisite most organizations skipped?
The prerequisite is a machine-readable model of how the organization actually works — its entities, their relationships, the authority structure, and the exception paths.
This is an ontology problem, and the word matters because it names something more specific than "documentation." An ontology defines what a customer is in your organization, how a customer relates to an account and an entitlement, which attribute is authoritative when two systems disagree, and what states a case can legally occupy.
An agent executing a refund needs all of that to be true and reachable at runtime. A chatbot answering "what is our refund policy" needs none of it.
That asymmetry is the whole explanation for the deployment gap. The chatbot generation of projects succeeded without touching the underlying model of the business. The agent generation cannot, and the work was never budgeted because the previous wave did not require it.
We work through how to construct one in how to build an organizational ontology, and the distinction from a document-retrieval approach in ontology versus RAG.
Why does this make ownership of the platform a strategic question?
Ownership becomes strategic because the model of how your organization works is the most valuable artifact the deployment produces, and it is far more durable than any model you run against it.
Mapping authority, systems of record, and exception handling is months of work involving the people who understand the business best. What comes out is, in effect, an executable description of your operating model.
If that description lives inside a vendor's platform in a proprietary format, you have encoded the most sensitive institutional knowledge you have into something you cannot export, inspect, or take with you. The frontier model you use will be replaced within the year.
That ontology will outlive several of them.
The cost shape compounds the exposure. Per-seat licensing at roughly $30–60 per user per month charges by headcount while agent workloads scale with process volume, so the bill grows on an axis unrelated to the work being done — and it grows on top of an asset you do not own.
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
How do you actually get an agent across Death Valley?
You get an agent into production by choosing a process narrow enough to model completely, then modelling the exceptions rather than the happy path.
Pick one process with a real owner. Not a department. One workflow, with somebody accountable for its outcome who can adjudicate the ambiguous cases.
Write down the exceptions first. The happy path is the easy 20%. Start from what goes wrong, because that is where the authority rules and the systems-of-record conflicts surface.
Resolve the system-of-record question explicitly. For each entity the agent touches, name the authoritative source. Unresolved, this reappears as a production incident rather than a design decision.
Instrument before you scale. Log every action with its inputs and its justification. This is the audit trail governance will require, and it is also how you find the failure modes the pilot never met.
Then widen. A second process on an established ontology is a fraction of the cost of the first, because most of the model is already built. This is why the first deployment feels disproportionately expensive and the fourth feels cheap.
The complementary read on why budgets rise while deployment does not is in AI budgets are growing 40% a year, deployment isn't.
Frequently asked questions
Is the 99% figure about agents in production?
No. It measures companies that plan to put agentic AI into production. The production figure from the same survey is 9-14%, and conflating the two overstates adoption considerably.
Does this mean AI agents are overhyped?
Not exactly. It means the prerequisite work is under-scoped. The organizations in the 9-14% are generally not running better models — they did the process modelling the others deferred.
How long does building an organizational ontology take?
For a single well-bounded process, weeks rather than quarters. The cost is concentrated in the first one; subsequent processes reuse most of the entity and authority model.
The bottom line
Universal intent and single-digit delivery is not a story about disappointing models. It is a story about a prerequisite that the previous wave of AI projects did not have and this one does.
Agents act, and acting requires knowing how your organization actually works — in a form a machine can execute. Write that down, own it, and the deployment stops being the hard part.