Categories of hallucinations

"Hallucination" has become a catch-all term for any time an AI agent produces incorrect output, but this lack of precision makes it harder to diagnose issues and find solutions. When we say "the model hallucinated," we're often describing very different failure modes that require different fixes. A model fabricating a URL because it was told to always cite sources is fundamentally different from a model ignoring an instruction buried in a long prompt, which is different again from a model making a reasonable-but-wrong assumption about business hours.

This post breaks "hallucination" down into more specific categories, so we can be precise when discussing bad agent behaviour. Each category describes a distinct root cause, which means each has distinct mitigation strategies. I expect the list to grow as we encounter new patterns.

Missing escape hatch

The model knows the correct answer but the available options, tools or output formats don't allow it to express that answer. Rather than refusing or surfacing the limitation, the model responds incorrectly by selecting an inappropriate option or fabricating content that fits the constraints. Models are trained to be helpful and complete tasks, so when faced with impossible constraints they will attempt to satisfy the request anyway.

Examples

• A classification task with fixed categories (e.g. "Billing", "Technical", "Sales") receives a question about account deletion that doesn't fit any category. The agent picks "Billing" because it's the closest match, even though it's incorrect.
• The agent is told to always provide a definitive answer, but the truthful response is "I don't know" or "This requires human judgment."
• A workflow requires selecting from predefined tool responses, but none accurately capture the situation, leading the agent to force-fit an inappropriate option.
• Instructions say "Always cite the source with a link," but the knowledge base article was manually uploaded or created without a URL. The agent fabricates a plausible-looking but non-existent link to comply with the citation requirement.

Mitigations

• Include an "Other" or "Unknown" option in classification tasks.
• Allow the agent to express uncertainty or escalate to humans.
• Design tool outputs and response formats with edge cases in mind.
• Audit workflows to identify scenarios where the agent is forced into false choices.

Conflicting instructions

The model receives multiple instructions that cannot all be satisfied simultaneously. Rather than surfacing the conflict or asking for clarification, it arbitrarily prioritises one instruction over another, often without transparency about the trade-off being made. Models have a strong drive to complete tasks and appear coherent, so they resolve conflicts silently rather than acknowledging uncertainty or asking for help.

Examples

• The system prompt says "Always respond in formal English" while the business's workflow says "Match the customer's tone" - when a customer writes casually, the agent must choose one.
• Instructions say "Be concise" and also "Provide comprehensive explanations" for the same response.
• One policy says "Never share order status details" while another says "Always answer customer questions directly."
• Workflow instructions conflict with knowledge base content (e.g. the knowledge base says returns are 30 days, the workflow says 60).

Mitigations

• Establish clear instruction precedence (e.g. business-specific policies over general guidelines).
• Design prompts to handle conflicts explicitly ("If X conflicts with Y, prioritise X").
• Test instruction sets for internal consistency before deployment.
• Use structured reasoning to surface conflicts rather than silently resolving them.

Missing context

The model lacks the information it needs to answer accurately but attempts to be helpful anyway, resulting in fabricated details. This is driven by sycophancy and the model's training to be maximally helpful - it would rather give a plausible-sounding answer than disappoint the user by admitting ignorance. The desire to be useful overrides the awareness of knowledge gaps.

Examples

• A customer asks about their specific order status, but the agent doesn't have access to order data and invents a plausible-sounding status.
• Asked about a business's refund policy when no policy document is provided, the agent generates a reasonable-sounding but potentially incorrect policy.
• The agent references a "knowledge base article" that doesn't exist when trying to point the customer to more information.
• The agent provides specific dates, times or tracking numbers that were never supplied.

Mitigations

• Explicitly instruct agents to acknowledge when information is unavailable, and point out that "information not available" is a valid and expected scenario.
• Provide clear boundaries and explain the data the agent has access to.
• Use guardrails that detect when the agent is generating specifics (dates, numbers, names) not present in context.

Reasonable assumption

The model makes inferences that seem logical but don't align with the specific business rules, customer expectations or edge cases of the actual situation. These assumptions often appear correct and are hard to catch because they follow common patterns. Models draw on broad training data and will fill gaps with what's "usually true" - but businesses often have specific rules that diverge from common sense. Sometimes these assumptions come from wider conversational context: if a user is asking about their account, it seems reasonable to assume they have a username.

