Why AI Agents Fail: Documentation Is Not the Source of Truth for Work

Most enterprise AI agents fail before anyone opens the builder.

The failure is decided at scoping, when a team defines what the agent should do based on the documented version of a process. Policies, SOPs, and process maps describe how work is supposed to happen. Real work is full of exceptions: approval rules that change by geography, judgment calls that live in people's heads, workarounds that never made it into a document.

Build an agent from documentation alone and it inherits an incomplete version of the company. It handles the happy path correctly, which is the part that was already working, and breaks on the exception path, which is where the cost was.

Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. Each of those three traces back to a scoping decision made without evidence about the real process.

Key takeaways

• The source of truth for documents is not automatically the source of truth for work.
• Documentation systematically omits exceptions, informal approvals, regional variation, and the reasoning behind decisions.
• An agent scoped from documentation automates the fraction of the process that was already smooth.
• The most expensive failures are silent: the agent produces plausible output for a case it should have escalated.
• Fixing this is a sequencing change, not a technology change. Process evidence comes before agent scope.
• The diagnostic question is not "can the model do this" but "does anyone know what this process actually does."

The two sources of truth

The distinction is worth stating precisely, because it is where the sequencing error originates.

Source of truth for documents. The governed corpus of policies, SOPs, contracts, wikis, and records. Modern enterprise search and knowledge platforms have made this layer accessible and well governed. It answers: what does the organization say about how this works?

Source of truth for work. How the process actually runs: the sequence people follow, the exceptions they handle, the approvals they seek, the systems they touch, the judgment they apply. It answers: what actually happens?

The first is a solved retrieval problem for most enterprises. The second is not stored anywhere. It exists distributed across the people doing the work, and no system holds a consolidated version.

An agent needs both. Given only the first, it produces an authoritative-sounding answer about a process that does not exist in that form.

How documentation drifts

The drift is not the result of negligence. It follows a predictable sequence.

A process is documented at a point in time, usually when it is designed or when a compliance requirement forces it. The documentation is accurate on the day it is written.

Then a system changes and someone adds a manual step to bridge the gap. A regulation changes in one market and the local team adds a check. A person leaves and their successor handles an edge case differently. A volume spike makes a step impractical and the team improvises. An incident produces a new control, which is added to the process and never to the document.

Each of those changes is rational and small. None of them triggers a documentation update, because updating documentation is nobody's priority and because acknowledging the change often means acknowledging the official process was insufficient.

After two or three years, the gap between the document and the practice is substantial and nobody has a measure of how substantial.

What documentation leaves out

Six categories are missing almost universally, and each one produces a distinct agent failure.

The pattern is consistent. Documentation captures intent. Agents built on intent perform well in demo and fail in operation, and the failure is concentrated in exactly the cases that made the process expensive in the first place.

Five failure modes and where each one originates

1. Scope drawn around the wrong process

The team picks a use case from a workshop or an executive list. The process sounds well-defined. Nobody checks whether the described version matches the operating one.

Origin: scoping. Symptom: the pilot works and adoption never happens, because the people doing the work know the agent is solving a version of their job they do not have.

2. Exception blindness

The agent is trained or prompted on the standard path. Exceptions arrive and it either handles them incorrectly or, worse, handles them plausibly.

Origin: evidence gap. Symptom: quality looks acceptable in aggregate metrics while a specific case type fails consistently.

3. Missing escalation logic

Nobody enumerated the conditions under which a human should take over, because nobody mapped what the current escalation path is.

Origin: scoping. Symptom: the agent has no way to say it does not know, so it does not.

4. Ownership mismatch

The workflow the agent changes belongs to a team that was not part of the design. There is no owner for the behavior change.

Origin: operating model. Symptom: the build completes, the workflow does not change, usage metrics look like access rather than adoption.

5. Automating what should have been removed

The process contains a step that exists because of a system limitation, a policy that changed, or a control that no longer reduces risk. The agent automates it faithfully.

Origin: no root-cause analysis before design. Symptom: the process runs faster and produces the same amount of downstream rework.

Four of the five originate before any code is written.

Agent design sequence

Where the failure is actually decided

Phase 2 is the one enterprise programs skip and the one that determines whether phases 3 through 6 are grounded in the real process.

The silent failure problem

Loud failures are manageable. The agent errors, someone notices, the case gets routed to a person.

Silent failures are the expensive category. The agent encounters a case outside its scope, has no signal that it is outside its scope, and produces output that looks like every other output. Nobody reviews it because nothing flagged it.

