Prompt, Loop and Harness Engineering: The 2026 Guide

Three years ago, getting good results from a language model mostly meant writing a better prompt. In 2026 that is only the first of three layers. The teams shipping reliable AI agents now talk about prompt engineering, loop engineering and harness engineering as separate skills, each solving a different problem.

This guide explains what each one means today, what changed this year, and how they fit together. The examples use a coding agent working on a Laravel app, but the ideas apply to any agent.

The short version

• Prompt engineering decides what you ask in a single turn.
• Loop engineering decides how the agent keeps going: act, check the result, adjust, repeat, and stop.
• Harness engineering decides everything around the model: the tools it can call, the context it sees, the rules it follows, and the checks that catch its mistakes.

A useful way to hold all three in your head is the formula that spread quickly through the industry this year:

Agent = Model + Harness

The model supplies the reasoning. The prompt and the loop live inside the harness. When an agent fails, the fix is usually in one of these three layers, not in swapping the model.

	Prompt engineering	Loop engineering	Harness engineering
Question it answers	What should I ask?	How does the agent iterate and when does it stop?	What does the agent work inside?
Unit of work	One request	A cycle of act → observe → adjust	The whole environment
Typical artefacts	System prompts, examples, output formats	Goals, verifiers, retry and stop rules	Tools, AGENTS.md/CLAUDE.md, tests, linters, permissions, sandboxes
Fails as	Vague or wrong answers	Endless retries, early "done", drift	Repeated mistakes, unsafe actions, unverifiable work

Prompt engineering in 2026

What it is

Prompt engineering is writing the instructions a model receives for a task: the goal, the constraints, the audience, examples, and the shape of the answer you want back.

What changed

The biggest change is that modern models need less scaffolding. Anthropic's own prompting best practices (November 2025) note that recent models rely less on heavy structure, that assigning an expert persona matters less than giving explicit instructions, and that built-in extended thinking reduces the need to spell out chain-of-thought by hand.

What still works, and matters more than ever:

1. Be explicit. State exactly what you want, including format and length.
2. Explain why. A constraint with a reason ("keep it under 160 characters because it is a meta description") is followed more reliably than a bare rule.
3. Show an example. One good example of the output format beats a paragraph describing it.
4. Allow "I don't know". Giving the model permission to say it is unsure reduces confident guessing.

Prompt engineering became context engineering

For agents, the prompt is now a small part of what the model reads on each turn. The rest is tool definitions, previous messages, files and search results. Anthropic describes this wider job as context engineering: choosing the smallest set of high-value tokens for each step. The practical techniques are worth knowing by name:

• Compaction: summarise a long conversation when it nears the context limit, keeping decisions and open issues.
• Structured notes: let the agent keep a progress file outside the context window.
• Just-in-time retrieval: keep references (file paths, IDs) and fetch details only when needed.
• Sub-agents: send a focused job to a separate agent and get back only a short summary.

Takeaway: prompt engineering is not dead. It has narrowed to writing clear intent, and the bigger lever has moved to what surrounds the prompt.

Loop engineering: designing how agents iterate

What it is

An agent is a loop. The model takes an action, sees the result, and decides what to do next, until a stopping condition is met. IBM defines loop engineering as designing these workflows so agents move toward a goal with minimal human intervention, and notes that it underpins coding agents such as Claude Code and OpenAI's Codex.

Every loop has the same four parts:

1. Goal: a measurable definition of done.
2. Action: a step toward the goal (edit a file, call a tool, run a command).
3. Observation: the result of that step (test output, an error, a diff).
4. Adjustment: what the agent changes next, based on what it observed.

Stacking loops

In June 2026, LangChain's The Art of Loop Engineering described four loops that stack on top of each other:

1. The agent loop: the model calls tools until the task is finished.
2. The verification loop: the output is checked against a standard, and failures go back to the model as feedback.
3. The event-driven loop: webhooks, schedules or messages start agent runs automatically, so the agent becomes part of a system instead of something you run by hand.
4. The hill-climbing loop: production traces are analysed to find recurring failures, and the prompts, tools or checks are updated to fix them.

The rule that matters most: verification is the signal

A loop can only converge on something it can check. Loops improve most when you:

• Prefer deterministic checks. Tests, type checkers and linters give a clear pass or fail. "Does this look right?" does not.
• Separate the maker from the checker. The step that writes the code should not be the only step that judges it.
• Define the stop. Cap attempts, and stop on success, on repeated identical failures, or when the agent needs a human decision.

Here is the shape of a verification loop for a Laravel change, in plain PHP-style pseudocode:

$attempts = 0;

while ($attempts++ < 5) {
    $patch = $agent->propose($task, $feedback ?? null);
    $repo->apply($patch);

    $result = $shell->run('php artisan test --parallel');

    if ($result->passed()) {
        return $patch;                 // verified: stop
    }

    $feedback = $result->failures();   // observation becomes the next input
}

return $human->review($task, $feedback); // out of attempts: hand over

