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.
How this series was researched
The evidence review ran through August 31, 2026 and favored four source classes:
- Government and standards work, including NIST, OECD, and the text of the EU AI Act.
- Field studies and controlled experiments that measured work rather than asking only for opinions.
- Agent benchmarks that test tool use, policy adherence, and consistency across repeated runs.
- 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.
| Problem | Evidence signal | What the demo hides |
|---|---|---|
| Delegation ambiguity | NIST warns about credential sharing, consent fatigue, and binding agent actions to human authority; payment protocols add verifiable intent | “Do this for me” is not a durable authorization contract |
| Verification debt | One controlled study found experienced developers took 19% longer with early-2025 tools even while believing they were faster; other field work found gains that varied sharply by worker | Generated work moves effort into review, repair, and integration |
| Permission and data overreach | NIST treats agent identity and authorization as a distinct infrastructure problem; Microsoft ships controls specifically for oversharing in Copilot and agentic experiences | Valid access to each source can become unsafe access in combination |
| Ungoverned memory | Research demonstrates query-only memory injection and persistent poisoned experience retrieval; consumer memory controls reveal deletion is a multi-store operation | Personalization turns one bad fact into repeated future behavior |
| The exception economy | Tool-agent benchmarks show low success and poor repeat consistency; economic analysis finds reliability and bottleneck tasks materially reduce modeled productivity gains | Happy-path automation leaves humans a smaller but harder queue |
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 Memory FAQ explains that deleting a chat does not delete a saved memory from that conversation, and fully removing a memory may require deleting both. That is a product-specific design, not evidence of wrongdoing. It 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.
| Symptom | Misdiagnosis | Actual control problem |
|---|---|---|
| Wrong purchase | Model made a mistake | Delegation and confirmation did not freeze the important fields |
| Reviewer misses defect | Human should pay more attention | Review workload and inspectability were not designed |
| Sensitive data reaches a message | Retrieval returned too much | Authority and egress policy composed unsafely |
| Old preference changes a future decision | Memory was inaccurate | Memory lacked provenance, expiry, correction, and scope |
| Pilot ROI vanishes at scale | Model needs a higher score | Exception frequency and handling cost were excluded |
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
Score each control 0, 1, or 2 before an agent receives meaningful authority.
| Control | 0 | 1 | 2 |
|---|---|---|---|
| Delegation | Goal is a prompt | Some action confirmations | Versioned scope, limits, gates, expiry, and receipt |
| Verification | Output is accepted or spot-checked informally | A reviewer is assigned | Review time, defects, escapes, and reviewer competence are measured |
| Permission | Agent reuses the user’s standing access | Some tools are scoped | Distinct identity, short-lived capability, purpose and egress policy |
| Memory | Conversations or outcomes become reusable context | Users can clear some memory | Provenance, promotion review, correction, TTL, and deletion propagation |
| Exceptions | Demo success is the KPI | Known failures are listed | Exception frequency, severity, handling time, and owner drive rollout |
Interpret the total conservatively:
- 0–3: do not grant action authority. Use the system for exploration or drafting only.
- 4–7: run a bounded pilot with explicit human review and a small data/tool surface.
- 8–10: consider staged authority, but require evals, incident controls, and rollback for the specific workflow.
The number is not a certification. It is a way to force five missing conversations before a launch decision.
The solution is a governed handoff
Across all five problems, the same architecture appears:
- Compile the user’s intent into an explicit, bounded contract.
- Give the run only the evidence and authority required for that contract.
- Verify high-risk decisions against rules and source evidence before action.
- Preserve an inspectable record of what was proposed, approved, executed, and learned.
- Treat exceptions and corrections as operating data, not embarrassing anecdotes.
ContextOS expresses those controls through governance, identity, evaluation and observability, memory, and a replayable runtime contract. The labels are less important than the discipline: authority must remain attached to intent while the plan changes.
Series map
- This article: the evidence map and five-control readiness check.
- The Delegation Contract: How to Let an AI Agent Act Without Losing Control
- The AI Agent Review Tax: When Automation Creates Verification Debt
- The Permission–Data Collision: Why Better-Connected Agents Create New Exposure
- Agent Memory Needs a Right to Correct and Forget
- The AI Agent Exception Economy: Why the Long Tail Decides ROI