"Working as Intended." The Customer Is Right. Your AI Checked Old Documentation.

The support AI closes the ticket: "This behavior is working as intended based on our documentation." The customer replies: "I understand what your documentation says. I'm telling you what the product is actually doing, and it's different." The ticket escalates. An engineer checks the codebase and finds that the behavior changed two months ago and the documentation was never updated. The customer was right. The AI was defending a behavior that no longer exists.

This pattern is more common than most support teams realize, because the failures are invisible until a customer pushes back hard enough. Every closed ticket that was "working as intended" based on stale documentation represents a real customer experience that was dismissed as a misunderstanding. Some percentage of those customers churn rather than reopen.

The confidence-accuracy gap

AI support tools generate responses with similar confidence regardless of whether the underlying information is current. The same tone, the same certainty — whether the AI is describing behavior from last week's release or from documentation written two years ago. There is no "I'm not sure if this is still accurate" signal, because the model has no way to know that the world changed.

This is the specific failure mode that makes "working as intended" closures dangerous. The customer is experiencing real system behavior. The AI is describing documented behavior. When those diverge, the AI is confidently wrong — and the customer is dismissed as confused. Support loses credibility, the customer escalates with frustration compounding the original problem.

What the AI checks when closing as "working as intended":
  -> Help center article: "Notifications are sent within 5 minutes" (written 8 months ago)
  -> Training data: historical tickets where this was expected behavior
  -> Result: "This behavior is expected — notifications process within 5 minutes"

What the codebase shows today:
  -> Commit 6 weeks ago: notification batching changed to 30-minute windows
  -> The customer was right. The AI was wrong.
  -> Three more customers reported the same issue before someone escalated.

How behavior drifts away from documentation

In teams where developers ship AI-accelerated output, the gap between what the system does and what the documentation says grows with every sprint. Not every change is significant enough to warrant a documentation update. Performance optimizations, internal refactors, behavior changes for compliance or scaling reasons — these frequently ship without corresponding documentation updates. The support AI inherits every one of these undocumented changes as a potential "working as intended" misfire.

How system behavior drifts from what support AI knows:
  Sprint 1: Notifications sent in 5 minutes (documented)
  Sprint 4: Batching added for performance, window now 30 minutes (documented?)
  Sprint 7: Batch window reduced to 10 minutes for premium tier (undocumented)
  Sprint 9: Batch behavior changed again for GDPR compliance reasons (undocumented)

  What the AI knows: Sprint 1 documentation.
  What the customer is experiencing: Sprint 9 behavior.
  Gap: 8 sprints of undocumented changes the AI confidently defends.

Support knowledge bases are always behind because documentation is a manual process. The codebase updates automatically. The only way to answer "is this current behavior?" accurately is to check the current codebase — not the documentation written at some earlier point.

The webhook agent that checks current behavior

Kognita's webhook fires on ticket creation. The managed agent receives the ticket, identifies the feature or service behavior being reported, and queries the live codebase index to determine the current system state. When a customer reports behavior that diverges from documentation, the agent can determine — from the actual code — whether the reported behavior is current, outdated, or a genuine regression.

What a Kognita webhook agent does on a behavior dispute:
  Ticket: "Notifications are arriving 30 minutes late — this is breaking our workflow"
  Agent queries codebase:
    -> Finds notification-service batch configuration
    -> Finds that batch window is 30 minutes for standard tier, 10 minutes for premium
    -> Finds that this changed in sprint 4 due to performance optimization
  Response: "Notification batch windows were changed in release v2.4 to 30 minutes
  for standard tier accounts. Premium tier accounts have a 10-minute window.
  This is current behavior, not a bug. If this change affects your workflow,
  our upgrade options are: [accurate current information]"

  No documentation needed. No escalation. First response resolves.

This doesn't require documentation updates. The agent reads the same code the developer wrote. It knows the current notification batch window because that's what the notification service configuration says right now. If the configuration changed yesterday, the agent's answer reflects yesterday's change — without anyone needing to update a help article.

When "working as intended" is accurate again

There are genuine cases where customers report expected behavior as a bug. A user who hasn't read the plan tier comparison might not know that bulk export requires a premium subscription. A user who onboarded before a UI change might be confused by the new workflow. These should be closed with accurate explanations.

The difference is that a codebase-grounded agent's "working as intended" response is derived from what the system actually does today — not from what it did when the help article was written. When the agent says it's working as intended, it's because the agent just checked. That's a fundamentally different kind of confidence.

Final take

"Working as intended" is only a valid ticket close when the AI actually knows what the current intention is. Documentation from last quarter doesn't tell you that. The codebase does. A webhook-triggered agent that reads the live codebase before responding doesn't defend stale behavior — it reports current behavior, which may have changed since the help article was written.

The customer is not wrong. The documentation is outdated. The AI was trained on the documentation. The codebase is the only source that doesn't have this problem — and a webhook agent that reads it first gets the answer right.