Suraj Khaitan

Posted on Jul 26

🔁 Loop Engineering Is Not Vibe Coding: The Two Loops That Make AI Agents Reliable

#ai #claude #llm #agents

The model is only one component. The real product is the loop around it: what the agent sees, what it may do, how its work is checked, when it must stop, and how every failure makes the system better for the next run.

I Used to Think the Agent Was the Product

Give an AI agent a goal. Connect a few tools. Let it reason, act, inspect the result, and repeat.

That sounds like an autonomous system.

It is also how you build an agent that can quietly burn tokens for an hour, retry the same broken command seven times, forget the original objective, and finally announce success with failing tests.

The uncomfortable lesson is that a powerful model inside a weak loop is still a weak system.

The model may write excellent code. It may understand an unfamiliar repository. It may recover from errors that would have stopped last year's systems. But once it operates for many turns, reliability depends less on the brilliance of any single response and more on the machinery surrounding every response.

That machinery is the agent harness:

the instructions and repository map it receives;
the tools and permissions it can use;
the state carried from one turn to the next;
the validators that inspect tool results;
the tests, policies, and evaluators that define success;
the budgets and circuit breakers that bound execution;
the traces that explain what happened;
and the handoff rules that decide when a human must take over.

Designing that machinery is loop engineering.

After studying the patterns behind long-running coding agents, customer-service agents, research agents, and the newer “agent-first” software teams, I think the most useful insight is not that agents work in loops. We already knew that.

It is that there are two loops, running at two different speeds:

the fast loop in which the agent improves one output; and
the slow loop in which the engineering team improves the harness itself.

The first loop completes a task. The second compounds capability.

And the quality of your agent system depends on whether you deliberately engineer both.

TL;DR

An agent is an LLM using tools in a loop. It observes, decides, acts, verifies, and repeats until a success or stop condition fires.
The loop is where production failures compound. Context grows, bad observations propagate, goals drift, and retries can continue indefinitely.
There are two loops: the runtime loop fixes the current output; the engineering loop turns recurring failures into permanent improvements to tools, context, hooks, and evals.
Loop engineering is not vibe coding. It combines high delegation with high verification. The agent may perform most of the work, but executable checks decide whether that work is acceptable.
The verifier is the real specification. A weak success metric creates Goodhart's law in miniature: the agent makes the metric green while the actual requirement remains broken.
Context is a finite attention budget. Compact old history, persist structured notes, retrieve details just in time, and isolate deep work in subagents.
Every production loop needs hard boundaries: maximum turns, token/cost limits, timeouts, repetition detection, validated tool results, clean failure exits, and human gates for irreversible actions.
Do not pre-build a giant harness. Run realistic tasks, inspect failures, fix one systemic gap, add it to the eval suite, and repeat. Autonomy grows through a ratchet—not a leap of faith.

First: What Loop Engineering Actually Means

Anthropic uses a deliberately simple description of an agent: an LLM autonomously using tools in a loop.

A typical cycle looks like this:

observe → reason → act → validate → update state → repeat

The core agent loop. Reliability comes from engineering every transition—not merely improving the reasoning step.

The agent reads the current state, selects a tool or produces an answer, observes what happened, and decides whether it has completed the goal. If not, the new observation becomes input to the next turn.

Loop engineering is the discipline of controlling that cycle so it remains useful as the number of turns grows.

It answers six questions:

Goal: What exactly counts as done?
Context: What information should the model see on this turn?
Action: Which tools and permissions are available?
Feedback: How is each result validated before it becomes new context?
Control: What limits prevent runaway execution?
Recovery: What happens when the agent is stuck, unsafe, or over budget?

Prompt engineering mostly asks, “What instruction should I give the model?”

Loop engineering asks a broader question:

“What system will keep producing trustworthy progress after the original prompt is twenty tool calls behind us?”

That is a different engineering problem.

Why Bare Agent Loops Fail

