Why Most AI Agent Projects Fail in Production—and How Operational Engineering Fixes the Problem

An AI agent can classify documents, investigate transactions and prepare recommendations in minutes. That does not mean it is ready to run a financial workflow.

In regulated organisations, the difficult part is rarely getting an agent to complete the happy path. The difficult part is deciding what happens when data is incomplete, policies conflict, confidence is low or a case falls outside the examples used during testing.

The article Building Governed Agentic AI for Financial Operations cites an IEEE Computer Society analysis suggesting that 83% of technology leaders start AI projects, while only 9% successfully operationalise them. That gap is a useful warning: deploying an agent is not the same as deploying a dependable operation.

The practical lesson is straightforward. Treat agentic AI as an operational engineering problem, not as a software feature rollout. Stabilise the workflow first, design auditability into the agent, create explicit human escalation paths and assign ongoing ownership before increasing autonomy.

The capability trap: why AI pilots fail in production

An AI pilot usually demonstrates a capability: extract fields from a document, summarise a case, identify a suspicious transaction or draft a response. A production process has more demanding requirements. It must handle exceptions, preserve evidence, respect permissions, meet service levels and make its decisions reviewable.

Consider a lender automating income-verification documents. A basic pilot may perform well on standard payslips in a clean digital format. The live workflow will also encounter scanned documents, multiple employers, inconsistent names, missing pages, foreign currencies and documents that contradict information already held in the customer record.

If the team measures only extraction accuracy on standard examples, it may declare success too early. The operational questions are different:

• What evidence is required before a case can move forward?
• Which fields can be accepted automatically, and which require review?
• What happens when two documents disagree?
• How does the system record the reason for a decision?
• Who owns a case that the agent cannot resolve?

These questions expose why “add an agent” is often the wrong starting point. The organisation may not have a single documented process. Different teams may apply different interpretations of the same policy. Exceptions may be resolved through email or personal judgement, leaving little usable audit history.

The source article reports that 90% of enterprise data is unstructured, citing CFA Institute research. Whether the data is in documents, email, notes or attachments, an agent inherits the ambiguity of that environment. It cannot create a reliable operating model merely by being connected to more files.

A better pilot has a narrower objective: prove that one clearly defined workflow can be executed with controlled inputs, explicit decision rules and safe handoffs. The success measure is not just whether the agent completes more cases. It is whether the organisation can explain every accepted, rejected and escalated case.

Step one: stabilise the baseline before automation

Before automating a process, map how it actually works today. This means documenting the full path from intake to closure, including manual workarounds that are often absent from the official procedure.

For a financial operations team handling suspicious-activity alerts, the map might include:

1. An alert arrives from a monitoring system.
2. An analyst gathers account history, transaction context and customer information.
3. The analyst checks relevant policies and records an initial assessment.
4. A second reviewer validates high-risk cases.
5. The case is closed, escalated or referred for further action.

That outline is not enough. The team also needs to capture what happens when the customer record is incomplete, the alert contains duplicate transactions, the supporting evidence is unavailable or the policy does not clearly cover the situation.

A useful baseline workflow map should record:

• Inputs: systems, documents, fields and permissions required to begin.
• Decisions: the rules or judgements that move a case to the next stage.
• Evidence: information that must be retained to justify each decision.
• Exceptions: conditions that prevent the standard path from continuing.
• Owners: the person or team accountable for each decision and handoff.
• Service levels: the time limits and queues that affect customer or regulatory outcomes.

The recommendation from the source article is to digitise workflows end to end before attempting optimisation. In practice, this might mean replacing an email-based exception process with a structured case record, standardising status values and recording the reason for each handoff. It may feel slower than immediately connecting an agent to operational systems, but it creates a stable baseline against which automation can be tested.

A simple readiness test is this: ask three experienced employees to describe the process independently. If their answers differ materially, the process is not yet ready for broad autonomous execution. Start by resolving the differences or explicitly representing them as approved decision paths.

Explainability must be designed into the workflow

Explainability is often treated as a report generated after an AI system has made a decision. That is insufficient for regulated operations. A reviewer needs to know not only what the agent decided, but also which evidence it used, which policy or rule it applied, what alternatives it considered and why it stopped or escalated.

This makes explainability a design constraint. The agent should produce a decision record as part of its normal operation, rather than attempting to reconstruct one later.

For a document-review agent, a useful record might include:

• the document version and source;
• extracted fields and their confidence or validation status;
• checks performed against internal records;
• policy rules invoked;
• contradictions or missing information detected;
• the action taken;
• the reason for escalation, if applicable;
• the human reviewer, decision and timestamp.

The record should distinguish between facts extracted from source material, calculations performed by the system and recommendations generated by a model. A reviewer should not have to infer which parts are evidence and which parts are interpretation.

