Your AI pilot can look impressive and still leave the business unchanged. It answers standard questions, drafts polished responses, and handles the clean demo path. Then it meets a disputed charge, an outdated customer record, a policy exception, or a system it cannot update. The work returns to a human.

If that pattern feels familiar, the next model upgrade is unlikely to solve it. You need to find the system-level constraint: the missing data, integration, authority, context, control, or ownership that prevents the AI from carrying work to a verified conclusion.

The assistant is only the visible edge of the product

A customer can pay for an extra bag and still require three calls to get the airline to confirm its own transaction. The payment exists. The customer has a simple request. Employees are available. Yet the information cannot move cleanly from the billing system to the people responsible for resolving the case.

Putting an AI assistant in front of that workflow does not repair it. The assistant may recognize the intent, explain the policy, and produce an empathetic response. It still cannot confirm the payment if the reservation system does not trust the billing system, the service console has stale state, or the assistant lacks permission to retrieve the transaction.

This is the first mistake in many AI strategies: treating the conversational interface as the product. The real product is the entire resolution path:

• Recognize what the user is trying to accomplish.
• Preserve the facts and constraints already established.
• Retrieve the correct policy and operational data.
• Resolve conflicts between records.
• Make or recommend an allowed decision.
• Write the result back to the relevant systems.
• Show evidence that the business state actually changed.
• Escalate exceptions with enough context for a human to continue.

If any link is missing, the interface can sound intelligent while the workflow remains manual. Employees become middleware: copying identifiers, checking another screen, interpreting policy, requesting approval, and re-entering the final state.

The scale of this gap should make product leaders cautious about demo metrics. Published accounts describe vendor demonstrations above 90% automation while production deployments land closer to 55–70% across real operating conditions. Those figures are directional, not a universal benchmark. Their value is in the pattern: the easy path dominates the demonstration, while exceptions, permissions, and integration failures dominate the unresolved remainder.

I use a stricter definition of adoption: AI is adopted when it can move an eligible unit of work to a verified terminal state, within policy, at an acceptable level of risk and human effort. Licenses activated, prompts submitted, and answers generated are usage measures. They are not proof of operational adoption.

Six barriers that masquerade as an AI quality problem

When a pilot underperforms, teams often change the prompt, switch models, or add more documents to retrieval. Those actions help only when the failure originated in the model or its context. Use the visible symptom to inspect the corresponding system layer before choosing a fix.

System barrier	What you observe	The decisive question
No authoritative state	The AI finds different values in different systems or gives an answer that was once correct.	Which system is authoritative for this fact, and how fresh must the value be?
Disconnected workflow	The AI explains what should happen but cannot complete the next step.	Can it read and write through supported interfaces, or is a person moving data between screens?
Missing authority	The AI reaches the correct recommendation but escalates every consequential action.	Which decisions may it execute, under what limits, and who owns the policy?
Context loss	Follow-up requests are answered as if the conversation started with the latest message.	Which user facts, constraints, and prior decisions must persist across turns?
Exception blindness	Routine cases work, but conflicting records, prior resolutions, or policy exceptions fail.	Which non-happy paths are common enough to design explicitly?
Fragmented ownership	The AI team owns the assistant, but nobody owns end-to-end resolution.	Who is accountable for the business outcome across product, data, operations, and system boundaries?

Data access is not the same as reliable truth

An assistant may technically have access to a CRM, knowledge base, billing platform, and support history. That does not tell it which record wins when those systems disagree. It also does not establish whether a retrieved value is current enough for the decision.

For every operational fact the AI uses, name the system of record, the expected freshness, and the conflict rule. A policy page may be authoritative for eligibility. The billing ledger may be authoritative for payment status. The customer profile may supply an address but not a financial balance. Without these distinctions, retrieval increases the amount of available information without establishing which information should control the action.

A useful answer is not a completed workflow

Many assistants are designed as read-only products. They can summarize an account, locate a policy, or recommend the next action. Resolution, however, normally requires a write: change a status, create a case, issue a credit, schedule an appointment, update a record, or notify another system.

That distinction should appear in the product requirements. Specify whether the AI can read, draft, recommend, execute with approval, or execute autonomously. Do not hide those levels inside a broad claim that it can handle a workflow.

