TL;DR
Context Engineering is a methodology that shifts the focus from the wording of a prompt to the completeness of the context around it. Instead of a single request, you assemble a "context package" from five types of information with a fixed priority: what's the authoritative document, what's an example, what's a constraint, what's an evaluation criterion, and what's just background. Each type has a rank, and in a conflict the higher rank wins.
The key insight: most repeat iterations with AI happen not because of a bad prompt but because of incomplete context. You write "draft a sales proposal" and get a generic shell. You try again with a clarification and get something a bit better. On the third pass you finally add the real data, the client's requirements and your own standards, and get a decent result. Three iterations purely because the needed information didn't make it into the first request. And your prompt is always the lowest-priority element: it starts the interaction but doesn't steer the result.
The method fixes this with two things: five roles for classifying everything you hand the AI, and a four-stage pipeline (Reviewer → Design → Builder → Auditor) for complex tasks where one request is obviously not enough.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
CONTEXT PACKAGE (for every request):
Role 1 — Authority: what governs the result → spec, plan, requirements
Role 2 — Exemplar: what it should look like → sample, previous report
Role 3 — Constraint: what's off-limits / critical → word limit, bans
Role 4 — Rubric: how to evaluate → checklist, acceptance criteria
Role 5 — Metadata: request context → your prompt, deadline, names
PRIORITY in a conflict: Authority > Exemplar > Constraint > Rubric > Metadata
PIPELINE (for complex / multi-session tasks):
STAGE 1 — Reviewer: what exists, what's needed, where the gaps are → structured assessment
STAGE 2 — Design: what to build and how → plan / architecture / structure (= Authority)
STAGE 3 — Builder: build to the plan → finished result
STAGE 4 — Auditor: check against the plan → list of fixes + where to send it back
Each stage is a separate request (or session, for big projects).
For simple tasks: Builder alone, or Builder + Auditor, is enough.
Example in Practice
Task: Mark is a B2B sales rep at a SaaS company. He needs to write a sales proposal for a specific client, a large distribution network. He used to give ChatGPT the task "write a proposal," get a template shell, and rewrite it three times. Now he assembles a context package.
Prompt:
You are the Builder. Your job is to create a sales proposal strictly according to the plan below.
You don't interpret requirements or make architectural decisions —
those have already been made. Your job is execution.
=== AUTHORITY (priority 1 — governs everything) ===
PROPOSAL PLAN:
1. Headline: the client's specific pain, not the product name
2. The client's current situation: 2 paragraphs, facts
3. What we offer: no passive voice, no "solutions"
4. Three concrete outcomes with numbers
5. Case study of a similar client: volume, timeline, ROI
6. Next step: one action, not "get in touch with us"
Requirements: no "synergy," "ecosystem," "innovative."
Length: no more than 600 words.
=== EXEMPLAR (priority 2) ===
Tone sample: [paste a paragraph from your best proposal, or a competitor's proposal you like]
=== CONSTRAINTS (priority 3) ===
- Don't name competitors
- Don't promise timelines without the manager's sign-off
- The client is a distributor, not an end consumer
=== RUBRIC (priority 4 — how to judge the result) ===
A good proposal: from the first paragraph the client gets what it's about and why to keep reading.
A bad proposal: starts with "our company was founded in..."
=== METADATA (priority 5 — my context) ===
Client: Eastline Trading Co., home appliance distributor, 47 regional warehouses
Our product: inventory management system, integrates with NetSuite
Client's pain (from the call): data mismatch between the warehouses and NetSuite — up to 12%
Contact: Brian Walsh, VP of Sales
Send deadline: Friday
Result: The model produces a proposal that strictly follows the six-point plan: as the Authority, it overrides any attempt by the model to "creatively interpret" the structure. Banned words and constraints are respected. The tone is matched to the exemplar. If the model drifts (adds a section that isn't in the plan, or writes "our company"), that's not interpretation, that's an error. Then you send the same package to the Auditor: "Check the proposal against the plan. Find every deviation."
Why It Works
The LLM's weakness: the model doesn't know which of the things you passed it matters most. If you wrote "make it shorter" at the end of the prompt but attached a 15-page spec at the top requiring a detailed section, the model may well pick "shorter." It follows the last or most explicit signal, not the most authoritative one.
What the model does well: follow explicit, structured instructions. If you plainly state which document governs, it will follow it. The "spec vs. prompt" conflict disappears as soon as you explicitly declare the priority.
How the method uses this: roles and priorities remove ambiguity. The model doesn't guess; you tell it outright, "this is the Authority, it outranks everything else." The four-stage pipeline removes another problem: trying to solve in one request a task that requires first understanding the requirements, then designing, then building, then checking.
Control levers: - Package size → for simple tasks, Authority + Metadata is enough. Add the Rubric and Exemplar for tasks with high quality bars - Pipeline stages → for an email or a short document, just the Builder. For a report, proposal or article, the full cycle with Reviewer and Auditor - Operator Authority (more below) → formalize your standards once and include them in every chat
Prompt Template
Universal Context Package
You are the {role: Reviewer / Designer / Builder / Auditor}.
{One-sentence description of the task for this stage}.
=== AUTHORITY (priority 1) ===
{Spec / requirements / plan / design doc — whatever governs the result}
=== EXEMPLAR (priority 2) ===
{Sample of the format, tone, structure — a good past version or a gold standard}
=== CONSTRAINTS (priority 3) ===
{What's not allowed. Technical requirements. Hard conditions.}
=== RUBRIC (priority 4) ===
{What a good result looks like. Checklist. Acceptance criterion.}
=== METADATA (priority 5) ===
{Task context: names, dates, background, my request}
What to plug in:
- {role}: Builder fits most tasks; Auditor when you need to check a finished text
- AUTHORITY: the client's spec, your plan, the agreed structure go here. If it clashes with the prompt, it wins
- EXEMPLAR: one paragraph of good text in the right tone beats long explanations
- RUBRIC: phrase it in the negative: "a bad version looks like this: ..."
- METADATA: your usual prompt goes here
Operator Authority: A Standing Document of Your Standards
A separate, powerful tool from the same methodology. Create it once, use it in every chat.
=== MY STANDARDS (Operator Authority v{version number}) ===
Writing style:
- {banned words and phrases: "synergy," "innovative," passive voice, etc.}
- {tone requirements: businesslike / lively / no corporate-speak}
Format:
- {preferences for structure, headings, length}
Priorities:
- Accuracy > speed
- Specifics > generalities
- {your specific rules}
This document is the Authority. It overrides any instructions in the request that contradict it.
Create a file like this, save it, and paste it at the start of every new chat. The model stops guessing your standards from the pattern of your corrections.
🚀 Quick start: paste into the chat:
Here's a Context Engineering template with five context roles.
Adapt it to my task: {your task}.
Ask me questions to fill in each section.
[paste the template above]
The LLM will ask about the Authority (which document governs), an example of the format you want, constraints and evaluation criteria, because without them the context package is incomplete and iterations are inevitable.
Why It Works (the Mechanics)
An LLM processes the whole context at once. When a text contains competing instructions, the model doesn't know which matters more, so it places a statistical bet. Most often it picks the last one in the text or the most explicit. Explicitly declaring priorities removes that uncertainty: you literally say "the AUTHORITY section overrides everything." It's not magic; it's a structured instruction the model follows because it's unambiguous.
The four-stage pipeline works on the principle of separation of concerns. Cramming "understand the requirements + design the structure + write it + check it" into one request is like giving one person the roles of analyst, architect, implementer and tester all at once. Each role needs a different focus and different quality criteria. Split them, and you get better quality at every step.
Limitations
⚠️ Overhead for simple tasks: The full package of five roles and four stages pays off for complex or recurring tasks. For "translate this paragraph," it's overkill. The author says so plainly: if the task fits in one conversation and errors don't require a structural rethink, the Builder alone, without the whole pipeline, is enough.
⚠️ A single data source: The study is based on 200 interactions by one operator with no control group. It's an observation, not a controlled experiment. The author is upfront about it. The results are logically convincing, but not statistically proven on independent samples.
⚠️ Quality of the Authority = quality of the result: The method shifts responsibility from the prompt to the Authority documents. A badly written spec passed as the Authority will produce a bad result, now with top priority. Garbage in, labeled "this governs everything," is garbage out with amplified influence.
⚠️ The Metadata paradox takes a mindset shift: Realizing that your text prompt is the lowest-priority element isn't obvious at first. Out of habit, users stuff everything important into the prompt rather than the Authority.
How They Studied It
The author collected 200 documented interactions with four AI tools (Claude, ChatGPT, Cowork, Codex) over four months of real professional work: documents, code, research. No purpose-built test sets, just live tasks from practice.
The comparison is simple: unstructured interactions (baseline, 50 cases) vs. structured ones with a full context package (200 cases). They measured the number of iterations to an acceptable result and the share of tasks accepted on the first try. Result: the average number of iterations dropped from 3.8 to 2.0, and first-try acceptance rose from 32% to 55%. With iterations allowed, final success was 91.5%.
An interesting detail: 72% of iterations in unstructured interactions were caused by incomplete context, not by a bad prompt but simply by missing information. That's the main takeaway: most repeat requests are requests for things you could have given up front. The researcher also checked the methodology in parallel on a production system with 2,132 tickets, and the results line up.
The main limitation, which the author names himself: one operator, one dataset, no control group. It's an honest observational study, not an RCT.
Original From the Paper
Context package roles table (original):
Role | Priority | Definition | Example
-----------|----------|-------------------------------------------------|---------------------------
Authority | 1 | Grants permission, establishes boundaries, | Requirements document,
| | defines success criteria | design constraint, approval
| | | signature
Exemplar | 2 | Provides patterns or examples for the desired | Previous report, template,
| | output format | successful artifact
Constraint | 3 | Specifies limits, forbidden paths, technical | Word limit, format
| | requirements | specification, API version
Rubric | 4 | Defines evaluation criteria and quality | Definition of done,
| | standards | assessment checklist,
| | | quality gate
Metadata | 5 | Contextual information about the request | Project name, stakeholder
| | and requestor | name, deadline
Context: The author demonstrates how the priority system resolves conflicts between elements, for example when the prompt (priority 5) says "make it 5 pages" while the client's requirements (priority 1) call for 15 pages with 8 sections. The Authority wins.
Adaptations and Extrapolations
1. Adaptation: Operator Authority as an "about me" file for every new chat
The most powerful practical idea in the paper, and it doesn't need the full pipeline.
💡 For any regular use of ChatGPT/Claude: create a document with your standards once and paste it at the start of every new chat. This eliminates "no, not like that" iterations, because "how it should be" now exists before the first answer.
=== MY WORKING STANDARD ===
This is the Authority. It overrides any of my later instructions
that contradict it.
Writing style:
- No words like: "synergy," "ecosystem," "innovative," "narrative"
- No passive voice where it can be avoided
- Short sentences. One paragraph, one idea.
- Address the reader directly as "you," not "one" or "users"
Default format:
- Headings are concrete, not abstract ("How to Shorten the Sales Cycle," not "About Sales")
- Lists only when there are 3+ items
- Answer length: no more than {limit} words unless I ask for detail
Approach:
- Specifics > generalities. If you write "big impact," give an example.
- Don't open answers with compliments or warm-up phrases
Context about me:
- {Profession / role}
- {The audience I usually write for}
- {Specifics of my field that matter}
2. Technique: An Instant Auditor Without the Full Pipeline
🔧 Add an Auditor at the end of any request → get a self-check in a single answer
[your usual request with the context package]
Once you've produced the result, go over it as the Auditor:
Check it against the AUTHORITY point by point.
Find every deviation.
Fix it, or explain why the deviation is justified.
This works because the model simulates a role switch within one request. Not as precise as a full separate stage, but enough for most tasks.
3. Extrapolation: Context Engineering + Chain-of-Thought for complex analysis
The Reviewer role from the pipeline pairs well with Chain-of-Thought (explicit step-by-step reasoning) for tasks where you can't afford to miss hidden requirements:
You are the Reviewer. Read the material below and answer step by step:
Step 1: What's here (facts, data, agreements)
Step 2: What's explicitly required (stated)
Step 3: What's implicitly required (implied but not said)
Step 4: Where the gaps are (what's missing to complete the task)
Step 5: What conflicts exist (contradictions in the requirements)
Output: a structured assessment for the next stage.
=== MATERIAL ===
{text: brief, email thread, spec, meeting notes}
This Reviewer prompt works on its own for any brief or spec, without the rest of the pipeline.
Resources
Context Engineering: A Practitioner Methodology for Structured Human-AI Collaboration Elias Calboreanu — Swift North AI Lab, The Swift Group, LLC, Maryland, USA Contact: [email protected] | ORCID: 0009-0008-9194-0589
Related sources cited in the paper: - Andrej Karpathy on context engineering (June 2025) — [twitter/X] - Tobi Lütke (Shopify CEO) on context engineering - Simon Willison — extending the framework - Sahoo et al. — survey of 44 prompting papers (39 techniques) - Schulhoff et al. — taxonomy of 58 prompting techniques - Mei et al. — survey of 1400+ papers on context systems from the machine side - Anthropic, Google, LangChain — context engineering guides