AI Agents in the Real World: Five Problems Capability Demos Hide

The public conversation about AI agents is still organized around capability:

• Can the agent browse?
• Can it call tools?
• Can it finish a coding task?
• Can it book, buy, reconcile, or deploy?

Those questions matter in a lab. They are not the questions that decide whether an agent is useful in a household or safe inside a company.

The real question is what happens after a person hands the system a goal, access to accounts, and permission to act.

An agent can be impressive and still create more work than it removes. It can obey a user and still exceed what that person thought they authorized. It can respect every individual permission and still assemble information nobody expected it to see together. It can remember a useful preference and also preserve a false, sensitive, or malicious memory. It can complete the happy path while making the rare exceptions ruin the economics.

This is the agent reality gap: the distance between completing a task in a demonstration and carrying responsibility in a living system.

This six-part series examines five problems on the far side of that gap. Each article separates observed evidence from an operating recommendation and ends with an artifact a person or enterprise team can use.

Contract review, October 16, 2026: the original research-review window and publication date remain. This revision maps the operating recommendations to current execution/profile obligations, updates the product-memory example and removes total-score permission to widen autonomy. No cited experiment, production control or ROI claim was rerun here.

How this series was researched

The evidence review ran through August 31, 2026 and favored four source classes:

1. Government and standards work, including NIST, OECD, and the text of the EU AI Act.
2. Field studies and controlled experiments that measured work rather than asking only for opinions.
3. Agent benchmarks that test tool use, policy adherence, and consistency across repeated runs.
4. Vendor system cards and product documentation, used as evidence of known failure modes and deployed mitigations—not as independent proof that a vendor solved them.

The distinction matters. A system card can show that a developer considers confirmation or prompt injection serious. It cannot establish the safety of every deployment. A benchmark can expose a failure class. It cannot predict production performance for a different model, tool set, or workflow. A productivity study can measure one task population. It should not be universalized to all work.

Several claims were deliberately excluded: timelines to artificial general intelligence, total job-loss forecasts, model leaderboard comparisons, and vendor estimates that count generated output as realized business value.

What the evidence says

The five problems are not hypothetical edge cases. Different evidence sources converge on them from different directions.

The 2026 Stanford AI Index gives the broad context: documented incidents in the AI Incident Database rose from 233 in 2024 to 362 in 2025, while responsible-AI benchmark reporting remained sparse. This does not mean agents caused every incident. It means adoption and capability have moved faster than the evidence needed to govern consequences.

Problem 1: the user delegated a sentence, but the agent needed a contract

“Plan my trip.”

“Handle my inbox.”

“Fix the production issue.”

Each sentence conceals decisions about money, recipients, deadlines, privacy, tradeoffs, and stopping conditions. A human collaborator fills those gaps through shared context and social judgment. An agent fills them through an incomplete prompt, retrieved content, product defaults, and whatever permissions happen to be available.

The issue is not solved by asking for confirmation at every click. NIST’s 2026 identity guidance explicitly warns that overusing human-in-the-loop approvals can create consent fatigue—the same behavioral weakness exploited by repeated authentication prompts.

The solution is a delegation contract created before execution: goal, allowed actions, prohibited actions, data scope, spend or change limits, validity period, approval triggers, and a receipt. Part two of this series turns that into a usable template.

Problem 2: the work did not disappear; it moved into verification

AI output is cheap to produce and expensive to trust.

The strongest illustration is not a claim that AI always slows people down. It is the disagreement between credible studies. An NBER field study of 5,179 support agents found a 14% average productivity gain, concentrated among novice and lower-skilled workers. A METR randomized study found experienced open-source developers took 19% longer on their own mature codebases with early-2025 AI tools, even though they estimated afterward that AI had made them 20% faster.

Both can be true. Different workers, tasks, artifacts, error costs, and review burdens produce different outcomes. The lesson is not “AI works” or “AI does not work.” The lesson is that perceived speed and measured completion are different variables.

The solution is a verification ledger that records generation time, review time, rework, escaped errors, and the reviewer’s ability to assess the artifact. Part three shows how to calculate the review tax and decide which work should remain assistive.

Problem 3: permissions compose faster than security teams can reason about them

A personal agent connected to email, calendar, cloud drive, shopping, and payments does not merely have five permissions. It has paths between five domains.

An enterprise agent connected to CRM, support, HR documents, code, and messaging can join facts that were harmless in isolation. It may inherit a user’s old group memberships, follow an instruction embedded in a document, then send the assembled result through a tool that was approved for another purpose.

This is why NIST’s agent identity concept paper asks how to establish least privilege, prove authority for a specific action, bind agent identity to human authorization, and preserve non-repudiation. It is also why Microsoft documents restricted discovery, data-loss prevention, and agent controls for SharePoint.

