When an AI-powered feature misbehaves, the reflex is almost always the same: rewrite the prompt. Add another instruction, another example, another "please be careful about." Sometimes that fixes it. Often it does not, because the actual fault sits somewhere the prompt cannot reach. Anthropic's own engineering guidance draws a sharper distinction most product teams have not adopted yet: prompt engineering, context engineering, agent loop design as covered in Building Effective Agents, and what Anthropic calls harnesses for long-running agents are four separate layers of one stack, and each fails in a different way.
This applies to any product team shipping an AI feature, whether the workflow drafts a clinical summary, screens a fintech application, or triages a support ticket. The split is not academic. It changes where you look first when something breaks, and what fixing it actually means.
Most teams collapse everything into "prompting." That collapse wastes debugging time. A workflow that hallucinates a fact, loops forever, or quietly does the wrong thing has a fault somewhere specific, and it is rarely the wording of the system prompt. Separating the layers turns debugging into elimination instead of guesswork.
This is the layer everyone knows: the system prompt, task instructions, examples, formatting rules. Anthropic's own prompt engineering documentation frames this as getting the model to reliably do the right thing when it already has everything it needs. Its failure mode is narrow: ambiguous instructions, missing examples, or a task description that underspecifies the actual decision. If the model had the right information and still got the task wrong, this is often, though not always, the layer to fix.
Context engineering is a distinct discipline from prompting. Anthropic's guide to effective context engineering defines it as curating the optimal set of tokens, retrieved documents, tool outputs, and conversation history the model actually sees during a task. Its failure mode differs from a prompt failure: the model was never wrong about the instructions, it simply never had the fact it needed, or so much irrelevant retrieved content buried the one relevant fact. No amount of prompt rewriting fixes this, because the prompt was never the problem. This layer breaks first as workflows scale past a single call and start pulling from multiple documents or tools.
An agent that calls tools, checks results, and decides whether to continue or stop is running a loop. Anthropic's framework for building effective agents is largely a guide to designing that loop well: when to chain steps, when to branch, when to hand control back to a human, when to stop. Loop failures look distinct from prompt or context failures. The agent has the right instructions and information, but it re-does a completed step, stops too early, or keeps calling the same tool because its stopping criteria are vague. Fixing this means redesigning the control flow, not the wording anywhere in it.
The harness is everything that is not the model: the execution environment, permission boundaries, retry and timeout logic, how tool outputs feed back in, the mechanism for a human to interrupt or approve. Anthropic's guidance on effective harnesses for long-running agents argues this layer becomes the dominant source of reliability, or unreliability, as tasks stretch toward an hour of autonomous work. A harness failure often looks identical to a model failure from the outside: the agent seems to forget something, or takes an action nobody approved. The actual cause is usually a missing checkpoint, an unbounded retry loop, or an approval gate that was never wired up, the piece we covered in agentic products live or die at the approval step.
A professional services firm builds an agent to draft client status reports from project data, email threads, and time-tracking exports. Two weeks in, reports start citing budget figures that are weeks stale, and the team's response is more emphatic prompt language: "Always use the most current budget figure." Nothing changes, because the prompt was never the fault. The retrieval step was pulling a cached export instead of the live feed, a context failure, and the harness had no freshness check on retrieved data, a harness failure. Once the team traced the failure to the right layer, the fix took an afternoon: a timestamp check in the harness and a query fix in the retrieval pipeline. The same misdiagnosis pattern shows up in biotech literature-review agents, fintech underwriting assistants, and media research tools. The domain changes. The four layers and their failure modes do not.
This is Aero's working framework for triaging a misbehaving AI workflow, not an established industry standard. Before touching the prompt, we ask five questions:
Most teams stop at question one. The workflows that get fixed are the ones where someone answers all five before changing anything, the same discipline we described in scaling AI from pilot to production: the failure modes that surface at scale are rarely the ones a demo exposed.
No. Prompt, context, and harness engineering are terms used in Anthropic's own engineering guidance, linked above. The four-layer diagnostic framing here is Aero's practical lens for applying that vocabulary, not a published standard.
Context and harness engineering tend to be underinvested relative to prompt engineering, because prompt tweaks are fastest to try and easiest to demo. Teams running agents past a single exchange usually get more reliability improvement from a harness fix, such as a checkpoint or approval gate, than another round of prompt edits.
No. A stronger model can mask a weak harness or a messy context pipeline for a while, but the failure modes are structural, not a function of model capability. They resurface as the task gets longer, the data gets messier, or the stakes go up.
Diagnosing where your AI workflow is actually breaking, not just where it is easiest to look? Talk to Aero.
AI coding tools are excellent at generating components and terrible at everything that makes a design system a system. Why token architecture, accessibility, and architectural judgment keep design system engineering a human role.
