From Prompt Engineering to Context Engineering

tl;dr

When I first started building with LLMs, I thought the game was all about crafting the perfect prompt. Find the right words, and the model will do what you want. But then I came across Context Engineering: Sessions & Memory whitepaper from Kimberly Milam and Antonio Gulli.

If you're building agentic AI systems that actually need to work in production, this shift in thinking - from prompt engineering to context engineering - might be the most important thing you learn.

---

Context Engineering

LLMs are fundamentally constrained. They have a fixed context window (the maximum number of tokens they can process and pay attention to at once). Everything you want the model to consider has to fit in that window:

• The conversation history.
• System prompts and instructions.
• Tool descriptions and their results.
• RAG-retrieved information.
• The user's current prompt.

The more you shove in context window, the more you risk losing what's called coherence (the model's ability to generate outputs consistent with your goals).

Stuff it full of tools, instructions, and context, and you'll get less predictable, less accurate results. And that is where you start feeling frustrated 😠🥲.

So what's the alternative?

Designe and build dynamic systems that provides the right information and tools, in the right format, at the right time, to give an LLM everything it needs to accomplish a task.

Actually that is what context engineering is all about.

An AI Developer Experience engineer at Google called Philipp Schmid DeepMind popularized this in his seminal blog post The New Skill in AI is Not Prompting, It's Context Engineering.

The Context Engineering visualizes the problem beautifully, showing everything you pack into your input context:

The elements that make up your context include:

• Instructions/System Prompts: which are initial settings and rules that define basic AI behavior.
• User Prompts.
• Short-term memory: the flow of the conversation.
• Long-term memory: user preferences and knowledge from previous interactions.
• RAG: retrieved external data from documents, databases, APIs.
• Available tools: functions the AI can execute.
• Structured output.

Most agent failures are not model failures anymore, they are context failures.

• Philipp Schmid

Schmid estimates that around 80% of agent failures trace back to broken or missing context - not the model itself being inadequate.

---

The Experimentation Mindset

You might be asking: "Okay, so what's the process? What's the step-by-step waterfall for optimizing context?"

There isn't one. In fact if you remember I wrote about this in Prompts Matter in Agentic Workflows
. Even when you do prompt engineering you need to do experiment and measure each change.

Context engineering is fundamentally about R&D, trial and error. Here's the only reliable approach:

1. Metrics: define something that measures how effective your agent is toward your business objective.
2. Experiment: test different approaches, different tool combinations, different ways of using RAG.
3. Measure: compare results against your metric.
4. Iterate: keep what works, discard what doesn't.

BTW do NOT forget to add traceability to your agentic workflow.

---

Subagents: Dividing to Conquer

One of the most powerful techniques in agentic programming is using subagents, breaking your larger agentic problem into smaller, independently testable steps.

So how you should create subagents?

1. Context optimization: if you've got 12 tools equipped to the same model, it might start losing coherence. Group related tools into a subagent, and now your main agent only sees one tool (the subagent itself). Your context window becomes dramatically more efficient.
2. Reusability: Build a subagent once, test it, validate it, and reuse it across multiple agentic flows.
3. Independent testability: Each subagent can be evaluated on its own, making debugging and improvement much easier.

The Trade-off

Subagents reduce flexibility in exchange for reliability. You're constraining how the problem gets solved by organizing it into fixed building blocks. The main agent can't decide to call tools in a different order, it's on rails.

This is a trade-off between autonomy, flexibility and bulletproof reliability.

Subagents in n8n

In n8n, implementing subagents is straightforward using sub-workflows. A sub-workflow can be triggered by another workflow, making it a clean, elegant subagent implementation.

---

The Human Trap -- Anthropomorphizing

One common anti-pattern is anthropomorphizing agents. People create agents with human-like roles (Analyst, Strategist, etc.) because "that's how the org is structured."

This is backwards. Divide into subagents because it:

• Gives you independently testable steps.
• Improves your evals.
• Fixes a specific context problem.

Not just because it sounds like human responsibilities.

---

The Lethal Trifecta -- The Security Vulnerability You Must Know

This is the one vulnerability unique to agentic AI, and it was popularized by the Simon Willison.

Simon coined the term "lethal trifecta", three capabilities that, when combined in a single AI agent, create a near-guaranteed path to exploitation through indirect prompt injection.

1. Access to private data: the agent can see sensitive information (bank accounts, sales numbers, API keys).
2. Ability to communicate externally: the agent can give information to someone other than you.
3. Exposure to untrusted content: some of the agent's input comes from sources you don't control.

Any two of these might be fine on their own. Many systems handle private data and have multiple users. Many systems communicate externally. Many systems ingest untrusted content.

But all three together? That's where the vulnerability emerges.

The untrusted content could contain instructions that deceive your LLM into exposing private data to a third party. And because LLMs are non-deterministic, you can't simply "patch" this vulnerability like you would in traditional software.

The only way to reliably prevent this attack is to cut off one of the three legs. Generally the easiest leg to remove is the ability for the LLM agent to transmit stolen data back to the attacker (AKA exfiltration vector).

A real-world example was when GitHub built an MCP server that allowed agents to read and write from both public and private repos. It ticked all three boxes.

What Makes a Strong Agentic Solution?

Category	❌ Anti-Pattern	✅ Best Practice	Why It Matters
Starting Point	Solution-Focused: "I want an agent to write emails."	Problem-Focused: "We are losing leads because follow-ups are slow. We need to reduce response time from 24h to 1h."	Ensures you build a tool that actually solves a business pain, not just a cool demo.
Agent Identity	Anthropomorphization: "Act like a senior sales manager with 20 years of experience."	Functional Role: "Act as a data processor. Extract contact info, check CRM status, and draft a follow-up."	Prevents the agent from mimicking human "personality" which leads to unpredictable or hallucinated advice.
Success Criteria	Vague Outcome: "Make the emails sound professional."	Quantifiable Metric: "Achieve a 15% reply rate on automated emails."	"Professional" is subjective; "15% reply rate" is measurable and verifiable.
Content Goal	Generation as Goal: "Generate a 10-page market strategy report."	Accuracy & Verification: "Analyze Q3 sales data, identify top 3 growth drivers, and cite specific data sources for each."	LLMs are great at sounding plausible but bad at being accurate. You must force verification.
Testing	Human Review Only: "I'll read the output and see if it looks right."	Rigorous Automated Testing: "Run 1,000 test cases. If accuracy < 95%, add a verification tool or rule."	Humans miss subtle hallucinations. Automated tests catch errors at scale before deployment.
Control	Autonomous "Thinking": "Let the agent decide the best price to offer the customer."	Tool-Based Execution: "Agent calculates price based on margin rules. Human approves any discount > 10%."	Removes the risk of the agent making expensive, unauthorized decisions based on "guesses."
Scope	Broad & Open-Ended: "An agent that handles all customer support."	Narrow & Concrete: "An agent that handles only password resets and billing status checks."	Narrow scope reduces error rates and makes it easier to prove the agent works.