Fundamentals · Working methods
Prompt, context, harness, or loop?
Finding the right lever.
DE Auf Deutsch lesen
When an AI agent delivers poor work, the first change usually lands in the prompt. That only helps if the prompt is actually the cause. Maybe a file was missing from the context, the tool was ambiguous, or the agent was allowed to stop before a test ever ran. Prompt, context, harness, and loop name these four distinct sources of failure.
Four questions instead of four buzzwords
A chat with a language model can still be explained almost entirely by the instruction and the text supplied with it. An agent additionally has tools, changes files, gathers new information, and runs across multiple model calls. That creates four questions:
| Area | Working question | Typical change |
|---|---|---|
| Prompt | Is the task described unambiguously? | Goal, boundaries, examples, output format |
| Context | Is the model currently seeing the right information? | Retrieval, history, summarization, tool output |
| Harness | Can the agent act safely and check its own result? | Tools, permissions, sandbox, tests, logs |
| Loop | What triggers the next step, and when does it stop? | Repetition, abort conditions, status, escalation |
This isn't a layered architecture with fixed boundaries. A system prompt belongs to both the prompt and the context at once. A test is part of the harness, but its result can drive the loop. The terms are useful exactly when they lead to a verifiable change.
1. Prompt: Is the task unambiguous?
Instruction
What should the model do in this step?
Levers: goal, relevant boundaries, examples, output format, success criterion
Prompt engineering shapes the instructions the model reads. That includes the user's request, permanently loaded system instructions, and tool descriptions as well. A good prompt says concretely what result is needed and how to recognize it.
An example: "Review the contract" leaves open whether a summary, a risk list, or concrete change suggestions are expected. "Name every notice period with its section, its length, and the earliest possible termination date" can be checked. Two or three typical examples help when the desired format is hard to describe with rules alone.
Prompt problems tend to show up immediately and reproducibly: the model delivers the wrong structure, ignores a clearly nameable constraint, or interprets a technical term differently than the team does. In that case, changing the instruction is a plausible fix. If the model is instead missing the current contract, even the most elegant prompt won't find a notice period.
2. Context: Is the right information present?
Selection
What's in the context window at the next model call?
Levers: retrieval, history, compaction, notes, tool output
Context includes system instructions, message history, loaded documents, tool definitions, and the results of earlier steps. Context engineering decides what of that is kept, reloaded, condensed, or dropped for the next call.
Anthropic describes the goal as the smallest, highest-quality set of tokens that enables the desired behavior. "Small" doesn't automatically mean "short." A missing specification saves tokens and still makes the result worse. Conversely, long logs can bury the one error message that matters and still cost money.
The often-cited "context rot" isn't a fixed threshold at which a model suddenly fails. Performance can decline with long contexts depending on the model, the task, and where the information sits. That's why you should measure with real tasks whether relevant details are still found and used correctly. Window size alone doesn't answer that question.
- Load on demand: search first, then open only the matching files or sections.
- Cap tool output: keep the relevant lines and error messages, trim repeated logs.
- Persist state outside the chat: keep progress, decisions, and open items in versioned files.
- Check compaction: after a summary, verify that open bugs, paths, and decisions are still present.
In a RAG system, chunking, search, ranking, and the number of hits passed along all belong exactly here. For coding agents, file search, project instructions, and how long terminal output is handled are the same kind of work.
3. Harness: Can the agent work safely?
Working environment
Which actions are possible, visible, and checkable?
Levers: tools, permissions, sandbox, file system, tests, logs
The harness is the technical environment around the model. It hands over tools and context, executes actions, restricts access, and makes results observable. Depending on the author, the actual agent loop is also counted as part of the harness. For diagnosis, I separate environment and repetition logic here.
A good example is Anthropic's experiment with a long-running coding agent. An initialization run produced a list of more than 200 checkable features for a Claude.ai clone. Later sessions read the Git history and a progress file, worked on a small part each time, and verified the application through browser automation. Anthropic describes this setup as one possible solution for long tasks, not as a general benchmark.
Tool design belongs here too. Overlapping names, unclear parameters, and huge responses raise the error rate. Anthropic therefore recommends clear functional boundaries and evaluations with real tasks. That a tool works technically says nothing about whether an agent reliably recognizes when and how to use it.
Permissions and sandboxing aren't a side issue. An agent can fall for a prompt injection or misread a destructive command. File-system and network boundaries limit the damage, while approval for sensitive actions stays with a human.
4. Loop: What happens after the first result?
Flow
How are observation, correction, and the end state controlled?
Levers: trigger, status, repetition, abort, escalation, approval
Loop engineering shapes the repeated cycle: pick a task, act, observe the result, correct if needed, and end in a clearly named state. IBM explicitly calls the term a young practice as of July 2026. Other authors count parts of it as part of the harness. That fuzziness is worth resolving once, within a project.
A test makes a failure visible. It doesn't guarantee an improvement. The agent can misread the error message, repeat the same attempt, or even alter the checker itself if permissions allow it. Anthropic's long-running experiment therefore explicitly forbade deleting or rewriting the feature checks. The loop also needs a limit on retries and a path to a human when a failure gets stuck.
What repetition can achieve mathematically
This model shows the chance of at least one successful attempt. Adjust the per-attempt success rate and the maximum number of attempts.
Assumption: every attempt is independent and equally good. Agent runs rarely meet that assumption. They inherit broken state, react differently to feedback, and cost time and tokens. The calculator shows the theoretical benefit of repetition, not realistic production performance.
A related weakness showed up in my world-model project. The planner scored action sequences with a learned model. That model predicted rewards that didn't occur in the real environment. More planning steps amplified the measurement error, because the action and the verification signal came from too closely related a source.
Which area is the bottleneck right now?
A failure can have several causes. This finder therefore points to the most useful first check, not a final diagnosis.
Select the symptom
What behavior are you observing?
Does the instruction specify structure, required fields, and a checkable example? Test the same task with a clearer output specification.
The boundaries fray
In an April 2026 post, Anthropic defines the harness as the loop that calls the model and forwards tool calls to the infrastructure. OpenAI uses harness engineering more broadly, for repository structure, agent readability, tools, feedback loops, and mechanically enforced rules. The narrow separation used in this post is therefore a working approach, not an industry standard.
That's not a problem day to day, as long as a team stays concrete. "We need better harness engineering" still isn't a task. "The agent may read production storage but not write to it, and every write attempt needs approval" is an actionable requirement.
What all four areas are missing: a yardstick
Without fixed test tasks, every improvement stays a one-off observation. A small set of real cases is often enough for a first comparison: typical tasks, two or three edge cases, and known success criteria. Because model output varies, each case should run multiple times. Anthropic therefore distinguishes, for agent evaluations, between the task, individual attempts, graders, and the full run trace.
Measure at least result quality, run time, token consumption, tool errors, and the human interventions required. Then change only one area. Otherwise you'll know the new setup behaves differently, but not which change actually helped.
A workable order for debugging
- Record the failure. Save the task, model version, context, tool calls, and result.
- Make success checkable. Before making a change, define how to recognize a correct result.
- Start at the observed symptom. Wrong format points first to the prompt, missing facts to the context, wrong actions to the harness, and premature stopping to the loop.
- Change only one lever. Then re-run the same tasks across multiple attempts.
- Check for side effects. A higher success rate can be bought with more run time, higher cost, or broader permissions.
In my projects, the work rarely starts with a long prompting session. I look first at the run trace: what did the model know, which tool did it pick, what signal did it get back, and why was it allowed to stop? After that, it's usually clear where a targeted fix is worth trying.
Sources and further reading
- Anthropic: Effective context engineering for AI agents, September 29, 2025
- Anthropic: Effective harnesses for long-running agents, November 26, 2025
- Anthropic: Writing effective tools for AI agents, September 11, 2025
- Anthropic: Demystifying evals for AI agents, January 9, 2026
- Anthropic: Scaling Managed Agents, April 8, 2026
- OpenAI: Harness engineering, February 11, 2026
- IBM: What is loop engineering?, July 17, 2026
Walk through your own agent system
In my training sessions, we break real workflows down into prompt, context, harness, and loop. That turns "the agent is unreliable" into a list of checkable changes. The intro call takes 30 minutes and is free.