Conversation history is not usable session state

A follow-up such as Could stress be causing this? is written for the conversation, not for a retrieval engine. Sent alone, it loses what this refers to, the reported severity, and the user’s preference to avoid medication. The same failure appears in business workflows when a customer says Use the other location, I already paid, or Do the same for next month.

Preserve a compact session state containing material facts, constraints, entities, and decisions. Keep the last two or three raw messages when wording and immediate sequence matter. Then construct retrieval from that state plus the new request instead of either sending the latest sentence alone or repeatedly stuffing the entire conversation into the model. A practical evaluation is to run 20 contextual follow-up questions twice: once with only the latest message and once with the maintained state. Check whether a relevant result appears in the top five and whether the query drops an important user constraint.

Organizational boundaries become product defects

A workflow can cross customer support, finance, security, legal, and product systems while every participating team still meets its local goal. The customer experiences the unresolved seam between them. AI makes that seam more visible because the assistant reaches it faster and at greater volume.

If one team owns response quality, another owns the connector, a third owns the source data, and nobody owns resolution, local optimization is predictable. The assistant becomes more fluent. The unresolved queue does not shrink. Give the workflow one accountable owner with authority to convene the system owners and change the end-to-end design.

Design around a verified resolution, not a conversation

Start with one workflow, not a general ambition to use AI. A narrow workflow exposes the exact data, permissions, exceptions, and handoffs required to create value. It also gives you a denominator for measuring performance.

1. Name the terminal state. Replace goals such as answer billing questions with an observable outcome such as confirm whether the specified invoice is paid and record the confirmation in the case. The terminal state must be visible outside the chat transcript.
2. Trace the state across systems. For each step, record what must be read, which system owns it, what must be written, and how the next system learns that the write occurred. Mark batch updates, stale replicas, manual exports, and duplicate identifiers.
3. Separate judgment from execution. Identify the decision the AI is making and the operation that implements it. The model may classify a case correctly while the tool call fails, or the operation may succeed even though the explanation is poor. These require different tests and different owners.
4. Set an authority ladder. Decide whether the AI may observe, draft, recommend, execute after approval, or execute within a bounded policy. Move up one level only when the evidence supports it. Financial, legal, privacy-sensitive, or difficult-to-reverse actions should retain approval or a reliable reversal path until their controls have been validated.
5. Build the exception catalogue. Include conflicting records, duplicated requests, prior partial completion, missing data, ambiguous identity, policy overrides, unavailable tools, and requests outside scope. Assign each exception a safe response: resolve, request one missing fact, queue for review, or stop.
6. Define proof of completion. A natural-language assurance is not evidence. Return a transaction identifier, updated status, timestamped event, created case, or other verifiable state from the operating system. If confirmation cannot be obtained, the assistant must say that the action is unverified.
7. Design the human handoff as part of the product. Send the intent, collected facts, sources consulted, actions attempted, tool results, policy boundary, and exact reason for escalation. A human should continue the case, not reconstruct it.

You can capture the design in a compact resolution contract:

Given the eligibility conditions, the system must produce a named business state, using specified systems of record. It may perform listed actions within defined limits. It must stop at named boundaries, return verifiable evidence, and escalate under explicit conditions.

This contract forces vague assumptions into product decisions. If you cannot name the terminal state, authoritative data, permitted actions, and stop conditions, you are not ready to automate the workflow. You may still use AI to assist an employee, but you should label that scope honestly.

Run the pilot against its worst day

A pilot dominated by routine cases answers the least useful question: can the system work when everything is already aligned? Production readiness depends on what happens when state, policy, language, or infrastructure is imperfect.

Build the evaluation set from distinct case classes:

• Routine cases: complete information, consistent records, supported intent, and a healthy integration.
• Context-dependent cases: pronouns, corrections, changed preferences, multiple entities, and references to earlier turns.
• Data-conflict cases: the CRM, ledger, support record, or user statement disagrees with another system.
• Policy exceptions: the normal rule does not settle the request, an approval is required, or two policies appear relevant.
• Partial-completion cases: an earlier employee or automation completed one step but not the full workflow.
• Tool-failure cases: timeout, unavailable dependency, rejected write, malformed response, duplicate operation, or success without confirmation.
• Boundary cases: the request is out of scope, identity is uncertain, or the proposed action exceeds the assistant’s authority.

