A coding agent searches for the company’s deployment configuration and retrieves a document titled “Production Data Export Settings.” The page is highly relevant to the request. It contains real commands, a realistic example and the right product name. Unfortunately, it describes the US environment, was written before the latest data-retention decision, and includes a proposed change that security never approved. The agent has found the right topic and the wrong instructions.
This is why relevance is not applicability. Retrieval ranking answers “How well does this material match the query?” It does not, by itself, answer whether a person or AI agent should rely on the material for this specific user, project, environment and moment in time.
How a perfect search result produces a bad decision
Semantic search and RAG are valuable because they can recover information even when the user does not know the original terminology. But a similarity score has no native understanding of organizational authority. A document about a previous project may look closer to the query than the short, current exception that truly governs it. The most verbose answer is not necessarily the authorized answer.
Consider a migration task with two documents. Document A gives a complete five-step migration recipe and has been linked from many tickets. Document B is a two-sentence decision approved last week: “Do not use this recipe in EU production until encryption-at-rest validation is complete.” Similarity-based retrieval might prefer A. A reliable context system must allow B to constrain the task even if B has fewer overlapping keywords.
Four independent applicability checks
| Check | Question | Example failure |
|---|---|---|
| Scope | Does this apply to this product, team, environment, customer and task type? | US staging configuration reused for EU production |
| Authority | Was it approved, merely proposed or explicitly rejected? By whom? | Meeting suggestion treated as company policy |
| Freshness | Is it still current? Was it superseded, reopened or subject to an expiry? | Old exception reused after a security review |
| Permission | Is this actor allowed to inspect and use this information? | Support agent receives a private security investigation |
These checks are not interchangeable. A record can be current but inaccessible. It can be permitted but never approved. It can be authoritative for one service and irrelevant for another. When evidence is incomplete, a good agent should signal a gap rather than silently treat the closest result as sufficient.
Selection should happen before context is sent to an agent
A practical context pipeline begins with a task frame, including actor identity, objective, repository, project, environment and requested action. It then considers potential evidence and knowledge. Before assembling the context package, it evaluates access, scope, lifecycle and authority. The output should be a small set of applicable records, accompanied by sources and reasons for inclusion or exclusion when available.
This ordering matters. If a context assembler first dumps private, stale and contradictory text into a model prompt, a warning sentence added afterward may not reliably neutralize the conflicting instructions. Upstream selection is a stronger design than expecting the model to disregard everything it should never have received.
The system should not confuse two evaluations: “May the user read this source?” and “Is this source an approved instruction for the user’s task?” Both are necessary, but they answer different questions.
A diagnostic walkthrough
Imagine a security-sensitive task: “Modify logging for the EU payments service.” Three search hits arrive:
- A 2024 logging guideline for all products, high similarity, now superseded.
- An unapproved 2026 migration proposal, also highly similar, visible to the engineer.
- A current reviewed decision for EU payments, shorter but scoped precisely to this deployment.
A purely relevance-driven system might put results 1 and 2 first. A governed selector should recognize result 3 as the applicable instruction, present the others as background evidence only when permitted, and surface any unresolved conflict. The developer—or coding agent acting under that developer’s authority—then has an auditable basis for work.
Where AuzzurA DM fits
AuzzurA DM distinguishes source evidence from candidate interpretations and reviewed knowledge. Its records can retain owners, approvers, evidence links, assumptions, exceptions, scope and lifecycle such as current or superseded. Its task-specific context preparation is designed to deliver the applicable reviewed Decisions, Rules and Skills to humans and connected agents.
The agent may subsequently find new contradictory evidence. That new material belongs in a review path, not in an automatic edit to an approved policy. Nor does DM claim to replace the AI model, the retrieval index or a customer’s own access-control system. Its contribution is the organizational judgment that retrieval alone cannot provide.
Test the failure mode before optimizing search quality
For a real workflow, plant three plausible documents: one current and applicable, one superseded, one current but outside the user’s scope. Ask the system what it selects and whether it explains exclusion. Track wrong-context delivery, not just top-k retrieval relevance. Then test what happens when the approved decision changes between two agent runs.
If this failure mode occurs, improving embeddings alone is unlikely to solve it. Context needs the missing dimensions: applicability, authority, freshness and permissions.
For the broader governance lifecycle, see Context Governance for AI Agents. For the retrieval architecture, see Context Engineering for AI Agents.
Sources and further reading
- Anthropic — Effective context engineering for AI agents
- Google Cloud — Context engineering
- MCP — Authorization security considerations
Put shared context to work.
DM is AuzzurA’s Beta product for human + AI teams. Sign up or sign in through the DM portal.