The model is no longer the variable. The context you assemble, the permissions you grant and the evals you run are the parts you own — and where the failures actually live.
The model is no longer the variable
Every frontier model release makes the same thing true a little more: the model is the part of your system you did not build and cannot control, and it is rarely why your feature is unreliable. The context you assemble, the permissions you grant, and the measurement you run are the parts you own, and they are where the failures live.
Three facts shape everything in this pack.
Reliability compounds against you. A step that succeeds 95% of the time, run twenty times in sequence, produces an end-to-end success rate of about 36%. Nothing is broken in that system. Every individual component is performing well. The architecture is simply wrong for the reliability of its parts. The engineering job is therefore reducing the number of steps and containing errors when they happen — not polishing the prompt at step fourteen.
More context is not better context. Chroma's Context Rot study (Hong, Troynikov and Huber, July 2025) evaluated eighteen frontier models and found that every one of them degrades as input length grows — commonly losing 20–50% of accuracy going from 10,000 to 100,000 tokens, with performance cliffs appearing well before the advertised context limit. The most useful finding is the counter-intuitive one: models often performed better on shuffled haystacks than on logically coherent documents, which means your intuitions about ordering context are not reliable and need to be tested rather than assumed.
The trust boundary does not exist. Prompt injection remains architecturally unsolved. A model receives one undifferentiated token sequence, with no privilege enforcement separating your system prompt from user input from retrieved web content. Agent Security Bench has recorded attack success rates up to 84.3%; the WASP benchmark work characterises the current state as security by incompetence
— attacks fail because agents are not yet capable enough to complete them, which is not a defence that improves over time. OWASP's position, restated publicly through 2026, is that this is unsolved for autonomous agents in high-stakes settings.
Decide the architecture before you write the prompt
Decide Whether Your Task Actually Needs an Agent is first for the same reason the channel prompt is first in the partnerships pack: the answer is frequently no. A single well-specified call, or a deterministic workflow with a model at two steps, beats an agent loop on cost, latency, and debuggability for most tasks. Agents earn their complexity when the path genuinely cannot be known in advance.
Choose the Right Model for a Task and Split Work Between an Orchestrator and Subagents are the other two architecture decisions worth making explicitly rather than by default.
If you want the conceptual background rather than a working prompt, the companion articles AI agent vs workflow vs single call, Multi-agent systems explained and How to build your first AI agent cover the same ground in essay form.
Context is a budget, not a bucket
Given what Context Rot shows, treating the context window as free space to fill is the most common expensive mistake in the field. Budget an Agent's Context Window makes you allocate it deliberately — what earns permanent residence, what gets retrieved per turn, what gets summarised, and what gets dropped.
Design Retrieval That Finds the Right Thing is the upstream half of that: retrieval quality sets the ceiling on everything downstream, and a system that reliably returns the eleventh-most-relevant chunk cannot be fixed with a better prompt. Choose Few-Shot Examples That Actually Help applies the same discipline to examples, which are context too and are frequently the least-examined tokens in a system. Design an Agent's Memory Across Sessions handles what persists between runs — and what should not.
Further reading: What is context engineering, RAG vs tools vs long context, Memory for AI agents, and Few-shot vs zero-shot: when examples actually help.
Design for the security model you actually have
Because there is no trust boundary inside the token stream, security has to be enforced outside it. That is a design constraint, not a hardening step you add at the end.
Scope What an Agent Is Allowed to Do works from the assumption that the model will at some point be persuaded to do the worst thing its permissions allow, and asks what that worst thing is. If the answer is unacceptable, the fix is the permission set, not the prompt.
Harden a Prompt or Agent Against Prompt Injection covers what can be done inside the prompt while being honest that it is mitigation rather than prevention. Design the Tool Surface for an Agent or MCP Server treats the whole set of tools as the real interface — the individual tool description matters, but the surface as a system is what determines whether the agent can be steered somewhere you did not intend. Design a Tool Description for an AI Agent handles the single-tool case.
See also Guardrails and safety for AI agents and How to design tools your AI agent can actually use.
Evals are the bottleneck
Capability stopped being the constraint before measurement did. Most teams shipping AI features cannot answer is this version better than the last one
with anything more rigorous than having tried a few prompts by hand — which means every change is a guess and regressions are discovered by users.
Write an Eval Set for a Prompt or Agent builds the set from real failures rather than from imagined ones. Write an LLM-as-Judge Scoring Rubric makes the judge specific enough to be worth trusting, which mostly means giving it criteria a human could apply consistently. Get Strict Structured JSON From a Prompt covers the output contract, and Work Out Why an Agent Run Went Wrong is the post-mortem for a trace that failed somewhere in the middle.
Companion articles: How to write evals for your AI agent, How to evaluate and test your prompts, and Getting reliable structured output from LLMs every time.
Operations: loops, cost, and the instructions you leave behind
Handle Errors and Retries Inside an Agent Loop addresses a failure mode that surprises people: naive retry loops diverge rather than converge, because the model treats its own failed reasoning — still sitting in the context — as evidence about the problem. A retry that resends the failure without reframing it tends to produce a more confident version of the same mistake.
Cut the Cost and Latency of an AI Feature works through the levers in order of leverage, which is usually fewer steps and smaller context before cheaper models. Write a Project Instruction File for a Coding Agent covers the standing context a coding agent reads on every run — the highest-leverage prompt most engineering teams never write deliberately.
Prompt craft, still
Four prompts here are about the prompt itself rather than the system around it: Diagnose and Improve a Prompt, Write a System Prompt for an AI Agent, Turn a One-Off Prompt Into a Reusable Template, and — for the underlying craft — The complete guide to prompt engineering and Anatomy of a great prompt.
They are deliberately last. Prompt quality matters, and it is the smallest of the levers on this page.
Sources
- Kelly Hong, Anton Troynikov and Jeff Huber, Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma, July 2025
- OWASP Top 10 for Large Language Model Applications
- Agent Security Bench and the WASP web-agent security benchmark, on attack success rates against autonomous agents