Label every failure by layer. A single bucket called AI error encourages the team to tune prompts for problems caused by stale data, missing permissions, broken tools, vague policy, or a poor handoff.

• A model failure means the necessary information and tools were available, but the model interpreted or reasoned over them incorrectly.
• A context failure means a material fact or constraint was not carried into the decision.
• A retrieval failure means the correct knowledge existed but was not found or ranked usefully.
• A data failure means the required operational state was missing, stale, ambiguous, or inconsistent.
• A tool failure means the intended read or write did not execute or could not be verified.
• An authority failure means the action was technically possible but not permitted under the operating policy.
• A workflow failure means the case reached a boundary with no effective resolution or handoff path.

Measure the workflow, not just the conversation. Track eligible attempts that reach a verified terminal state, human touches per resolved case, time to resolution, reopen or rework rate, escalation completeness, unauthorized action attempts, and operations whose success could not be confirmed. Keep routine and exception performance separate. A single average can conceal a system that is excellent on low-value questions and unreliable precisely where the business carries the most risk or cost.

Review the failure distribution before changing the model. If most failures come from conflicting account state, model work is a distraction. If tool calls succeed but users repeatedly reopen cases, the definition of resolution may be wrong. If escalations are safe but expensive, improve the context package before granting more autonomy.

Fund and govern the operating change

AI initiatives often receive budget for the visible layer: model access, an assistant interface, and a launch. The less visible work competes for separate roadmaps—identity mapping, event synchronization, policy normalization, permissions, observability, exception handling, and frontline process changes. That split produces a polished entry point to an unchanged operation.

Evaluate every proposal across three funding lines:

• Experience: how the user states an intent, supplies information, reviews a proposed action, and receives confirmation.
• Resolution infrastructure: authoritative data, integrations, identity, read and write operations, policy rules, and state synchronization.
• Operations: evaluation, monitoring, incident response, human review, audit evidence, exception ownership, and feedback into the product.

If a plan funds only the first line, it is an interface plan. If it funds the first two but ignores ongoing evaluation and incident ownership, it is a launch plan. Sustainable adoption needs all three.

The governance model should also match the workflow. Assign one person accountability for the business outcome, then make the supporting ownership explicit:

• The workflow owner defines eligibility, the terminal state, and acceptable human effort.
• System owners guarantee the behavior of reads, writes, identifiers, and failure responses.
• The data owner defines authoritative fields, freshness expectations, and conflict resolution.
• The policy or risk owner sets decision boundaries, approval rules, and audit requirements.
• The AI product owner maintains orchestration, context, evaluations, and failure classification.
• The operating team defines useful handoffs and reports recurring exceptions that deserve product treatment.

During a pilot, hold a regular resolution review rather than a showcase. Ask five questions: What business state changed? What proves it? Which human steps disappeared or were added? Where are failures concentrated by system layer? What evidence is required before the next increase in scope or authority?

This changes the roadmap. The next priority may be an identity-matching service, a clearer refund rule, a reliable write API, or a better escalation packet—not a more capable model. That is not infrastructure distracting from the AI product. It is the work that turns the AI interface into a functioning product.

Key takeaways

• Define adoption as eligible work reaching a verified terminal state, not employees gaining access to an AI tool.
• Diagnose failures by layer before tuning the model. Data, context, integration, authority, and workflow defects require different owners and fixes.
• Give every operational fact a system of record, freshness expectation, and conflict rule.
• Test contextual follow-ups, conflicting records, partial completion, policy exceptions, tool failures, and authority boundaries—not only the clean path.
• Increase autonomy one permission at a time, with evidence, explicit limits, and a safe handoff or reversal path.
• Fund the interface, resolution infrastructure, and ongoing operations as one product investment.

Choose one important workflow and follow one real case from intent to confirmed state. Mark every point where a person copies data, reconciles two records, requests permission, retries an operation, or explains the case again. That seam—not the chat window—is your next AI product decision. Fix it, measure the change, and let the system earn its next permission.

References

• Ask Me AI — The Robot Is Begging for Change. My Airline Can’t Confirm I Paid for a Bag.
• Learn AI Together — LAI #141: The Questions AI Can’t Answer

---