The test suite is the reward signal. Without it, the agent can only guess whether it is done.

The risks

IBM names four risks that grow with autonomous loops: unverified code, comprehension debt (more code than anyone understands), intent debt (lost design reasons) and cognitive surrender (people stop checking). The answer is not fewer loops. It is keeping a human at the points where judgement matters: merging, deploying and changing data.

Harness engineering: the environment around the model

Where the term came from

In February 2026, Mitchell Hashimoto (creator of Terraform and Ghostty) described "engineering the harness" in his essay My AI Adoption Journey: whenever an agent makes a mistake, you change its environment so that it cannot make that mistake again. Days later, OpenAI published Harness engineering: leveraging Codex in an agent-first world, describing a five-month internal project in which a small team shipped a product of roughly a million lines of code without writing the code by hand (InfoQ summary). The engineers' job moved from writing code to designing the environment the agents worked in.

What goes into a harness

In April 2026, Birgitta Böckeler of Thoughtworks published Harness engineering for coding agent users on martinfowler.com. It splits a harness into two kinds of control:

• Guides (feedforward): steer the agent before it acts. Examples: an AGENTS.md or CLAUDE.md file, architecture docs, coding conventions, templates.
• Sensors (feedback): detect problems after it acts, in a form the model can understand. Examples: tests, type checks, linters, build errors, review comments.

Each control is either computational (fast and deterministic, like PHPStan or Pint) or inferential (a model judging the work: slower and probabilistic, but able to catch design problems). The advice is to run cheap computational checks constantly and save inferential checks for later stages.

OpenAI's write-up adds two patterns worth copying:

• Docs as a map for agents. Keep plans, specs and architecture notes in the repository, so the agent can learn the system from the repo itself.
• Architecture enforced by code, not by hope. Their layers (types → config → repository → service → runtime → UI) were enforced with structural tests, so an agent could not quietly break the dependency direction.

A minimal harness for a Laravel project

You can start small. For a Laravel codebase, a first harness might be:

AGENTS.md            # how to run the app, where things live, what never to touch
docs/architecture.md # layers and the direction dependencies may point
composer test        # Pest or PHPUnit: the main sensor
vendor/bin/phpstan   # static analysis: a fast computational sensor
vendor/bin/pint      # code style, fixed automatically
tests/ArchTest.php   # Pest arch tests, e.g. no dd() or env() outside config

Then apply Hashimoto's rule. Every time the agent makes the same mistake twice, turn the fix into part of the harness: a line in AGENTS.md, a new arch test, or a stricter PHPStan level.

Make your codebase harnessable

Some codebases are much easier for agents to work in. Böckeler's article recommends designing for "harnessability": strong types, clear module boundaries and standard frameworks. For Laravel teams that means typed properties and return types, form requests instead of inline validation, and consistent service boundaries. These are good practice anyway, and now they also make your agent more reliable.

How the three work together

Picture one bug fix from start to finish:

1. Prompt: "Fix the failing invoice total test. Don't change the public API of InvoiceService." The prompt states intent and constraints.
2. Harness: the agent reads AGENTS.md, has permission to run tests but not to touch .env, and knows where invoices live from docs/architecture.md.
3. Loop: it edits, runs php artisan test, reads the failure, edits again, and stops when the suite passes or after five attempts.
4. Hill-climbing: you notice agents keep forgetting to update a related factory. You add an arch test and a note to AGENTS.md. The harness improves, and the next run doesn't repeat the mistake.

Each layer covers the others' blind spots. A perfect prompt cannot fix a loop with no verifier. A great loop cannot fix an agent that can't see the right files. A strong harness still needs a clear prompt to know what you want.

Key takeaways

• Prompt engineering now means clear intent, constraints and examples. Modern models need less scaffolding, and the bigger job is context engineering.
• Loop engineering is about act → observe → adjust cycles. Verification is the signal: prefer deterministic checks, separate maker from checker, and define when to stop.
• Harness engineering is everything around the model: guides before it acts and sensors after. Treat every repeated agent mistake as a missing part of the harness.
• Agent = Model + Harness. When an agent fails, look at the prompt, the loop and the harness before you blame the model.

FAQ

Is prompt engineering still worth learning in 2026?

Yes, but its scope is narrower. Writing clear, specific instructions with examples still matters in every AI interaction. For agents, the higher-leverage skills are context, loop and harness engineering.

What is the difference between loop engineering and harness engineering?

Loop engineering designs how an agent iterates (its actions, checks, retries and stopping rules). Harness engineering designs the environment that loop runs in: the tools, context, rules, permissions and sensors. The loop lives inside the harness.

Is harness engineering only for AI coding agents?

No. The term became popular through coding agents, but any agent that takes actions (support, data analysis, operations) benefits from guides, sensors and clear boundaries.

Where should I start?

Add an AGENTS.md (or CLAUDE.md) to your repository, make sure your test suite runs with one command, and let your agent run it after every change. That single verification loop is the biggest early win.