A demo usually exercises the happy path. A production loop lives in the unhappy paths.

Four failure modes appear repeatedly.

1. Context growth

Every tool call produces more text: search results, logs, stack traces, files, plans, failed attempts, and model explanations. If every observation remains in the conversation, the context becomes a landfill.

A larger context window delays the problem; it does not remove it. Anthropic's context-engineering guidance describes context as a finite attention budget with diminishing returns. Research on “context rot” similarly shows that retrieval and reasoning can degrade as irrelevant or weakly relevant material accumulates.

The danger is not simply reaching a token limit. The agent can remain inside the limit and still lose precision because important constraints are competing with thousands of stale tokens.

2. Error propagation

A malformed API response, an incomplete search result, or an incorrect assumption can become “fact” on the next turn. The agent then plans against it, calls more tools, and produces downstream work built on a corrupted state.

Without validation, one bad observation becomes a multiplier.

3. Non-termination

The agent retries a command. It fails. The agent slightly rephrases the command. It fails again. Nothing in the loop recognizes that the state has not materially changed.

A model saying “I will try another approach” is not a circuit breaker.

4. Goal drift

After dozens of intermediate decisions, the agent starts optimizing a local subproblem and forgets the original objective. It may produce an elegant refactor when the task was a one-line bug fix, or finish 35 items in a 50-item migration and treat the progress as completion.

Long-running agents need the goal re-anchored, not merely remembered somewhere deep in chat history.

These are not four unrelated bugs. They are all failures in the design of the loop.

Five Loop Patterns Worth Knowing

“Agent loop” is not one architecture. Several patterns recur because they solve different kinds of tasks.

Pattern	How it works	Best fit	Main risk
ReAct	Alternate reasoning, tool action, and observation	Open-ended research and tool use	Wandering or accumulating noisy context
Reflexion / self-critique	Generate, inspect failure, reflect, and retry	Code that can be tested; drafts with clear feedback	The generator may rationalize its own output
Plan-and-execute	Create a plan, execute steps, replan when reality differs	Long, staged tasks	A bad initial plan can anchor every step
Evaluator-optimizer	One component generates; another scores and gives feedback	Work with a stable quality rubric	Weak or biased evaluator
Human-in-the-loop	Pause at explicit checkpoints for approval	Payments, deletion, publishing, customer communication	Too many gates destroy useful autonomy

Five useful patterns. The right choice depends on whether the task needs exploration, refinement, staging, independent evaluation, or approval.

Anthropic's Building Effective Agents makes an important recommendation: start with the simplest pattern that works, and add agentic complexity only when it measurably improves outcomes.

A support FAQ does not need an autonomous planner. A deterministic workflow does not become better because an LLM gets to improvise every transition. And a single model call with retrieval may beat a sophisticated agent when the task has no meaningful need for iteration.

The best loop is not the most autonomous loop. It is the smallest loop that can close the task reliably.

The Production Stack Around the Loop

A bare ReAct cycle is no longer advanced agent engineering. It is the center of a larger control system.

A production-grade loop usually adds five layers.

Context engineering

Select, compress, isolate, and retrieve the information the model needs. The objective is not “give the agent everything.” It is give the agent the smallest high-signal context that supports the next correct decision.

Bounded execution

Enforce maximum turns, token and cost budgets, wall-clock deadlines, tool-specific timeouts, and repetition detection. These are hard controls in code—not polite suggestions in a prompt.

Layered guardrails

Inspect more than the user's first message. Controls should exist around:

incoming content;
the proposed tool call;
the tool response;
state transitions; and
the final output.

Each boundary is another opportunity to stop unsafe or malformed data before it contaminates the run.

Human gates

Human oversight is not an embarrassing fallback. It is an architectural component.

Define an escalation matrix before launch. Reading a public webpage may be autonomous. Refunding money above a threshold, deleting production data, changing IAM policies, or sending an external email may require approval.

Observability and evaluation