This also affects system architecture. Instead of allowing a language model to produce an unrestricted final decision, the workflow can separate responsibilities:

1. A retrieval step collects approved records and policy documents.
2. A structured extraction step converts relevant information into defined fields.
3. A rules or validation layer checks mandatory conditions and contradictions.
4. An agent proposes an action with supporting evidence.
5. A human or authorised control approves actions outside the agent’s permitted scope.
6. The workflow stores the complete decision lineage.

The model may still be useful for interpreting unstructured material, but it should not be the sole source of truth for permissions, thresholds or regulatory obligations. Those controls need stable, reviewable representations that can be tested when policies change.

Design for exceptions and uncertainty

A safe agent is not one that always returns an answer. It is one that knows when it does not have enough evidence to proceed.

Suppose an accounts-payable agent receives an invoice whose supplier name differs from the approved vendor record, whose purchase order is missing and whose tax treatment is ambiguous. A weak design may fill in the gaps, select the closest match and send the invoice for payment. A governed design pauses the transaction, records the conflicts and routes the case to the appropriate reviewer.

Exception handling should be explicit rather than hidden inside a prompt. Define categories such as:

• missing required evidence;
• conflicting records;
• low-confidence extraction;
• policy ambiguity;
• unusual value or transaction pattern;
• unavailable system or data source;
• request outside the agent’s authority.

For each category, specify the destination, required information and permitted next action. For example, a low-confidence customer-name match might return to an operations analyst, while a policy conflict might go to compliance. The agent should attach the evidence it used and state exactly what prevented completion.

A practical escalation message is more useful than a generic “needs review” flag. It might say: “Payment held because the invoice supplier name does not match the approved vendor record, the purchase order is absent and the tax category cannot be determined from the supplied document. Review vendor identity, purchase-order status and tax treatment.”

This approach makes human involvement part of the design rather than evidence that the automation failed. It also prevents a common failure mode: optimising the rate of automatic completion by encouraging the agent to guess.

A four-step operating model for governed deployment

Teams can turn these principles into a controlled implementation sequence.

1. Audit and digitise the current workflow

Select one process with a clear business outcome, such as onboarding review, payment exception handling or regulatory reporting preparation. Map inputs, decisions, systems, evidence and exceptions. Replace informal handoffs with structured records where possible.

Do not begin with the most complex workflow in the organisation. Choose a process where the boundaries of the agent’s authority can be stated clearly and where a human team already owns the outcome.

2. Define exception paths before the happy path

Write down the conditions under which the agent must stop. For every exception, specify who receives the case, what evidence is passed along and what the reviewer must decide.

Test these paths with real historical cases, including difficult and incomplete examples. A workflow that works only on clean inputs is a demonstration, not a production system.

3. Build explainability into the logic layer

Create a structured decision log containing inputs, evidence, checks, rules, output and escalation reason. Make the log available to operations, compliance and internal audit without requiring them to inspect model internals.

Version the prompts, retrieval sources, policies and validation rules. When an outcome changes, the organisation should be able to determine whether the cause was new data, a policy change, a model update or a workflow configuration change.

4. Establish operational ownership

Assign named owners for workflow performance, model and prompt changes, access permissions, data quality, incident response and periodic review. An agent left without ownership will drift as policies, documents and upstream systems change.

Define operating measures beyond automation rate. Useful measures include exception resolution time, unsupported-decision rate, audit-record completeness, human override patterns, false escalations and incidents caused by stale or incorrect information.

What this approach cannot solve automatically

Governance-first deployment introduces real costs. Mapping the workflow takes time. Cross-functional reviews can delay launch. Structured evidence capture may expose process weaknesses that teams previously managed informally. Smaller organisations may also lack dedicated compliance, data and engineering capacity.

There are technical limits as well. Explainability records do not make an incorrect decision correct. A complete audit trail can document a flawed policy or bad source data. Human escalation can become a bottleneck if exception volumes are high or reviewers lack clear authority. And a model may appear reliable during testing while failing on new document formats, policy language or customer behaviours.

The answer is not to remove controls in pursuit of a higher automation percentage. It is to start with bounded authority, monitor outcomes and expand the agent’s scope only when the evidence supports doing so.

The source article also includes several industry figures that should be checked before being used in an investment case, including estimates about non-compliance costs and complex end-to-end task success rates. Leaders should validate those figures against their own process data rather than treating them as universal benchmarks.

Agentic AI becomes more useful when an organisation stops asking, “What can the model do?” and starts asking, “What decision may this system make, on what evidence, under which controls, and what happens when it is uncertain?”

Before deploying an agent, map the exception paths of the existing manual process. If the agent cannot hand an exception to a named human with the relevant evidence and a clear audit trail, the workflow is not ready for production autonomy.