The solution is not one larger OAuth consent screen. It is purpose-bound authority: a distinct agent identity, short-lived capabilities, source and destination policy, and re-authorization when the plan materially changes. Part four provides the control design.

Problem 4: memory converts an error into a policy

Without memory, a bad interaction can end with the session. With memory, it can become a premise for future action.

The MINJA paper demonstrates that an attacker can inject malicious records into an agent’s memory through query-only interaction. MemoryGraft demonstrates a different mechanism: poisoned “successful experiences” are retrieved later for semantically similar tasks, causing persistent behavioral drift.

Even benign memory has control problems. OpenAI’s current Memory documentation, checked October 16, explains that chats, saved memories or summaries, Library files and connected apps can be distinct sources. Deleting a chat does not necessarily remove a separate saved memory; settings and propagation vary. That product-specific design illustrates the underlying systems point: memory is not one thing in one place.

The solution is a memory ledger with provenance, subject, purpose, sensitivity, confidence, scope, expiry, and deletion state—plus a hard separation between capturing an event and promoting it into reusable memory. Part five provides the schema and lifecycle.

Problem 5: the last 10% of work can contain most of the cost

Agent demos are selected for legibility. Production receives duplicate records, conflicting policies, missing fields, changed goals, unavailable tools, adversarial content, and users who do not express intent cleanly.

The original tau-bench tested agents in retail and airline interactions with tools and domain rules. The evaluated function-calling agents succeeded on fewer than half of tasks, and repeat consistency was worse: retail pass-to-the-power-of-eight was below 25%. The exact model results are now historical; the important contribution is the metric. One successful run does not establish a dependable workflow.

Anthropic’s January 2026 Economic Index reaches the same operating problem from usage data. Its task-reliability adjustment roughly halved one modeled productivity estimate, and its analysis found bottleneck tasks can further constrain aggregate gains. Because this is vendor-authored and partly model-estimated, treat the exact macroeconomic values cautiously. The direction is operationally useful: failed and complementary tasks do not disappear from the workflow.

The solution is an exception economy ledger: exception class, frequency, handling time, loss severity, detection point, and owner. Part six shows how to find the point where automation creates a harder residual job rather than a better system.

Why “hallucination” is too small a diagnosis

Calling all five problems hallucination produces bad fixes.

A better model can reduce some errors. It cannot decide who was authorized, make an overloaded approver attentive, repair over-broad file permissions, define a person’s right to correct memory, or assign an owner to the exception queue.

Those are system and operating-model decisions.

The five-control readiness check

Use the following per-control inventory to expose gaps, with explicit unknown/not-evaluated status. It is not a substitute for workflow-specific required controls or current evidence.

The earlier total-to-authority bands are withdrawn: a high total could hide one missing mandatory condition, and drafting or read-only exploration can itself expose protected data. Exact control profiles select obligations from workflow features. Useful allowed cases, required denials and current independently verified evidence bind the claim to the workflow, implementation, release and environment under Conformance. Missing, failed, stale or unevaluated mandatory controls block dependent work regardless of other scores.

The solution is a governed handoff

Across all five problems, the same architecture appears:

1. Compile the user’s intent into an explicit, bounded contract.
2. Give the run only the evidence and authority required for that contract.
3. Verify high-risk decisions against rules and source evidence before action.
4. Preserve an inspectable record of what was proposed, approved, executed, and learned.
5. Treat exceptions and corrections as operating data, not embarrassing anecdotes.

ContextOS expresses those controls through governance, identity, evaluation and observability, memory, and a replayable execution contract. The labels are less important than the discipline: authority must remain attached to intent while the plan changes.

The additive execution guide preserves base envelopes while adding current owner/workload mandates, exact stored action approvals, observed containment/credential/data routes and owned durable operations. Compiler policy-expression errors stop with structured non-success. Checkpoint restore and proactive wake-ups revalidate current controls; retries, reviewers and children conserve original spent/reserved limits. A timeout/cancellation can leave effects unknown, and a deletion request can leave derived copies pending. The deterministic reference validates supplied trusted facts; deployed brokers, enforcers, stores and providers need separate evidence.

Series map

1. This article: the evidence map and five-control readiness check.
2. The Delegation Contract: How to Let an AI Agent Act Without Losing Control
3. The AI Agent Review Tax: When Automation Creates Verification Debt
4. The Permission–Data Collision: Why Better-Connected Agents Create New Exposure
5. Agent Memory Needs a Right to Correct and Forget
6. The AI Agent Exception Economy: Why the Long Tail Decides ROI

What to read next

• The Delegation Contract: How to Let an AI Agent Act Without Losing Control
• The AI Agent Accountability Matrix
• The Eight-Property Harness Audit
• Governance