Log each meaningful state transition: selected action, validated observation, latency, token use, cost, retry count, and stop reason. Then evaluate complete traces against representative tasks.

You cannot improve a loop if all you retain is its final answer.

The Most Important Mental Model: There Are Two Loops

This is the distinction that changed how I think about agent engineering.

The runtime loop improves one task's output. The engineering loop improves the harness across every future task.

Loop 1: The runtime loop

This is the fast loop—the agent doing one task.

Timescale: seconds to hours
Cycle: gather → act → verify → repair
What improves: the output for this run
Who operates it: the agent
Harness status: mostly fixed during the run

Suppose a coding agent writes a function, runs the type-checker, reads an error, patches the function, and runs the check again.

That is a successful runtime loop. The task got fixed.

But the system learned nothing durable. On the next task, the agent can make the same category of mistake again.

Loop 2: The engineering loop

This is the slow loop—the team improving the system across many runs.

Timescale: hours to weeks
Cycle: run → inspect failure → identify missing capability → modify harness → re-evaluate
What improves: every future run
Who operates it: engineers, often with the agent implementing the changes
Harness status: it is the object being changed

If type failures appear repeatedly, the engineering response is not “ask the model to be more careful.” It is to make type-checking an unavoidable back-pressure signal:

run the type-checker before completion;
return structured failures to the agent;
prevent success while errors remain;
add the scenario to the evaluation suite; and
document the repository convention where the agent can find it.

Now the fix applies to every future task.

The runtime loop repaired one output. The engineering loop removed an entire class of failure.

That is compounding.

The Fast Loop Runs Inside the Slow Loop

Every runtime trace is a diagnostic data point for the engineering loop.

When an agent stalls, repeats itself, calls the wrong tool, edits the wrong package, or declares success on broken work, the immediate temptation is to blame the model.

Sometimes the model is the problem. Often the environment is underspecified.

The better question is:

“What capability, signal, constraint, or piece of context was missing from the harness?”

OpenAI described this pattern in its 2026 article on harness engineering. Its team began with an empty repository and used Codex to generate the application, tests, documentation, tooling, and infrastructure. When the agent failed, the team's response was rarely “try harder.” They identified what the agent could not see or enforce, then encoded that missing capability into the environment.

Their reported experiment reached roughly a million lines of agent-generated code in five months, with around 1,500 merged pull requests driven initially by a three-person team. Those numbers are specific to that internal system and should not be treated as a universal benchmark. The transferable lesson is the method:

human judgment was captured once, then made available or enforceable on every future run.

This is the harness ratchet.

Each runtime failure becomes evidence for the slower engineering loop. A durable harness fix then raises the floor for future runs.

Triage: Runtime Repair or Harness Fix?

Not every failure deserves a new rule. If you encode every one-off mistake into the harness, it becomes brittle, noisy, and overfit to yesterday's tasks.

Use one question:

“Would this fix help many future runs, or only this run?”

Let the runtime loop handle it when:

a test fails and the agent correctly patches the implementation;
a transient API request succeeds after bounded backoff;
the agent needs one missing fact and can retrieve it;
a first hypothesis is wrong, but evidence leads it to a better one; or
the issue is task-specific and unlikely to recur.

The key signal is self-recovery. The existing loop already contains enough feedback to correct course.

Promote it to a harness improvement when:

the same mistake appears across tasks;
the agent cannot observe the signal required to recover;
the failure has a dangerous blast radius;
the agent repeatedly “finishes” while a mechanical check is red;
the task exceeds the context or planning structure of one agent; or
humans keep writing the same review comment.

Examples:

Repeated failure	Durable harness improvement
Edits the wrong module	Add a concise repository map with links to deeper architecture docs
Runs destructive SQL	Block unsafe operations with a pre-execution hook
Ships type errors	Run type-checking as a mandatory completion gate
Loses a 40-step migration	Add an execution plan, durable progress file, and planner/executor separation
Repeats stale patterns	Encode architectural invariants in custom lint rules
Produces ambiguous tool inputs	Redesign the tool contract with typed, validated parameters
Same review nit on every PR	Convert the principle into a lint, test, example, or evaluation case