Examples

• Assuming business hours are 9-5 Monday to Friday when the business actually operates 24/7.
• Inferring that "free shipping" applies to all orders when it only applies to orders over $50.
• Assuming a customer asking about "my subscription" has only one subscription when they have several.
• Treating "cancel" as "cancel immediately" when the business has a specific cancellation process with retention offers.
• A user asks about their account settings, so the agent assumes they have a username and password - but the business uses SSO only.

Mitigations

• Think of models as very junior employees: be explicit about what is possible and what isn't. Organisational quirks and specific business rules are non-intuitive and need to be spelled out.
• Document and provide explicit business rules rather than relying on the agent to infer them.
• Test with edge cases where common assumptions break down.
• Include specific examples of where common sense diverges from actual policy.
• Flag outputs that make assumptions not grounded in the provided context.

Vague instructions

Instructions are ambiguous, underspecified or open to multiple valid interpretations. The model picks one interpretation without any indication that alternatives exist, potentially diverging from the intended behaviour. Models are trained to be decisive and helpful, so they commit to an interpretation rather than asking for clarification or expressing uncertainty about what was meant.

Examples

• "Be professional" - the agent interprets this as formal when the business prefers friendly-professional.
• "Handle the complaint appropriately" - what counts as appropriate? Apologise? Offer a refund? Escalate?
• "Keep responses short" - is that one sentence, three sentences or a paragraph?
• "Follow our return policy" without specifying what the policy actually is.
• "Use your judgment" without boundaries on which judgments are acceptable.

Mitigations

• Replace vague instructions with specific, measurable criteria.
• Provide examples of correct behaviour alongside instructions.
• Test prompts with multiple people to identify interpretation variance.
• Define edge cases explicitly rather than leaving them to the model's interpretation.
• Use few-shot examples to demonstrate expected behaviour.

Model dumb

Sometimes it's just hard to reason about something, and the model reasoned about it incorrectly. The model correctly identifies what it needs to do but fails in the execution due to limits in its reasoning ability. This is not about missing instructions or context - the model has everything it needs but still produces incorrect output, because the task requires reasoning beyond its capabilities. This is NOT a catch-all for "there were instructions but it didn't follow them." It specifically refers to cases where the model engages with the instruction, attempts to reason through it, and arrives at the wrong conclusion.

Examples

• Complex date arithmetic: "If the return window is 30 days, the purchase was made on January 15th and today is February 16th, is the return still valid?" - the agent calculates incorrectly.
• Multi-step logical inference where the agent loses track of constraints across steps.
• Understanding nuanced language like sarcasm, implicit requests or cultural references.
• Correctly parsing complex nested conditions: "If A and (B or (C and not D))…"
• Timezone conversions, especially with daylight saving time.

Mitigations

• Offload complex calculations to deterministic code or tools rather than model reasoning.
• Break complex tasks into simpler sub-tasks.
• Use chain-of-thought prompting to surface reasoning errors.
• Accept that some tasks may need human review as a backstop.
• Design prompts that reduce the reasoning burden (e.g. provide pre-calculated values).

Poisoned source material

The model correctly retrieves and faithfully represents information from its sources, but those sources contain incorrect or outdated content. This is not a model failure - the agent did exactly what it was supposed to do. The error exists upstream. Debugging often reveals that "the model said X" and the knowledge base also says X.

Examples

• The knowledge base says returns are 30 days, but the policy changed to 14 days and no one updated the docs.
• Help articles reference deprecated features, old pricing or workflows that no longer match the UI.
• A CRM or API returns stale data (an old address, unsynced inventory status).

Mitigations

• Audit knowledge base content regularly, especially after policy or product changes.
• Track "last reviewed" dates on source material to surface staleness.
• Create feedback loops to flag suspected source errors.
• When investigating "hallucinations," check whether the source material itself is wrong before assuming model error.

Other

Not everything fits cleanly into these categories, so there's definitely an "other" category (an escape hatch, HA!). Sometimes models just do things, and we need to figure out why by deeply examining the traces. This category exists for cases that don't fit neatly into the patterns above, where the root cause is unclear, or where multiple factors contributed and it's hard to isolate a single cause. As more "other" cases turn up and patterns emerge, new categories will come out of this bucket. The goal is to document these cases thoroughly and re-categorise them once we understand the underlying cause.