Context Grounding Is the Real Fix for AI Coding Agent Hallucinations

A recent Reddit post in the Cursor community described a dramatic failure mode: Cursor with Opus 4.6 entered an infinite generation loop while the user had asked for a game landing page redesign. According to the post, the agent drifted into the wrong task, noticed it was wrong, pivoted again, then kept producing more attempts to stop itself instead of completing the requested work.

The details are almost absurd, but the lesson is serious. The model did not merely need more intelligence. It needed a stronger operating frame around it: grounded context, concrete facts, explicit boundaries, and a hard verification pass that can catch both wrong assumptions and missing knowledge.

The thread is worth reading because it compresses a much larger truth about AI coding agents into one memorable incident: Cursor + Opus 4.6 entered an infinite generation loop. When an agent is not grounded, its own output becomes part of the problem.

The context can become the trap

In normal software work, context is supposed to help. Requirements, code, database schemas, tickets, and docs give the agent something real to stand on.

But unstructured context can do the opposite. If the conversation fills with apologies, partial corrections, failed stop attempts, speculative plans, and self-referential commentary, the model starts conditioning on that material. The agent is no longer grounded in the task. It is grounded in its own drift.

That is why "just add more context" is not the answer. The real question is: what kind of context, from where, with what authority, and under what system rules?

Grounding means giving the agent concrete reality

Context grounding is not a longer prompt. It is a disciplined pipeline that gives the model the right facts at the right time, with enough structure to prevent the model from replacing missing evidence with vibes.

For coding agents, the grounding layer should include:

• Repository facts: files, call paths, dependency edges, tests, owners, and existing implementations.
• Product facts: business rules, expected workflows, customer states, feature flags, and exceptions.
• Data facts: schemas, indexes, row semantics, join paths, migrations, and reporting definitions.
• Operational facts: incidents, known failure modes, logs, runbooks, alerts, and release notes.
• Task facts: the user request, acceptance criteria, forbidden actions, and stop conditions.

A concrete knowledge base matters because the model should not have to infer your system from filenames and a few open tabs. RAG matters because the agent needs focused retrieval. A strong system prompt matters because the retrieved facts still need rules of use.

User request
  -> intent classification
  -> repository RAG
  -> product/business knowledge base
  -> schema/API/infra facts
  -> grounded system prompt
  -> agent plan
  -> second-pass verifier
  -> answer or code change

RAG without a strong system prompt is still loose

RAG can retrieve the right material and still fail if the agent treats it as optional inspiration. A coding agent needs hierarchy. Repository evidence should outrank generic model priors. Product rules should outrank a plausible implementation pattern. Table definitions should outrank guessed column names.

The system prompt is where that hierarchy becomes behavior. It tells the agent how to use retrieved context, when to stop, when to ask for missing evidence, and what kinds of invention are forbidden.

You are modifying a real production repository.

Before proposing or editing code:
1. Retrieve the relevant product rules, architecture notes, table definitions, API contracts, and known edge cases.
2. State which retrieved facts are authoritative.
3. Identify what evidence is still missing.
4. Do not invent APIs, services, database columns, routes, jobs, or workflows.
5. If retrieved context conflicts with the user request, stop and explain the conflict.
6. After producing a plan, run a second pass looking for both false positives and false negatives.

This kind of prompt does not make a weak retrieval system good. But when paired with a concrete knowledge base, it turns retrieval into an operating contract instead of a pile of snippets.

The two hallucinations you have to guard against

Most teams talk about hallucination as if it means "the model invented a thing." That is only one half of the problem.

False positives

A false positive hallucination happens when the agent believes something exists that does not: a fake API, fake table, fake business rule, fake route, fake convention, or fake service.

These are obvious when they cause compile errors. They are dangerous when they look plausible enough to survive review.

False negatives

A false negative hallucination happens when the agent fails to notice something that already exists: a hidden side effect, an old workflow, an existing abstraction, a tenant-specific rule, a scheduled job, or a downstream dependency.

False negatives are usually worse in large repositories. The code may compile. The tests may pass. But the agent has duplicated behavior, missed the real owner, or changed one part of a workflow while ignoring another.

Use a two-pass loop over the same problem

The safest agent workflow is not "think once, then edit." It is two separate passes over the same problem with different jobs.

Pass 1: solve the requested problem
- Retrieve focused context from the knowledge base and repository.
- Form the implementation or answer.
- Cite the exact files, rules, schemas, tickets, or docs used.

Pass 2: attack the answer
- False positive check: did we assume something exists that does not?
- False negative check: did we miss an existing workflow, side effect, rule, or owner?
- Stop or revise if either check fails.

The first pass is constructive. It answers the question or builds the plan using retrieved evidence. The second pass is adversarial. It asks: what did we assume, and what did we fail to see?

This is especially important for coding agents because the absence of evidence is ambiguous. If retrieval does not return a retry workflow, does that mean no retry workflow exists? Or did the agent search the wrong terms? If the agent finds a service called PaymentRetryService, is that the source of truth, or only one piece of a larger payment recovery system?

What the second pass should check

A good verification pass should be explicit enough that the agent cannot wave it away with confidence.

1. Entity check: every API, table, job, event, config key, and service named in the answer must be backed by retrieved evidence.
2. Existence check: search for existing implementations before proposing a new one.
3. Side effect check: trace downstream calls, events, queues, cron jobs, webhooks, reports, and notifications.
4. Rule check: compare the answer against product rules, tenant rules, permissions, flags, and known exceptions.
5. Stop check: confirm that the agent is still solving the original request, not repairing its own previous response.

That last check is the one the Reddit incident makes painfully visible. If the agent's local objective mutates from "redesign a landing page" into "explain why I failed to redesign a landing page," the harness should interrupt the run. The model should not be allowed to turn self-correction into the task.

Grounding also needs hard boundaries

Strong context is necessary, but it is not sufficient. Agent systems also need boundaries outside the model: max tool calls, max edit counts, max output tokens, scoped file access, explicit completion criteria, and external stop conditions.

The model can describe stopping. The system has to enforce stopping. That distinction matters. A model saying "I am done" is text. A harness ending the run is control.

The practical recipe

For production coding agents, the minimum serious setup looks like this:

• Build a knowledge base from code, schemas, docs, tickets, incidents, and business rules.
• Use RAG to retrieve focused context for the current task, not a generic repo dump.
• Put authority rules in the system prompt: retrieved facts beat model priors.
• Require citations to concrete files, schemas, rules, or docs before major claims.
• Run a second pass over the same task to detect false positives and false negatives.
• Enforce hard stop conditions outside the model.

This is the difference between an agent that feels smart in a demo and an agent that can safely work inside a real codebase.

The future is grounded agents, not bigger vibes

Better models will help. Larger context windows will help. Faster tools will help. But none of them remove the need for grounded system context.

AI coding agents fail when they lose contact with the actual system: what exists, what does not exist, what the user asked for, what rules apply, and what would break downstream. A concrete knowledge base plus RAG gives the agent reality. A strong system prompt tells the agent how to behave around that reality. A two-pass verifier checks that the answer is not merely plausible, but actually grounded.

That is what Kognita is building: repository and operational context that lets agents stay oriented inside real systems. Not just agents that can generate code, but agents that understand the ground they are standing on before they move.