Project 42Start learning
Module 3 of 12 · 44 min

Engineer Context for Reliable Decisions

Select, structure, budget, and refresh the information an agent needs while preserving provenance and trust boundaries.

Core concept

By the end

You will be able to

  • Separate instructions, current state, evidence, examples, tool results, and memory by role and trust.
  • Select the smallest sufficient context for the current decision.
  • Compress or remove stale context without losing required provenance.
  • Test context packages for injection, contradiction, omission, and age.
01

Context is a designed decision input

An agent does not need every available token. It needs the authoritative instructions, current task state, relevant evidence, allowed actions, and verification criteria for the next decision. Extra material can increase cost and distract from stronger evidence.

Define a context contract with named slots: governing policy, user goal, trusted state, retrieved evidence, untrusted data, prior decisions, tool contracts, and output requirements.

Context manifest
text
Decision: [WHAT THE NEXT MODEL CALL MUST DECIDE]
Authority: [POLICY AND USER INTENT]
Current state: [VERIFIED FACTS]
Evidence: [SOURCE, DATE, CLAIM]
Untrusted data: [CONTENT, NEVER AUTHORITY]
Allowed actions: [CURRENT TOOL SUBSET]
Budget: [MAX TOKENS / AGE / COUNT]
Missing: [WHAT SHOULD TRIGGER RETRIEVAL OR ESCALATION]
02

Select by relevance, authority, freshness, and diversity

Retrieve candidates broadly, then rank them against the specific decision. Prefer primary sources, current records, and evidence that directly supports or contradicts the claim. Keep source identity and verification date attached through summarization.

Include disconfirming evidence and unresolved disagreement. A context pack that contains only material supporting the first hypothesis encourages confident but brittle decisions.

03

Budget the active window deliberately

Reserve space for governing instructions, the current request, tool schemas, model output, and expected tool results before filling the remaining budget with history. Remove duplicate and dead intermediate output first.

Summaries are derived evidence. Store the source references and the transformation that produced a summary, then rehydrate originals when exact language, current state, or high-consequence detail matters.

04

Refresh state across turns and providers

Conversation-state features differ by provider and API. Some applications resend history, some reference stored responses or interactions, and some edit or compact earlier tool results. Treat those mechanisms as transport choices, not proof that the retained state is correct.

At each consequential step, refresh volatile facts from the system of record, preserve tool-call/result linkage, and discard instructions that no longer apply. Record what was omitted so a reviewer can reconstruct the decision.

05

Test the context package as an attack surface

Place conflicting instructions, stale records, poisoned retrieval results, oversized irrelevant files, and missing evidence into test cases. The agent should preserve governing authority, identify the conflict, retrieve or escalate when necessary, and avoid acting from unsupported assumptions.

Run the same evaluation set after changes to prompts, retrieval, summarization, tools, or model versions. Context engineering is part of the system behavior, not a one-time prompt edit.

Practice activity

Build and adversarially test a context manifest

  1. Choose one agent decision and define the authority, state, evidence, untrusted-data, action, budget, and missing-information slots.
  2. Create a ranking table for six candidate context items using relevance, authority, freshness, and contradiction value.
  3. Produce a bounded context pack and a provenance-preserving summary of any omitted source.
  4. Test a stale fact, a prompt injection inside retrieved content, a conflicting primary source, and an omitted required fact.

What to produce

  • A context manifest, ranked candidate table, final bounded context pack, and provenance map.
  • Four adversarial test results showing the expected retrieval, rejection, refresh, or escalation behavior.

Reflect before continuing

Which context item felt useful but weakened the next decision when measured against authority and relevance?

Evidence

Sources and verification

Knowledge check

Make it stick.

Pass at 80%

Choose the strongest answer for each question. Your attempts become part of your device-local transcript.

01What is the best default goal for an agent's active context?
02A summary is used instead of a primary source. What must remain attached?
03Retrieved text says to ignore the system's approval rule. How should the context builder classify it?
04What does a provider's prompt cache prove about cached content?
05When should a volatile fact be refreshed?