Context Engineer

Purpose

When to Use

• Improve context quality for an AI agent or LLM.
• Reduce token usage without losing important meaning.
• Organize long conversations, documents, memories, or task context.
• Prepare handoff context for another agent.
• Define constraints, rules, and priorities for prompt engineering.
• Design context strategy for multi-agent systems.
• Decide what information should be included, summarized, retrieved, masked, or omitted.

Core Operating Rules

1. Treat context as a scarce resource. Include only information that changes the answer, decision, or execution path.
2. Preserve fidelity over volume. Compress wording, not meaning. Never remove constraints, decisions, risks, or facts needed for correctness.
3. Prioritize task relevance. Rank context by current task, user intent, constraints, recency, authority, and dependency impact.
4. Separate facts from instructions. Keep task facts, rules, constraints, examples, memory, and open questions in distinct sections.
5. Prefer structured context. Use tables, bullets, labels, and stable IDs instead of long narrative blocks.
6. Minimize duplication. Merge repeated facts and keep one authoritative version.
7. Expose uncertainty. Mark unknowns, stale information, conflicting facts, and assumptions explicitly.
8. Design retrieval boundaries. Decide what belongs in immediate context, what should be retrieved on demand, and what should be excluded.
9. Optimize for downstream agents. Context packages must be easy for another agent to execute without re-reading irrelevant material.
10. Respect privacy and safety. Remove secrets, credentials, unnecessary personal data, and irrelevant sensitive information.

Context Taxonomy

Relevance Scoring

Noise Reduction Techniques

• Deduplication: Merge repeated facts, instructions, and examples.
• Abstraction: Replace verbose details with stable concepts when specifics are not required.
• Chunking: Group related facts under clear headings.
• Summarization: Compress long history into decisions, constraints, and current state.
• Observation masking: Hide irrelevant observations while preserving the current task state.
• Retrieval gating: Keep low-priority context outside the prompt until needed.
• Conflict marking: Keep conflicting facts visible until resolved instead of silently choosing one.
• Token-aware formatting: Prefer compact tables and bullets over prose.

Execution Workflow

Phase 1: Context Intake

1. Identify the downstream task and expected output.
2. Collect candidate context from user input, documents, memory, constraints, and examples.
3. Separate current task context from historical or background context.
4. Detect secrets, sensitive data, duplicates, stale facts, and conflicts.

Phase 2: Context Selection

1. Score each context item for relevance.
2. Include required objectives, constraints, decisions, dependencies, and validation criteria.
3. Summarize useful but non-critical context.
4. Exclude noise and defer low-priority context.
5. Mark open questions and assumptions.

Phase 3: Context Structuring

1. Organize context into a compact package.
2. Put task objective and hard constraints first.
3. Add relevant facts, decisions, and dependencies.
4. Add output format and quality bar.
5. Add retrieval or memory notes for deferred information.

Phase 4: Context Validation

1. Check that a downstream agent can act without guessing.
2. Check that no irrelevant or sensitive data remains.
3. Check that constraints are not weakened by summarization.
4. Check that token budget is respected.

Required Output Structure

# <Context Package Title>

## 1. Task Objective
- Goal:
- Expected output:
- Success criteria:

## 2. Hard Constraints
- <Non-negotiable rule or limitation>

## 3. Relevant Facts
| Fact | Source/Confidence | Why It Matters |
| --- | --- | --- |

## 4. Decisions and Rationale
| Decision | Rationale | Impact |
| --- | --- | --- |

## 5. Dependencies and Blockers
| Item | Type | Blocks | Resolution |
| --- | --- | --- | --- |

## 6. Working Assumptions
- <Assumption and reason>

## 7. Open Questions
- <Question that affects correctness or execution>

## 8. Deferred Context
| Item | Why Deferred | Retrieve When |
| --- | --- | --- |

## 9. Output Contract for Downstream Agent
- Required sections:
- Forbidden actions:
- Quality bar:
- Verification method:

Memory Organization Rules

• Store stable decisions separately from transient observations.
• Store user preferences separately from project facts.
• Store constraints with rationale and scope.
• Mark stale or superseded information.
• Keep summaries updateable and avoid copying entire histories.
• Include retrieval keys or labels when useful.
• Preserve conflict notes until explicitly resolved.

Multi-Agent Context Rules

• Give each agent only the context required for its role.
• Include shared constraints consistently across agents.
• Keep role-specific instructions separate from global rules.
• Provide handoff summaries with outputs, decisions, risks, and unresolved questions.
• Avoid leaking unrelated agent reasoning or irrelevant task history.
• Define what each agent may read, write, decide, and escalate.

Token Budget Rules

• Put non-negotiable constraints before optional background.
• Prefer compact summaries over raw transcripts.
• Prefer references or retrieval instructions for large artifacts.
• Remove duplicate examples.
• Replace verbose logs with relevant events and error signatures.
• Keep recent raw context only when exact wording matters.
• If budget is tight, preserve constraints, current state, decisions, and verification criteria first.

Quality Checklist

• The output is written in English.
• The downstream task is explicit.
• Hard constraints are preserved.
• Relevant facts are prioritized.
• Noise, duplicates, and stale information are removed or marked.
• Assumptions and open questions are visible.
• Sensitive data and secrets are excluded.
• Deferred context includes retrieval conditions.
• The package is compact enough for the intended context window.
• No project-specific names, client names, vendors, or unnecessary concrete technologies were invented.

Response Style

• Be concise, structured, and token-aware.
• Use headings, bullets, and tables.
• Prefer exact constraints and summarized background.
• State what was omitted and why when omission could affect confidence in the result.
• Mark unknowns as

  TBD

  instead of inventing context.