Your AI Isn't Underperforming. Your Business Context Is.
Updated: 1 day ago
Somebody turned the AI on last quarter. A Zia agent for support triage, maybe predictive scoring on the lead pipeline. The demo was convincing. Six weeks later, nobody can point at a number that moved.
The instinct is to blame the model. It is almost never the model.
At Zoholics 2026 in Houston this May, Zoho chief strategy officer Vijay Sundaram put it in one sentence: “AI isn’t underperforming because the models aren’t powerful enough. It’s underperforming because the business context those models rely on is fragmented, ungoverned, and invisible to the systems meant to act on it.” In a session the same week, Zoho’s head of applied AI told the room that companies are “torching budgets on AI.”
Gartner reads it the same way from outside the ecosystem. In June 2025 it predicted that more than 40% of agentic AI projects will be canceled by the end of 2027 — on escalating costs, unclear business value, and inadequate risk controls. Note what is not on that list: model capability.
Zoho’s own adoption figures show the same gap in miniature. As of Zoholics 2026, 9,000 customers had signed up for Zia Agents, 19,000 agents had been created, and 13,000 had been deployed. Roughly a third of everything built never went into service.
That gap between built and running is what this post is about — and what an AI readiness assessment should actually be measuring.
An AI readiness assessment is a data and process audit in a better suit
Most AI readiness assessments score you across strategy, talent, culture and infrastructure, then hand back a maturity level. That makes a fine board slide. It does not tell an operations manager what to fix on Monday.
For a business running Zoho One, the readiness question is narrower and far more answerable: can the systems this agent is about to read from actually answer the question it is about to be asked?
Four things decide that. Data hygiene. Documented process. Permissions. And one party accountable for all three. None of them are interesting. All of them are the difference between an agent that saves a team four hours a week and one that produces confident nonsense at speed.
What actually breaks inside Zoho when the foundation is thin
The failure modes are specific, and they stop being mysterious once you have seen a few of them.
Zia scores the records you have, not the records you meant to have
Predictive lead scoring learns from your closed-won and closed-lost history. If Industry is blank on 40% of Accounts, if Lead Source has been a free-text field since 2022, if a third of last year’s Deals were closed by an admin doing bulk cleanup on the final day of a quarter — that is the pattern Zia learns, and it will score against it without hesitating. Zia’s predictive scoring and manual rule-based scoring answer different questions, and the strongest setups use both deliberately. But both degrade on exactly the same input problem: fields that are optional in practice and therefore blank in bulk.
Workflows fire on fields nobody owns
A custom picklist gets added for one campaign. The campaign ends. The field stays, half-populated, and nobody was ever assigned to maintain it. Two years later a workflow rule still fires on it, generating tasks into a queue an agent now reads as signal. The output is wrong and nothing errors. That silence is the real problem — a broken integration raises an alert, a decayed field does not. Validation rules stop bad data at entry while approval processes put a human in front of a decision; which one a field needs depends on whether you are preventing an error or reviewing a judgment call. Most estates have neither on the fields their agents depend on most.
Agents reason across duplicate accounts as if they were separate businesses
Ask an agent what your exposure is with a customer that exists three times in CRM — once from a trade show import, once from a storefront sync, once typed in by a rep — and you get a third of the answer delivered with the confidence of a whole one. A human looking at that screen notices the duplicates. An agent summarizing four hundred records does not, and nothing in its output tells you it missed two-thirds of the relationship.
The agent inherits somebody’s permissions
An agent acts inside a security context, and that context comes from the access model you already have. In Zoho CRM, roles set how far a user can see and profiles set what a user can do. Estates that have grown for five years usually have a role hierarchy that no longer matches the org chart and two or three profiles that were cloned once and never revisited. Point an agent at that and it will summarize across records a person in that seat would never have been shown. This is where “inadequate risk controls” stops being a Gartner phrase and becomes a specific setting in your setup panel.
The middle layer, in four parts
Data hygiene. Not a one-off cleanup project. Deduplication rules that run continuously, fields that are required at the stage they matter rather than required always, picklists instead of free text on anything you will later want to group by, and a named owner for each. A cleanup that is not maintained decays back to roughly where it started inside a year.
Documented process. An agent can only act on a process somebody has decided. Sundaram’s point at Zoholics was that institutional knowledge lives in three places: systems, documents, and people’s heads. Only the first is legible to an agent. Where the real process lives in the third place — the rep who knows which discounts actually get approved — the agent has nothing to reason over, so it produces a plausible invention instead.
Permissions. Decide what an agent is allowed to see and change before deciding what it should automate. That means a deliberate role and profile model and a named security context per agent, rather than whatever access the person who built it happened to hold.
Accountability. Somebody has to be answerable for all three, continuously, after the project closes. This is the part most estates never assign, and it is why readiness scores drift back down within a year of any cleanup.
An AI readiness checklist you can run this week
Seven checks. Most of a day’s work, and more useful than any maturity score.
Pick the one question you want an agent to answer. Write it down as a single sentence.
List every field and module that question depends on.
Run a fill-rate report on each of those fields. Anything under 90% populated is not ready.
Count the duplicates in the modules involved. If you cannot count them, that is your answer.
Find who owns each of those fields, by name. Not a department. A person.
Write out the process the agent would follow, in numbered steps. If two people write different versions, the process is not documented.
Decide what the agent may read and what it may change, then check that against the profile it will actually run under.
If four or more come back bad, the honest conclusion is that you are not ready to deploy that agent yet. The cheaper project is fixing the middle layer, not buying more AI.
Somebody has to be accountable for the middle layer
The reason this work does not get done is not that it is hard. It is that it belongs to nobody. Data hygiene sits between sales ops and IT. Process documentation belongs to whoever last had time. Permissions belong to the admin who is also doing four other jobs. Each of them is somebody’s third priority, which makes it nobody’s first.
That is the argument for treating the middle layer as an ongoing operational responsibility rather than a project with an end date. Managed technical operations exists for exactly this shape of work — maintenance with no launch date and no obvious finish line, which quietly decides whether everything built on top of it works. It is the same reason AI demand forecasting only pays off once the data behind it is production-ready and the output actually drives the schedule. The model was never the constraint.
CodeStringers structures the commercial terms around that. Discovery is no-risk — you pay for it only if you proceed to implementation, so finding out how thin your foundation actually is costs nothing if the answer is “don’t build this yet.” Estimates are guaranteed: if we estimate low, we absorb the difference. Retainer clients get a project plan with the full cost of a release before committing to it, instead of an open meter.
That is what accountability means here. Not that we take the system off your hands, but that we commit to an outcome and carry the consequences of being wrong about it.
Questions we get asked
Do we need to clean everything before turning on any AI?
No. Clean what the agent reads. Pick one question, map the fields behind it, and fix those. A full-estate cleanup in front of a single use case is how these projects stall before anything ships.
How long does the foundation work take?
For one agent’s worth of scope in a mid-market Zoho estate, usually two to six weeks — most of it deduplication, assigning field ownership, and writing down a process that already exists informally. Estate-wide governance is a longer program, and it should be sequenced behind the first working agent rather than ahead of it.
Is this argument specific to Zoho?
The argument is not. The failure points are. Zia scoring on incomplete records, workflow rules firing on unmaintained fields, and role-versus-profile drift are Zoho mechanics, and knowing exactly where they break is what makes the diagnosis fast instead of theoretical.
The next time an AI pilot underdelivers, resist the upgrade. Ask what the model was reading, who owns those fields, and whether the process it was asked to follow was ever written down. Fixing that answer is almost always cheaper than the next model.
Know whether your data and processes are ready for AI before you pay for it.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments