A coding agent is asked to implement customer-data export. It reads the Jira ticket, retrieves an old architecture page and produces a plausible API. Only during review does someone notice that the implementation violates a newer privacy decision. The agent followed the information it received; the context system supplied the wrong material.
That example captures context engineering: how a system decides what an AI agent needs to know, what it is allowed to know, and what is currently relevant to the task. It starts before retrieval, continues while the agent works, and should leave a trail that explains what happened afterward.
Define the layers before you build the pipeline
An agent’s task frame specifies the goal, actor, environment, acceptance criteria and risk. Operational context includes APIs, schemas and live tool results. Organizational context includes approved policies, architecture decisions, exceptions and standard procedures. Memory can add previous experiences or outcomes when relevant. These layers have different lifetimes and different authority; they should not be poured indiscriminately into one prompt.
In the export example, the task frame should establish which product and jurisdiction are involved, whether the endpoint is customer-facing, and whether the caller is permitted to inspect sensitive data. Without that frame, even excellent retrieval cannot tell which document applies.
The diagram separates the DM-managed context boundary from the external agent runtime. Its arrows follow a specific sequence: a task frame and source evidence feed context preparation; reviewed Rules, Skills and Decisions pass through eligibility checks; Prepare Context delivers the selected bundle to a connected agent. The agent invokes external tools independently. Work outcomes can reach a human reviewer, but only approved changes re-enter durable shared knowledge. The optional Mem0 episodic path is marked as partial and entitlement-gated, while Graphify provides live repository evidence. Not every box connects directly to DM, because DM is not the agent runtime or a controller for outside tools.
Why context engineering begins before retrieval
A retrieval-first architecture asks which documents most closely match the user’s wording. A task-first architecture asks who is working, on what, with what authority and in which environment? Those attributes must be available early enough to influence source eligibility. Otherwise the retrieval engine can return a plausible document that the actor must not see, or a current policy that belongs to another product.
For example, a coding agent may ask for “data export requirements.” Before retrieval, the system should establish whether the task concerns a beta integration or regulated production data, the repo and tenant boundary, and whether the actor has permission to inspect customer-specific records. A broadly relevant export guide from another region is not automatically the right input. Equally, a low-similarity security exception may still be compulsory context.
A robust sequence separates eligible sources, retrieved candidates and approved applicable knowledge. Source evidence may inform a candidate, but approval state should not be inferred from its location in Confluence or from a high embedding score. Keep the original provenance available when summarizing. If scope or authority cannot be established, return an explicit gap to the user rather than quietly filling it with the nearest document.
This is an engineering boundary as much as an editorial one. Eligibility can be tested with adversarial fixtures: an expired rule, a tenant-restricted record, a stale but highly relevant wiki page and a shorter current decision. The assembled task context should include the applicable record and explain, where possible, which competing sources were excluded. See Why Relevant Context Can Still Be Wrong for the distinction between semantic relevance and permissioned applicability.
Step 1: Decide eligibility before exposing material
Eligibility asks: may this user or agent access a source; is it within the task’s product and environment; is it a draft, active, expired or superseded statement; and does the relevant authority own it? This order is logical: a permission-safe search system may fetch identifiers before status checks, but it must not leak forbidden document content into the model just because a keyword matched.
Suppose three documents mention data export: February’s unrestricted draft, March’s incident retrospective, and April’s approved limited-field decision. All three may explain the history. The April decision controls the current API unless a later scoped exception exists. The others remain evidence, not active instructions.
Step 2: Retrieve candidates using the right method
Keyword search finds exact ticket numbers or policy identifiers. Semantic search finds related language. Graph traversal helps follow service dependencies and the records connected to them. An MCP server can expose authorized tools from source systems. None of these, alone, turns relevance into organizational authority.
Use the methods that best fit the task. For a migration affecting a repository, codebase and dependency relationships matter. For a customer-data exception, an approved policy and its effective scope matter more. The system should preserve provenance so that a reviewer can inspect the original material.
Step 3: Compose a small, explicit context package
A task-ready package should contain: the objective and constraints; applicable reviewed Rules, Skills and Decisions; enough evidence and references to justify them; current tool or repository state; and a clear note about unresolved conflicts. It should also record exclusions where they are important to an audit.
A large context window does not solve contradictory instructions. If one passage says “export every field” and another says “exclude identifiers,” the agent needs the approved, applicable boundary, not both lines presented as equally authoritative. When status cannot be resolved, the safe behavior is to ask or escalate.
Step 4: Observe actual work—not merely the prepared prompt
After the agent runs, record what it actually received, which tools it used, which sources were excluded, and whether the result followed the selected constraints. If a failure occurs, identify where: missing source, wrong eligibility, stale context, poor composition, or agent execution. Those are different engineering defects and deserve different fixes.
An agent may discover an unexpected API incompatibility. That outcome could become an episode helpful to later work. But it should not automatically become a global Rule; conditions, version and human review matter when promoting a lesson.
Where DM, optional Memory and Graphify fit
DM’s live reviewed Rules, Skills and Decisions can be used to prepare relevant context for connected human and agent work. Its Mem0-based episodic-memory integration is partial and entitlement-gated; examples of automatically retained episodes must therefore be presented as conditional, not available by default. Graphify-backed repository intelligence is live for codebase, dependency and architecture relationships, providing structural evidence where needed. DM combines the applicable approved context with selected supporting evidence; it is not the agent runtime and does not enforce external tool actions on its own.
For the export task, the important benefit is that the approved privacy restriction is findable, scoped and explainable before implementation. The old design draft can still be consulted for rationale without overriding the current decision.
Test the architecture with an adversarial case
Build a pilot task containing three sources: an attractive but stale proposal, a current approved rule, and a private note. Verify that the agent receives the correct rule, never sees the private text, flags genuine conflicts and produces evidence that it applied the rule. Repeat with a changed environment to test whether context selection adapts.
Measure accuracy, exclusion quality, review burden and context-selection errors—not just retrieval recall or the number of tokens supplied. The purpose is better work, not a larger prompt.
Sources
Illustrative scenario. DM capability maturity and integration boundaries follow the approved website Promotion SSOT.
Put shared context to work.
DM is AuzzurA’s Beta product for human + AI teams. Sign up or sign in through the DM portal.