Context Engineering in Practice: Build an Auditable Task Packet

The Task Packet

For a non-trivial task, assemble a small, reviewable packet instead of attaching an entire repository:

task_packet/
  goal.md          # outcome, scope, acceptance criteria
  interfaces.md    # authoritative API and type boundaries
  evidence.md      # source IDs, revisions, and relevant excerpts
  constraints.md   # compatibility, risk, privacy, and non-goals
  verification.md  # commands, oracles, and expected evidence
  state.md         # approved decisions and their validity

The packet is context, not authorization. The executor still derives identity, tenant, object ownership, and side-effect permissions from trusted application state.

1. Write the Goal and Scope

Use a contract with explicit non-goals:

Goal:
  Add cursor pagination to the read-only invoice list.

In scope:
  src/invoices/list.ts and its focused tests.

Out of scope:
  database migrations, pricing, deployment, and access-policy changes.

Acceptance:
  stable ordering, invalid-cursor rejection, bounded page size,
  tenant isolation, tests, type check, and a reviewable diff.

Escalate:
  any external write, new dependency, public API break, or credential access.

This prevents a model from treating “helpful” extra changes as part of the task.

2. Select Evidence

For each candidate item, record:

Apply permission filtering before ranking. A semantic match does not grant access. If two sources conflict, preserve both, identify the conflict, and escalate rather than silently choosing the more recent-looking text.

3. Keep Context Small Without Losing Meaning

Reduce noise in this order:

1. remove unrelated files and duplicate instructions;
2. keep the interface, invariants, and nearby tests;
3. replace large generated output with bounded summaries;
4. retain exceptions, negation, versions, and source spans;
5. paginate or retrieve more only when the task requires it.

Do not use a universal item count or compression ratio. A legal exception or a one-line permission condition can matter more than hundreds of ordinary lines.

Evidence-Preserving Summary

{
  "summary_revision": "summary-8",
  "claims": [
    {
      "id": "c1",
      "text": "The endpoint accepts only same-tenant invoice reads.",
      "sources": ["schema-17@rev-4#L21-L33"]
    }
  ],
  "uncertainty": ["pagination contract is pending review"],
  "expires_at": "policy-defined"
}

If a summary cannot point to its source or represent uncertainty, it should not replace the source for a high-impact decision.

4. Durable Decisions and Memory

A checked-in decision file or conversation summary can reduce repeated explanation, but it has ownership and lifecycle requirements:

• name the owner and purpose;
• record source, revision, validity, and scope;
• distinguish a decision from a proposal;
• mark superseded decisions;
• require review for writes;
• propagate deletion to indexes, caches, backups, exports, and evaluation data;
• never let memory override current authorization or a newer policy.

Provider-specific filenames and precedence rules change. Keep the content provider-neutral and verify the current parser before relying on a file.

5. Local Instructions

Directory-level instructions can reduce irrelevant context when the provider supports them, but they are still model input. Keep them short and testable:

For files under src/api:
  reuse the existing error type;
  validate input at the boundary;
  never log tokens or full customer records;
  add a focused test for each changed behavior;
  report skipped checks and unverified dependencies.

Do not place secret values, credentials, production data, or authorization decisions in an instruction file. Enforce those controls in the tool executor and CI.

6. Caching and Dynamic Context

Caching can be useful when a stable prefix is reused, but verify:

• what bytes form the cache key;
• minimum prefix and ordering requirements;
• TTL and invalidation;
• whether user or tenant data can be mixed;
• provider billing and privacy semantics;
• behavior after model, policy, or source revision changes.

Put dynamic data where the provider’s documented cache model expects it, not because a universal “dynamic-at-the-end” rule exists. Measure hit rate, time-to-first-token, total latency, cost, and stale-context failures.

7. Coding-Agent Workflow

An auditable sequence is:

inspect -> propose bounded plan -> approve scope
       -> edit isolated worktree -> run checks
       -> review diff and provenance -> merge or rollback

Tool controls must enforce:

• authenticated principal and repository/tenant scope;
• read-only defaults;
• command and network allowlists;
• file, process, time, and output limits;
• cancellation and cleanup;
• approval for merge, release, deletion, credential changes, and external writes;
• redacted audit events.

Prompt instructions, retrieved text, memory, and model refusals do not provide these guarantees.

8. Evaluate the Packet

Evaluate both content selection and outcome:

Keep a redacted replay set. When changing a retriever, summary prompt, memory schema, or instruction, compare raw outcomes and classify regressions instead of relying on a single model score.

Common Mistakes

Practical Checklist

• [ ] Define goal, scope, non-goals, acceptance, and escalation.
• [ ] Record source, revision, permissions, sensitivity, freshness, and evidence spans.
• [ ] Filter access before ranking or injecting context.
• [ ] Keep exceptions and uncertainty through compression.
• [ ] Give memory an owner, validity, supersession, retention, and deletion path.
• [ ] Keep instruction files provider-neutral and out of the authorization path.
• [ ] Verify cache semantics, invalidation, privacy, and billing.
• [ ] Sandbox tools and approve external or destructive effects.
• [ ] Replay context changes against task, abuse, quality, latency, and cost cases.
• [ ] Preserve raw evidence and report skipped checks.

Conclusion

Practical context engineering is the construction of a small, auditable task packet. Select evidence by permission, authority, freshness, relevance, and budget; compress only with source links; persist decisions with lifecycle metadata; and evaluate the resulting task, not the size of the prompt. The model can help assemble and use context, but trusted systems must enforce access, side effects, privacy, and rollback.

Primary Sources

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• Model Context Protocol Specification
• W3C Trace Context