This is why exception coverage matters more than accuracy on the standard path. A system that is 95% accurate and knows when it is uncertain is more useful in production than one that is 98% accurate and confident throughout.

Three design requirements follow.

Enumerate the out-of-scope conditions

Not "escalate when uncertain" but the specific input patterns, thresholds, counterparties, and case types that must go to a person. A general instruction to escalate on low confidence assumes the model can recognize the categories of case it was never shown, which is precisely the assumption that fails.

Instrument for the absence of signal

Monitor the rate at which the agent escalates. An escalation rate near zero in a process with known exceptions means the detection is not working, not that the exceptions stopped. This is one of the few monitoring signals where a good-looking number is the warning.

Sample the outputs that were not flagged

Reviewing only the flagged cases audits the part of the system that is already working. A sampling regime that never looks at unflagged output cannot detect the failure mode it most needs to detect.

How to ground agent design in real process evidence

1. Start with the decision, not the tool

Define what business outcome the agent is meant to move. Cycle time on a specific queue, rework rate, cost per case, a compliance metric. If nobody can name the metric, the use case is not ready.

2. Establish the current state before defining scope

Find out what actually happens: the sequence, who owns each step, which systems are touched, which approvals exist formally and informally, which exceptions occur and how often, and where the process varies by region, team, or customer segment.

This step is where the sequencing correction happens. It is not a documentation review. It requires input from the people who perform the work, receive the output, and handle the exceptions.

3. Quantify the exception distribution

Ask what proportion of volume follows the standard path. In most enterprise processes the answer surprises the people who own the process. If a third of cases are exceptions, an agent scoped to the standard path addresses two thirds of volume and possibly none of the cost.

This single number does more to shape a sensible scope than any other input, and it is the one least often available at the moment the scope is drawn.

4. Separate the decisions inside the use case

"Handle invoice exceptions" is not one decision. It is classification, routing, drafting, sending, and approving, and those belong at different levels of autonomy. Scoping them as one produces either an agent that is too restricted to be useful or one that is authorized to act where it should not.

5. Check each step against whether it should exist

Before automating a step, establish why it exists. Controls added after a resolved incident, duplicate approvals where risk was already cleared upstream, and manual re-entry compensating for an unintegrated system are all candidates for removal rather than automation.

Automating them makes them permanent, because once a step is automated the case for removing it becomes harder to make: the work now appears free.

6. Define escalation from the current escalation path

The people doing the work already escalate. Find out when and to whom, and encode that. Inventing an escalation rule that has no relationship to the existing one produces a path nobody staffs.

7. Validate the scope with the teams who own the work

Before building, take the proposed scope back to the people who perform the process. Ask what is missing, which cases would break it, and what would have to be true for them to trust the output.

8. Build the refresh into the plan

Processes change. An agent scoped against a snapshot degrades as the organization moves. Decide in advance what triggers a re-scope: a policy change, a system replacement, a reorganization, or a drift signal in the escalation rate.

What tribal knowledge looks like when it becomes the process

There is a specific state large organizations reach without noticing. Documentation exists but has not been updated in years. The people who know how the work runs know it from experience rather than from any artifact. Status lives in two or three tools simultaneously because no single one was ever designated as authoritative.

At that point the organization is running on tribal knowledge, and the phrase understates the problem. It is not that the knowledge is informal. It is that the knowledge is distributed in a way that makes it unavailable to anyone trying to design a system: no individual holds the whole picture, and the aggregate exists nowhere.

An agent program that begins in that state has a specific characteristic. Every scoping conversation produces a confident answer, because each person can describe their part accurately. The parts do not compose, and nobody is in a position to notice.

The diagnostic question is not whether documentation exists. It is when it was last accurate, and whether anyone can say what proportion of work follows it today.

Where Horizon fits

Horizon is an AI-powered continuous discovery platform. Its role in agent programs sits at phase 2, the step most enterprise teams skip.

Discovery Cycles run AI-led interview campaigns across the roles that operate a process, asynchronously and at census scale. The conversations adapt in real time and follow up on high-signal answers, which is how exceptions and informal approvals surface at all. The Process Library extracts and structures what comes back into navigable process documentation, generated from the conversations rather than authored by hand, and it grows with each cycle. The Insights Dashboard ranks findings by impact and effort with each one traceable to the employee input behind it, and the Initiatives Dashboard turns the priority items into business cases and implementation plans with owners.