The goal is not to make the prompt longer. The goal is to make the environment more legible and the constraints more executable.

What the Harness Ratchet Looks Like Over Five Runs

Imagine an agent implementing a real feature in an unfamiliar repository.

Run 1: It edits the wrong module

The agent does not understand the package boundaries.

Harness fix: create a short repository map in AGENTS.md or CLAUDE.md, with links to canonical architecture documents. Do not paste the entire architecture into the context; provide a navigable map.

Run 2: It gets further, then proposes an unsafe migration

The model knows the codebase now, but the action should never execute autonomously.

Harness fix: add a tool hook that rejects destructive SQL and routes exceptional cases to human approval.

Run 3: It builds the feature but stops with type errors

The agent's internal sense of “done” is weaker than the repository's standard.

Harness fix: type-checking becomes a mandatory verifier. A failed check returns structured, actionable feedback and prevents completion.

Run 4: It loses the thread halfway through a large change

The task is too long for one unstructured context.

Harness fix: require a versioned execution plan and progress log. Split planning from execution or delegate isolated subtasks to clean-context workers.

Run 5: It completes end to end, with only recurring review nits

The remaining issues reflect team taste and architectural consistency.

Harness fix: encode the “golden principles” mechanically where possible and add regression cases to the eval suite.

No model upgrade was required. The environment became better at making the current model succeed.

This is why autonomy should be treated as an earned property. Each harness improvement removes one reason a human previously had to intervene.

The harness ratchet in practice: every observed failure adds a durable capability, constraint, or feedback signal.

Context Engineering: Keep the Loop Out of the Fog

Long loops eventually become context-management systems.

Anthropic recommends three practical techniques for long-horizon work.

1. Compaction

Summarize an older trace and begin a fresh context with the critical state: decisions, constraints, unresolved issues, modified files, failed approaches, and next actions.

Raw historical tool output is usually low-value after its result has been incorporated. Clear it or replace it with a concise state update.

Compaction is lossy, so optimize for recall first. A tiny summary that omits a subtle architectural decision can be more damaging than a slightly longer one.

2. Structured note-taking

Persist progress outside the context window:

execution plans;
TODO lists;
decisions and rationale;
known failures;
files changed;
checks already completed; and
the exact next step.

After a reset, the agent reloads the durable state rather than reconstructing it from memory.

The filesystem becomes long-term memory. The model's context remains working memory.

3. Subagent isolation

Give focused subtasks to agents with clean contexts. Each worker can inspect thousands of tokens of detail but return only a distilled result to the coordinator.

This prevents one specialist's logs, searches, and dead ends from consuming the parent agent's attention budget.

The principle behind all three is the same:

preserve state, discard noise.

A useful context is not the largest one. It is the one with the highest signal per token.

The Ralph Loop: Fresh Context, Durable State

The Ralph loop is a useful extreme of this idea.

Instead of extending one conversation indefinitely, a coding agent starts each iteration with fresh context. It reads the same goal and repository instructions, performs one bounded unit of work, writes progress back to durable artifacts such as files and git history, and exits. An external loop launches the next iteration.

Conceptually:

load the goal and current repository state;
choose one useful unit of work;
implement it;
run objective checks;
persist progress and decisions;
stop if the verifier passes; otherwise start a fresh iteration.

This trades conversational continuity for predictable attention. The agent does not need to carry every earlier thought because the codebase, plan, tests, and git history contain the state that matters.

The pattern has impressive creator-reported stories, but those results are anecdotal rather than controlled benchmarks. The architecture—not the headline number—is what matters.

Fresh context alone does not create reliability. A Ralph-style loop without a trustworthy success condition is simply a resettable infinite loop.

