Why AI agents fail at real business tasks: the missing-context problem

What is the missing-context problem?#

The missing-context problem is the gap between what an AI agent can infer from general knowledge and what a task inside your company actually depends on. An agent can write a fluent reply to a customer, yet not know that this customer is on a legacy contract, that refunds above a set limit need the controller, or that similar requests were declined last quarter.

General-purpose models learn mostly from broad public and licensed text, such as documentation, forums, books and open code. Very little of that text shows how a specific mid-size company runs a refund, a change order or a dispatch. The knowledge that matters sits in ticket histories, CRM notes, approval chains and the memory of experienced staff.

That is why agent pilots often look strong in a demo and stall in production. The demo uses a clean, generic task. Production brings the account with an exception, the order that was split, and the customer who escalates through a different channel.

The three causes, and the records that fix each#

Three context gaps explain many agent failures in business work: missing state, missing procedure and missing judgment. Each produces a different symptom, and each is closed by a different family of records, which is why one fix rarely solves all three.

In practice the causes stack. An agent with perfect access to current data still fails if it does not know the approval path, and an agent that follows the right path can still make a call your best people would not.

Why missing state is the easiest gap to see#

Missing state is the easiest gap to see because the agent's mistake can be checked against a system of record. When an agent quotes a discontinued part or cites a support plan the customer cancelled, someone can open the ERP or CRM and point to the correct value.

The fix is usually integration plus history. Connectors give the agent today's values. History shows how state changes over time: a contract amended twice, an order that moved from backorder to partial shipment, a ticket reopened after a release. Records with full status histories show an agent, and the people testing it, that state is a sequence, not a snapshot.

The common mistake is exporting only current tables. A customer table without its change log, or a ticket export without status transitions, removes exactly the context an agent needs to reason about what happened before.

Why procedure and judgment are harder to supply#

Procedure and judgment are harder to supply because neither is written down in one place. A written SOP describes the normal path. The real procedure lives in reassignments, side conversations in Slack, approval comments and the exceptions experienced staff handle without thinking.

Judgment is harder still. A record of judgment needs the situation, the decision and what happened afterward. A ticket marked resolved says little; a ticket that shows the first answer, the customer's reply, a senior engineer's correction and no reopening teaches what a good resolution looks like.

Outcome-linked records are also what AI developers find hardest to produce on their own. They can write synthetic tasks, but they cannot invent years of real decisions with real consequences inside a working company.

How teams supply each kind of context#

Each kind of context is supplied one way while the agent runs and another way while it is tested, and many failed pilots come from mixing the two up. Run-time context helps the agent act; test cases built from past records tell you whether it acts the way your best people would.

The testing column matters most for a CTO choosing between vendors. A vendor demo on generic tasks says little; a replay of your own past cases, graded against what actually happened, says a great deal.

Illustrative: an engineering firm's RFI agent#

Illustrative: a fictional civil and structural engineering firm deploys an agent to draft responses to contractor RFIs logged in Procore. The drafts read well, but reviewers send many of them back, so the firm sorts the rejections by cause.

Some drafts cite a superseded drawing revision, which is missing state. Others go straight to the contractor without the internal review the managing principal requires on structural changes, which is missing procedure. The rest approve product substitutions the firm's engineers have historically refused for durability reasons, which is missing judgment.

The firm connects the agent to the current drawing log and its revision history, writes the review routing from its past RFI threads into the agent's instructions, and gives it prior substitution requests with each engineer's decision and reasoning. A principal stays in the loop for structural RFIs. The rejections that remain are now real engineering disagreements rather than avoidable errors.

What to check before blaming the model#

Before blaming the model, a CTO should check whether the agent ever had the context the task required. A short review of failed runs usually shows whether a context gap is responsible and which one, and that review costs far less than a platform change.

• 1Pull a sample of failed runs and label each one as a state, procedure or judgment failure.
• 2Separate tool and integration errors, such as timeouts, permission denials or malformed calls, from context failures; those need engineering fixes.
• 3For state failures, confirm the agent reads current values and their change history, not a stale nightly snapshot.
• 4For procedure failures, compare the written SOP with how tickets, orders or jobs were actually routed and approved.
• 5For judgment failures, find similar past cases and check whether their outcomes were recorded anywhere.
• 6Keep a held-out set of your own real cases to test any new model or vendor against.
• 7List the records that were missing or unlinked; that list becomes your context backlog.

Why the same gap creates demand for business records#

The missing-context problem matters beyond internal projects because AI developers face the same gap at scale. Teams building agents for business work need records that show real state changes, real routing and real outcomes to train and evaluate those agents, and public text rarely contains them.

That is one reason operational records such as support histories, dispatch jobs, order exceptions and code reviews can be licensed. The company keeps ownership, licenses a defined scope, and personal and confidential details are removed before anything is delivered.

SourceX approaches this with the SourceX Enterprise Data Value Framework, which rates drivers such as human-generated signal, domain expertise and AI utility, and with the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The initial fit check uses metadata only, and the supplier approves every step.