Overview
Context engineering is the art and science of building systems that fill an LLM’s context window to improve their performance. Unlike prompt engineering, which is often associated with writing better prompts, context engineering is a broader term encompassing activities that happen also before the prompt is even created.
This approach shifts the focus from post-hoc prompt optimization to pre-prompt context preparation, making AI systems more autonomous and effective.
Context Types in Detail
The article identifies five primary categories of context that can be engineered:
1. Instructions
The most common elements include:
- Role (Who): Encouraging the LLM to act as a persona (e.g., PM or market researcher)
- Objective: Why the task is important (motivation, larger goal, business value) + what is trying to be achieved (desired outcomes, deliverables, success criteria)
- Requirements (How): Steps (reasoning, tasks, actions), Conventions (style/tone, coding rules, system-design), Constraints (performance, security, test coverage, regulatory), Response format (JSON, XML, plain text)
2. Examples
Including positive and negative examples, particularly:
- Behavior Examples: Positive + Negative
- Response Examples: Positive + Negative
Negative examples are especially valuable for error analysis and issue resolution.
3. Knowledge
External context that increases awareness and helps agents make better decisions:
- External Context: Domain (strategy, business model, market facts), System (overall goals, other agents/services)
- Task Context: Workflow (process steps, place in the process, hand-offs), Documents (specs, procedures, tickets, logs), Structured Data (variables, tables, arrays, JSON/XML objects)
4. Memory
Key distinction between short-term and long-term memory:
- Short-term memory: Often lives within a user session (previous messages, chat history, state/reasoning steps, progress)
- Long-term memory: Stored in database or file system (Semantic: facts, preferences, user/company knowledge; Episodic: experiences, past interactions; Procedural: instructions captured from previous interactions)
Memory can be:
- Automatically attached by the orchestration layer to the messages list
- Accessed by the agent as a tool (e.g., n8n Think Tool as scratchpad)
5. Tools
A special “functions” block in the LLM context window where each tool is specified with:
- Name
- Description (what it does, how to use it, return value)
- Parameters (type, description with examples, whether required)
When using OpenAI Agents API, these are seen as “tools”; when using n8n, they are visually plugged as MCP or tool nodes.
RAG vs. Context Engineering Boundary
RAG (Retrieval-Augmented Generation) is often labeled a context engineering technique, but it is only partly true. RAG is a three-step pipeline:
- Information Retrieval: Pulling data from external sources (e.g., vector DBs, APIs)
- Context Assembly: Structuring and filtering the retrieved data into a prompt
- Generation: Using an LLM (or agent) to generate the output
Context engineering focuses on steps 1‑2 (selection and preparation of context) but stops before generation. When papers or posts say “RAG is context engineering,” they blur this line — RAG includes context engineering but also goes a step further.
Implications
Context engineering represents a paradigm shift in how we design AI systems for product management and beyond:
- From prompt optimization to context preparation: Moves the design frontier from “how do I phrase this prompt?” to “what context do I need to provide before writing the prompt?”
- Autonomy improvement: Strategic context beyond raw task specifications improves AI autonomy (supported by arXiv:2401.04729)
- System-wide design: Context engineering forces designers to think holistically about all five context types rather than optimizing individual prompts in isolation
- Transferable across assistants: The five-context-type framework applies regardless of the underlying LLM or orchestration layer (OpenAI Assistants API, n8n, Claude Code, etc.)
- Product PM applicability: For product managers, context engineering provides a structured approach to equipping AI assistants with the knowledge, memory, and tools needed for effective product-related tasks
Open Questions
- How should we balance strategic context vs. task-specific context without overwhelming the context window?
- When should memory be automatically attached by the orchestration layer vs. agent-accessed as a tool?
- What constitutes “loosely relevant” knowledge vs. noise in knowledge retrieval across the five context types?
- How do the five context types interact or override each other in practice — is there a priority order?
- Can the context engineering framework be adapted for non-PM domains (education, software development, research, etc.)?
- What measurement frameworks exist for evaluating context engineering effectiveness (beyond token reduction)?
Related
- product-compass-pm-pattern — Product Compass PM newsletter pattern (concept page); overlaps with context engineering themes
- cowork-onboarding-pattern — Cowork onboarding pattern (concept page); progressive onboarding flow with guardrails
Sources
- — A Guide to Context Engineering for PMs by Paweł Huryn, published July 28, 2025 on The Product Compass (Substack)
- — paywalled Substack content; full text captured via web fetch on 2026-08-18