A Production Loop Skeleton

Frameworks vary, but the control flow should remain visible. A useful mental model is small enough to inspect:

state = initialize(task)

for turn in range(MAX_TURNS):
    if budget.exhausted() or deadline.expired():
        return partial_result(state, reason="budget_exhausted")

    context = build_context(goal=task.goal, state=state)
    action = model.decide(context)

    if action.is_done():
        verdict = verify_goal(state, task.acceptance_criteria)
        if verdict.passed:
            return success(state)
        state.add_feedback(verdict.feedback)
        continue

    if repeated_without_progress(action, state.history):
        return escalate(state, reason="loop_detected")

    try:
        raw_result = execute_with_timeout(action)
        result = validate_tool_result(raw_result)
    except RecoverableError as error:
        state.add_feedback(structured_error(error))
        continue
    except UnsafeOrRepeatedError as error:
        return escalate(state, reason=str(error))

    state = update_state(state, action, result)
    trace(turn, action, result, budget.snapshot())

return partial_result(state, reason="max_turns_reached")

The model call is one line. Most production reliability lives around it.

Notice the explicit exit paths:

verified success;
budget exhaustion;
deadline expiration;
repeated behavior without progress;
unsafe or repeated failure;
and maximum turns reached.

A useful partial result is better than a fabricated success or an unbounded retry.

The Difference Between Loop Engineering and Vibe Coding

If the agent performs most of the implementation, is this just vibe coding with a more serious name?

No—but it can become that very easily.

The difference is not how many lines the human typed. It is how rigorously intent is specified and verified.

Think of agent-assisted development on two independent axes:

delegation: how much work the agent performs; and
verification: how strongly the output is constrained and checked.

	Low verification	High verification
Low delegation	Ad hoc manual work	Traditional spec-driven engineering
High delegation	Vibe coding / naive autonomous loop	Loop engineering

Delegation and rigor are independent. Loop engineering deliberately combines high agent delegation with strong executable verification.

Loop engineering deliberately occupies the high-delegation, high-verification corner.

The agent can write the code, update tests, inspect logs, drive a browser, and open the pull request. But it is not allowed to redefine success based on how convincing its own output feels.

Tests, type checks, security policies, architectural constraints, business metrics, independent review, and human approval gates hold the boundary.

Delegation without verification is not autonomy. It is unobserved risk.

The Verifier Is the Executable Specification

Loop engineering does not eliminate the specification. It relocates it.

The old burden was to describe every implementation step in advance.

The new burden is to define a verifier whose “pass” actually means “correct.”

That can be harder.

A loop optimizes aggressively against its stop condition. If the condition is a weak proxy, the agent can satisfy the letter of the check while missing the intent:

tests pass, but the requirement was never covered;
coverage rises through low-value assertions;
an LLM judge approves polished nonsense;
response time improves while correctness falls;
tickets are “resolved” by prematurely closing difficult cases;
a migration reaches zero compiler errors but changes runtime behavior.

This is Goodhart's law in miniature: when a measure becomes a target, it can stop being a good measure.

Before trusting a loop, ask:

“Would I stake the output on this stop condition?”

A strong verifier often combines several signals:

deterministic checks for syntax, types, tests, schemas, and policy;
behavioral checks against acceptance scenarios;
regression tests for previously observed failures;
an independent evaluator for qualities that are difficult to encode;
and human judgment for consequential or ambiguous cases.

An LLM evaluator should not be treated as an oracle. Calibrate it against human-labeled examples, test disagreement cases, and track false approvals as seriously as false rejections.

The best loop is not the one that keeps trying hardest. It is the one that knows what trustworthy success looks like.

Observability: Trace the Decision Cycle, Not Hidden Reasoning

A production trace should let you reconstruct what the system did without requiring private chain-of-thought.

Capture operationally useful data:

task and run ID;
current goal and stage;
model and configuration;
selected tool and sanitized arguments;
tool outcome and validation status;
state changes;
verifier scores and feedback;
retry reason;
latency, tokens, and cost;
safety or approval events;
final stop reason; and
links to resulting artifacts.

Then measure the loop as a system:

Metric	What it reveals
Task completion rate	Whether the loop closes real work
Verified completion rate	Whether “done” survives independent checking
Average turns to completion	Efficiency and possible wandering
Cost per successful task	More useful than cost per model call
Retry rate by tool	Fragile contracts and external dependencies
Repeated-action rate	Loops making no material progress
Human escalation rate	Where autonomy still breaks down
False-success rate	Weak verifiers or premature stopping
Recovery rate	Whether feedback actually helps the agent self-correct
Context size over time	Compaction and retrieval quality

Tools such as OpenTelemetry, Langfuse, LangSmith, or a custom event store can capture these signals. The brand matters less than having a coherent trace model from day one.

If you add observability after scaling, you will have expensive failures with no explanation.

Guardrails: The Boundaries That Make Autonomy Possible

Guardrails do not make agents less autonomous. They create the safe region in which autonomy is allowed.

Every serious loop should have:

Hard resource limits

maximum turns;
maximum tokens or cost;
wall-clock deadline;
per-tool timeout;
retry caps with backoff; and
concurrency limits.

Progress detection

Compare actions and state changes across turns. Repeated identical calls, semantically equivalent edits, or unchanged verifier scores should trigger a strategy change or escalation.

Validated tool contracts

Prefer typed parameters, constrained enums, clear error schemas, and token-efficient responses. Make write operations idempotent where possible so a retry does not duplicate payments, messages, records, or infrastructure changes.

Least privilege

A research agent that reads untrusted pages should not automatically inherit credentials for production deployment. Separate readers, decision-makers, and privileged executors when the blast radius is meaningful.

Approval before irreversible action

Define the boundary explicitly. Examples include:

sending external communication;
deleting or overwriting data;
changing production access;
executing a payment or refund;
merging into a protected branch; and
publishing regulated or high-impact content.

Clean degradation

A stopped loop should return what it knows, what it changed, what failed, which checks remain, and what a human should do next.

“Could not complete safely within the budget” is a valid outcome. Pretending to have succeeded is not.

How to Build a Harness Without Over-Engineering It

The wrong approach is to imagine every possible failure, create a giant instruction manual, connect thirty tools, and launch a multi-agent platform before one real task has run.

The better approach is incremental.

Step 1: Define the boundary and success condition

Write down the goal, allowed actions, forbidden actions, and acceptance criteria. Replace “improve the service” with measurable outcomes such as “all contract tests pass and p95 latency remains below the agreed threshold on the test workload.”

Step 2: Choose the smallest useful pattern

Use a single call when possible. Use a deterministic workflow when the path is known. Use an agent loop when the path or number of steps must be discovered dynamically.

Step 3: Design narrow tools

Give each tool a distinct purpose, typed input, concise result, predictable error format, and clear permission boundary. Make retries safe.

Step 4: Engineer context deliberately

Start with a short map and retrieve detail just in time. Decide what will be compacted, what must be persisted, and which subtasks need isolated contexts.

Step 5: Add hard stop controls

Set budgets before testing. A maximum-turn limit added after a runaway bill is not loop engineering; it is incident response.

Step 6: Validate observations

Do not let malformed, untrusted, or incomplete tool output flow directly into state. Normalize and validate it first.

Step 7: Design success, failure, and handoff exits

The loop should know how to finish, how to stop, and how to ask for help.

Step 8: Instrument every run

Trace actions, outcomes, state changes, budgets, and stop reasons. Redact secrets and sensitive payloads while retaining enough structure to debug.

Step 9: Evaluate on representative tasks

Build a small test set with known outcomes, difficult edge cases, and previously observed failures. Track task-level metrics, not just whether individual responses look good.

Step 10: Run, observe, triage, and ratchet