Trafilea, an eCommerce group running direct-to-consumer brands with more than 400 employees working fully remote across several countries, is a clear example of the starting state described above. Its process documentation had not been updated in over two years. Teams ran on tribal knowledge with no standardized source of truth. Status was duplicated across Asana and Slack at 80 to 100 requests per month, and the creator pipeline ran across more than seven tools with parallel updates and copy-pasted links. Briefs were scattered across Slides, Email, Loom and Asana with ownership and approvals unclear.

Horizon ran 43 asynchronous interviews across two tribes in two weeks without blocking a calendar. The engagement produced 10+ actionable findings, quantified 218 hours per month of operational waste in duplicate status tracking alone, identified 50 to 90% automation potential across key workflows, and generated standardized process documentation. It eliminated more than 129 hours of discovery work against traditional process mapping, and the internal estimate for the manual equivalent was about a year against four weeks with Horizon.

As Trafilea's process specialist put it: what would have taken a year to map was done in two to three weeks.

That is one engagement under specific conditions rather than a projection for any organization. What generalizes is the order of operations: the process was established from evidence before anyone decided what to automate.

An agent scoped from documentation two years out of date inherits a version of the company that no longer exists. That is not a model problem and no model improvement corrects it.

Pre-build checklist

Run this before any agent moves into development.

1. Can you name the business metric the agent should move?
2. When was the process documentation last accurate?
3. Do you know what proportion of volume follows the standard path?
4. Have you enumerated the exception types and their frequency?
5. Do you know where the process varies by region, team, or segment?
6. Have you identified the approvals that happen outside any system?
7. Has every step been checked against whether it should exist at all?
8. Have you decomposed the use case into individual decisions?
9. Is there a named business owner accountable for the workflow change?
10. Have you documented the current escalation path, including who receives it?
11. Are the out-of-scope conditions specific enough to implement?
12. Is there a monitoring signal for silent failure, not only for errors?
13. Have the people who do the work reviewed the proposed scope?
14. Do you know what triggers a re-scope?

If fewer than nine of these have answers, the build is premature regardless of how ready the technology is.

Common mistakes

Treating the SOP as the specification. The SOP is a hypothesis about the process. Verify it before building on it.

Measuring the pilot on the happy path. A pilot that excludes exception cases measures the part of the process that did not need help.

Skipping the exception frequency question. It is the single most informative number in agent scoping and it is almost never asked.

Confusing a demo with a workflow. An agent that works in isolation and does not fit the meetings, approvals, and systems where work happens will not be used.

Reading a low escalation rate as success. In a process with known exceptions, it usually means the detection is broken.

Assuming a better model closes the gap. Model capability improves output quality on cases the agent can see. It does not reveal the cases it was never scoped for.

FAQ

Why do most enterprise AI agents fail?

Most fail at scoping rather than in development. Teams define the agent around the documented process, which omits exceptions, informal approvals, regional variation, and workarounds. The agent then performs well on the standard path and fails on the cases that carry the cost. Gartner's prediction that over 40% of agentic AI projects will be canceled by end of 2027 attributes this to escalating costs, unclear business value, and inadequate risk controls, all of which trace back to scoping.

Can you build an AI agent from process documentation alone?

You can, but the agent inherits whatever the documentation left out. In most enterprise processes that includes the exception paths, which frequently carry a substantial share of volume and most of the operational cost. Documentation is a useful input, not a sufficient one.

What is a silent failure in an AI agent?

A silent failure occurs when the agent produces plausible output for a case it should have escalated, and nothing flags it for review. These are more damaging than visible errors because they accumulate without detection. Preventing them requires enumerating out-of-scope conditions explicitly and monitoring the escalation rate rather than only the error rate.

How much process discovery is needed before building an agent?

Enough to answer four questions: what proportion of volume is exceptions, what the exception types are, where the process varies, and what the current escalation path is. That is a smaller scope than a full transformation diagnostic and a much larger one than reading the SOP.

Should we fix the process before automating it?

Often yes. If a step exists because of a system limitation, a superseded policy, or a control that no longer reduces risk, automating it makes a redundant step faster and considerably harder to remove later. Root-cause analysis during discovery usually identifies several steps that should be removed rather than automated.

Who should own an enterprise AI agent?

A named business owner accountable for the workflow change and the outcome metric, supported by the process owner, a data or platform owner, and a risk partner. An agent owned only by a central AI team tends to launch without the workflow change that would make it useful.

Build fewer agents. Build the right ones.

Most agent failures are decided before anyone opens the builder. The scope is drawn from documents that describe the process as intended, and the exception path where the real cost lives never enters the design.

The correction is a sequence, not a technology. Understand how the work happens, then decide what is worth reinventing, then build.

See it. Fix it. Lead it.

See Horizon in action.