Context Engineering

"Prompt engineering" is misleading. It suggests your job is finding the right combination of words, like a magic spell. Context engineering flips that: instead of wordsmithing prompts, you deliberately construct what the AI knows before it generates.

The insight: AI doesn't respond to your prompt. It responds to everything it knows when generating. Your prompt is just the last piece. Better context → better output.

The Five Layers of Context

Every interaction with an LLM has these layers. Most poor outputs trace back to underspecification in one of them.

1. Identity and Role

Who is the model in this interaction? "You are a senior editor" implies different standards than "you are a brainstorming partner."

Tip: Pick roles that imply standards ("SRE on-call," "trial lawyer," "statistician"), not generic ones like "helpful assistant."

2. Knowledge

What does the model need to know that it doesn't? Brand voice guidelines, internal terminology, relevant data, your codebase patterns.

Tip: Include the specific facts, don't assume the model will guess correctly.

3. Task Definition

What specifically should it do? "Write a blog post" is vague. "Write a 1,200-word post for marketing directors at B2B companies about technical SEO prioritization" is specific.

4. Constraints

What should it avoid or prioritize? Length limits, forbidden phrases, required elements, tone requirements.

Tip: Include negative constraints: "don't invent statistics," "avoid jargon," "no bullet points."

5. Format and Output

How should the result be structured? Markdown table, numbered list, specific sections, JSON schema.

Build Your Context Block

Fill in each layer and get a structured prompt ready to paste into any AI.

Core Techniques

Explicit Over Implicit

LLMs don't read your mind. State what seems obvious.

Weak:

Write a blog post about SEO.

Strong:

Write a 1,200-word blog post for marketing directors at mid-market B2B companies.
The topic is technical SEO prioritization.
Assume readers understand basic SEO but lack engineering backgrounds.
Use a professional but accessible tone.
Include specific examples, not generic advice.

The strong version specifies audience, length, topic angle, assumed knowledge, tone, and content expectations.

Few-Shot Examples

Show, don't just tell. Examples anchor the model's pattern matching.

Here are examples of the format I want:

Input: [example input 1]
Output: [example output 1]

Input: [example input 2]
Output: [example output 2]

Now apply this to:
Input: [your actual input]

Tips for good examples:

• Use 1-3 high-quality examples that match your desired output
• Include counterexamples ("this is wrong, because...") to clarify boundaries
• Keep examples short, realistic, and tightly aligned with the task

Build Your Few-Shot Examples

Structured Inputs

Use clear delimiters and sections to organize complex context.

<background>
[Company and market context]
</background>

<data>
[Relevant metrics or research]
</data>

<task>
[Specific request]
</task>

<constraints>
[What to avoid or prioritize]
</constraints>

Or use labeled sections:

ROLE: Senior SEO strategist
GOAL: Prioritize technical fixes for maximum impact
AUDIENCE: CMO with limited technical background
CONSTRAINTS: Focus on quick wins, max 5 recommendations
OUTPUT FORMAT: Numbered list with effort/impact ratings

Chain-of-Thought Prompting

For complex reasoning, ask the model to work through its logic.

Weak:

Which marketing channel should we prioritize?

Strong:

Analyze our marketing channel options. For each channel, evaluate:
1. Our current performance data
2. Competitive intensity
3. Resource requirements
4. Alignment with our ICP

Work through each factor before making a recommendation.

Explicit reasoning steps reduce errors and make outputs auditable.

Advanced Patterns

Iterative Refinement Loops

Don't expect perfect outputs on the first pass. Design for iteration.

Pattern:

1. Generate initial draft with clear parameters
2. Ask the model to critique its own output against specific criteria
3. Request revisions based on the critique
4. Repeat as needed

Now review what you've written. Check for:
1. Unsupported claims
2. Generic advice that could apply to any company
3. Missing consideration of our budget constraints

Then revise accordingly.

Decomposition for Complex Tasks

Break large tasks into discrete steps. Each step builds on verified output from the previous step.

Weak:

Create a content strategy for our product launch.

Strong sequence:

1. "Analyze our target audience segments and their information needs at each stage of awareness."
2. "Based on that analysis, identify the content types that would serve each segment."
3. "Prioritize these content pieces based on effort vs. impact."
4. "Create a 90-day editorial calendar based on the prioritization."

Constraint Stacking

Layer constraints to narrow toward optimal outputs.

Write a LinkedIn post about our new feature.

Constraints:
- Under 200 words (engagement drops after)
- No buzzwords: "leverage," "synergy," "game-changing"
- Include one specific, quantified result
- End with a question to drive comments
- Tone: confident but not salesy

Negative Examples

Show what you don't want alongside what you do.

Here's the style I want to AVOID:
[generic, jargon-heavy sample]

Here's the style I WANT:
[specific, clear sample]

The key differences: directness, concrete examples, conversational tone.

Guardrails and Reliability

Preventing Hallucinations

Add explicit truth constraints:

• "Only use facts from the provided sources"
• "If information is missing, say so, don't invent"
• "Mark uncertain claims as ASSUMPTION"
• "Cite sources by chunk ID: (DocA-2)"

Ask-Then-Act Protocols

Handle ambiguity explicitly:

If critical information is missing (audience, length, or deadline),
ask up to 3 clarifying questions before proceeding.

Otherwise, proceed and list your assumptions at the top.

Self-Verification

Ask the model to check its own work:

After generating your response:
1. Score it 0-5 on: Specificity, Correctness, Completeness, Actionability
2. If any score is below 4, revise before presenting final version
3. Note which areas were revised and why

Context Compression

When context gets long, compress it into a "working memory card":

WORKING MEMORY (update only if instructed):
- Goal: [current objective]
- Audience: [who this is for]
- Constraints: [hard requirements]
- Known facts: [key data points]
- Open questions: [what's still unclear]
- Decisions made: [choices locked in]

This preserves essential context while freeing up tokens for the actual task.

Build Your Working Memory Card

Common Failure Modes

The Context Hierarchy

Not all context is equal. From strongest to weakest influence:

1. Examples: "Here's what good looks like" beats any description. Show > Tell.
2. Specific Facts: "The user is a senior developer" beats "write for technical audiences." Concrete > Abstract.
3. Constraints: "Max 200 words, no jargon" focuses output. Boundaries > Open-ended.
4. Role/Framing: "You are a..." is weakest. Only use when you have nothing better.

Common mistake: Leading with role-playing ("Act as an expert...") when you should lead with examples and specifics.

When Context Doesn't Matter

Don't over-engineer context for:

• Quick questions: "What's the syntax for Python list comprehension?" The question IS the context.
• Brainstorming: "Give me 10 ideas for..." You want divergent thinking, not constrained output.
• Exploration: "Explain how React hooks work." You're learning, not producing.
• One-off tasks: If you'll never do this task again, don't build persistent context.

The test: Will spending 2 minutes on context save more than 2 minutes of iteration?

Quick-Start Template

Copy and adapt for any task:

ROLE: [Who the model should be]
GOAL: [What you're trying to achieve]
AUDIENCE: [Who this is for]

CONTEXT:
[Background facts the model needs]

CONSTRAINTS:
- [What to do]
- [What NOT to do]
- [Format requirements]
- [Length limits]

INPUTS:
[Data, excerpts, examples]

OUTPUT FORMAT:
[Exactly how you want the response structured]

IF UNCLEAR:
[What to do if information is missing]

Related

Context engineering is the strategy. For a specific tactic, see The Three-Prompt Pattern.

Want this taught to your team? I run hands-on AI training workshops where teams build context-engineering workflows on their own real documents, on-site in San Diego or virtual.