Let real failures tell you what the harness lacks. Add one durable improvement at a time and lock it into the eval suite.

The harness should grow from evidence, not imagination.

A Subtle Third Loop: Model and Harness Co-Evolve

There is a third, slower feedback cycle across model generations.

Harness designers expose useful primitives—filesystem operations, shells, browser control, plans, subagents, structured edits. Future models are then trained and evaluated in environments containing those primitives, so they become better at using them. Better models enable more capable harnesses, which create new training and evaluation tasks.

Capability compounds across both sides.

But this creates coupling. A model can perform exceptionally inside the harness it was optimized around and much worse inside another. Benchmarking the “model” without the scaffold can therefore be misleading; tool design, context assembly, retry policy, and verifier quality may account for a large portion of observed performance.

That leads to a practical rule:

evaluate the model-harness pair on your tasks.

Keep critical constraints portable when possible. A business rule encoded as a test, schema, or policy is easier to preserve across model and framework changes than one hidden in a vendor-specific prompt trick.

Six Rules I Would Take Into Any Agent Project

The production checklist: measurable success, hard guardrails, incremental harness improvement, deliberate context, explicit human boundaries, and observability.

1. Make success mechanically checkable

“Looks good” is not a stop condition. Prefer tests green, lint at zero, schema valid, every item processed, reconciliation balanced, or a human-approved exception.

2. Treat context as working memory, not a database

Retrieve detail when needed. Compact old traces. Persist decisions and progress externally. Use isolated contexts for deep subtasks.

3. Put hard limits outside the model

Turn caps, budgets, timeouts, repetition detection, and permission checks belong in code. The component consuming resources must not be the only component deciding when to stop.

4. Convert recurring failures into harness improvements

A repeated review comment is a missing rule. A repeated tool mistake is a broken interface. A repeated unsafe proposal is a missing guardrail.

5. Draw the human–AI boundary before launch

Decide which actions require approval while calm—not after an agent sends, deletes, pays, or deploys the wrong thing.

6. Instrument before scaling

Keep traces, build an eval set, and measure cost per verified success. More autonomy without better evidence is simply a larger unknown.

Final Take: The Loop Is the Product

The agent is not just the model. It is the model plus the environment that shapes every decision.

A good loop gives the model the right context, useful tools, validated feedback, a trustworthy definition of done, and enough freedom to find a path. A safe loop also knows when to stop spending, when to reject an action, and when to hand control back to a human.

But the deeper advantage comes from the second loop.

Run the agent. Read the failure. Decide whether it was a one-off recovery or a systemic harness gap. Encode the missing capability as a tool, hook, test, document, policy, or evaluation. Run again.

Each runtime loop produces one result.

Each engineering-loop improvement raises the floor for every result that follows.

That is why loop engineering is not vibe coding. Vibe coding delegates the work and relaxes the proof. Loop engineering delegates the work because the proof has been made executable.

The future of agent engineering will not be won by whoever writes the cleverest mega-prompt or connects the most tools. It will be won by teams that turn intent into verifiers, failures into infrastructure, and human judgment into constraints that compound.

The model will change.

The harness will evolve.

The discipline remains the same:

Let the agent loop on the task. Let the team loop on the agent. Never let either loop run without a trustworthy signal.

Sources and Further Reading

Anthropic — Building Effective Agents
Anthropic — Effective Context Engineering for AI Agents
OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World
Geoffrey Huntley — The Ralph Wiggum Loop
Chroma Research — Context Rot: How Increasing Input Tokens Impacts LLM Performance
OpenTelemetry — Documentation

About the Author

Suraj Khaitan — Gen AI Architect | Building scalable platforms and secure cloud-native systems

Connect on LinkedIn | Follow for more engineering and architecture write-ups

Where does your agent fail today: inside the runtime loop, or because the harness has not learned from yesterday's failure? Share the pattern in the comments—I am collecting the most useful real-world loop fixes for a follow-up.