Feedback loop in AI agents: how to close the improvement cycle

An agent running without feedback is like someone practicing in the dark: they repeat the same motion a thousand times with no idea whether they’re getting better or worse. They can execute tasks all day and keep making the same mistake, because nothing tells them that result was wrong. The feedback loop is the piece that turns “repeating” into “improving,” and it’s what separates an AI agent that half-works from one that sharpens with every cycle.

What is a feedback loop in an AI agent?

A feedback loop is the turn in the cycle where the result of an action is measured, and that measurement changes the next action. It’s the difference between acting blindly and acting with course correction.

To see why, remember what an agent is. An AI agent is a model running inside a loop: it receives context, decides on an action (often using a tool, like reading a file or calling an API), observes what that action returns, and decides the next step. That turn repeats until the objective is met — and that’s the difference from a one-shot call that answers once and shuts down. That loop is the agent’s engine, and designing it well is half the work: I break down the decisions that define it in the architecture of an enterprise agent.

Feedback is a specific part of that loop: the turn where the result isn’t just observed but measured against something, and that measurement decides what the agent does next. Observing is not the same as measuring. An agent can read the output of a test and keep going as if nothing happened; the feedback loop only exists when that result — green or red — actually changes the next attempt.

// El feedback loop de un agente: actuar, medir, y dejar que la
// medida cambie el siguiente intento.
async function resolverConFeedback(objetivo: Objetivo) {
  const MAX_INTENTOS = 5 // ajusta a tu caso
  let feedback = ""
  for (let intento = 0; intento < MAX_INTENTOS; intento++) {
    const resultado = await agente.actuar(objetivo, feedback)
    const senal = await medir(resultado)   // test, linter o juez
    if (senal.ok) return resultado         // la señal aprueba: paramos
    feedback = senal.detalle               // qué falló entra en el próximo intento
  }
  // Agotados los intentos sin señal verde: fallamos fuerte en vez de
  // devolver undefined en silencio.
  throw new Error(`Sin resultado válido tras ${MAX_INTENTOS} intentos`)
}

feedback = senal.detalle is the assignment that turns the loop into learning. Without it, the agent iterates in a void.

Two types of feedback: deterministic and judgment-based

There are two ways to give an agent a signal, and choosing well between them is not a minor detail. Getting it right can eliminate one model call per iteration; getting it wrong ties you to the judge forever.

Deterministic feedback compares the result against a fixed rule. A test that passes or fails, a linter that finds or doesn’t find an error, a gate that validates a schema, or comparing the output against an expected answer. The signal is binary or measurable, and it always produces the same result for the same input. It doesn’t opine: it measures.

Judgment-based feedback uses another model to evaluate the output of the first. You pass the evaluating model the response and a rubric, and it scores how good it is. This is LLM-as-judge, which I cover in depth in model as judge. It handles what no fixed rule can measure, at the cost of putting a model (with its own quirks) inside the loop.

	Deterministic feedback	Judgment-based feedback
How it measures	A fixed rule: test, linter, gate, or exact comparison	Another model evaluates with a rubric you write
Cost	Nearly zero per run	One extra model call per turn
Stability	Same input, same signal, every time	Can change between two identical runs
Hallucinates?	No	Yes, it can
Best for	Verifiably correct or incorrect	Clarity, tone, and what has no exact answer

Why deterministic wins when you can use it

Whenever you can measure with a rule, use the rule. A test doesn’t have a bad day: it runs the same on Monday as on Friday, it doesn’t invent a pass, and it costs the same to run a thousand times as it does once.

When the agent writes code, the most honest signal that exists is the test suite. It passes or it doesn’t, and there’s no opinion to argue with. If your agent touches code, setting up that safety net before releasing it is the first thing you’d do; I cover this in the testing strategy for AI-generated code. And when you move to production, that signal grows into metrics and evals that run continuously — something I cover in how to evaluate AI agents in production.

Deterministic feedback is boring. That’s why it works.

When you need judgment

Judgment comes in when there’s no exact answer to compare against. Does this summary capture what matters from the document? Does the tone of this email sound professional? Is this explanation understandable? No test can answer that. Those are matters of degree, and a fixed rule can’t score nuance.

That’s where an LLM-as-judge earns its place: it reads the output and evaluates it against a rubric you define, scaling a criterion that would otherwise have to be applied by a person to every case by hand. The tradeoff is that the judge is another model, with the same flaws as any model. It can hallucinate. It can reward a long answer just for being long. And sometimes it changes its verdict between two identical runs. That’s why judgment is the second resort, not the first. If a rule can measure it, the rule wins.

From one-off feedback to a self-adjusting loop

A feedback loop doesn’t have to be run by a human every time. At first, you close the loop yourself: you read the result, decide if it’s good enough, tweak the prompt, and launch again. It works, but it doesn’t scale beyond a few manual iterations.

The next level is letting the cycle itself measure, propose a change, test it, and validate whether it improved. That’s the experiment-driven optimization pattern: you set a baseline, propose a hypothesis, iterate, and validate against that baseline. The human only steps in where they genuinely add judgment — approving the hypothesis before spending time on it. The rest of the loop runs on its own.

Here, feedback stops being one more step and becomes the engine. The loop moves forward because each turn produces a signal that drives the next. And it all depends on that signal pointing in the right direction.

The trap: a bad signal optimizes toward the wrong thing

A feedback loop with a bad signal doesn’t stay still. It optimizes toward the wrong thing, and it does so with maximum efficiency. When a metric becomes the objective, it stops measuring what mattered. That’s Goodhart’s Law, and in an agent you see it fast.

Imagine you measure an agent’s quality by the percentage of tests that pass, and the agent can edit those tests. It will learn that the fastest path to a green signal is to delete the assertions that bother it or write tests that don’t check anything. The metric goes up. The code gets worse. The loop is working beautifully toward the wrong objective.

The signal has to measure what you actually want, not what’s easy to count. A loop is only as good as its feedback, and feedback that points in the wrong direction is worse than no feedback at all — because it gives you the false sense that you’re improving while you’re moving further away.

Feedback is just one turn in the loop the agent runs, and without a good signal no loop converges. Designing that signal is the foundation of the full loop engineering pattern, of which this feedback loop is one piece.

Common mistakes

Measuring what’s easy instead of what matters

The silent version of the Goodhart trap. You count tokens, latency, number of steps, and cost per response because they come for free from the log, while “the answer was correct” forces you to think about how to verify it. The end of that road is an agent that’s incredibly fast and cheap but answers poorly, with a dashboard full of green charts that don’t measure the only thing you cared about.

Using a judge when a test was enough

If the output can be verified with a rule, don’t call a model to opine on it. An LLM-as-judge to check whether a JSON is valid is more expensive, slower, and still capable of being wrong. Use a parser.

No signal at all (“it seems to be working better”)

The most common of all, and the hardest to admit. You change the prompt, test it with two examples by hand, get the sense it improved, and call it done. Without a recorded signal, you don’t know whether it improved, got worse, or you just got lucky with those two examples. “It seems to be working better” is not feedback. It’s a hunch dressed up as a conclusion.

Loop with no iteration cap

An agent with no iteration cap can spin on the same error it doesn’t know how to resolve, burning one call after another without getting any closer to a result. The first time it happened to me was with an agent missing a dependency that wasn’t even installed: without a MAX_INTENTOS to cut it off, it rewrote the same import over and over expecting a different outcome. That’s why the snippet’s loop has a cap and terminates with an explicit error when it’s exhausted. Failing loudly is better than iterating in silence forever.

Implementation checklist

• Every relevant agent action produces a measurable signal, not an impression
• You use deterministic feedback (test, linter, gate, or comparison against an expected answer) whenever the output can be verified with a rule
• You reserve LLM-as-judge for subjective quality, always with an explicit rubric
• The signal measures what you actually want, not what’s easiest to count
• The agent cannot manipulate its own signal (it doesn’t touch the tests that evaluate it)
• You record every signal to compare iterations instead of deciding by feel
• The human steps in where they add judgment — like approving the hypothesis — not on every loop turn

Frequently Asked Questions

Deterministic feedback or LLM-as-judge: which do I choose?

Always start with deterministic. If the output can be verified with a rule (a test or an exact comparison against the answer you expected), use it — it’s cheaper, doesn’t hallucinate, and gives the same signal every time. Reserve LLM-as-judge for what has no exact answer, like the tone or clarity of a text. Many good agents combine both: a deterministic gate filters what can be verified, and a judge evaluates the subjective residual.

How do I know if my feedback loop’s signal is good?

Run the cheater test: if an agent wanted to maximize your metric without doing the actual work, would it have a shortcut? Think of a signal that counts as success “the agent returned a response”: a model quickly learns that producing any paragraph will raise it, even if it solves nothing. The way to check without guessing is to record the score from your gate or judge alongside whether the output actually worked, on every turn. When the metric rises and the real result stays flat, that’s the loop exploiting the gap.

Can an AI agent’s feedback loop be fully automated?

The mechanical part, yes: measuring, proposing an adjustment, testing it, and validating whether it improved can run without you in the room. What’s worth keeping under human control is the decision of which hypothesis to test — that’s where your judgment prevents the agent from optimizing toward the wrong thing. In practice, the human approves the direction and the loop executes the rest.

Does this only apply to agents that write code?

No. Any agent with an output you can measure has a viable feedback loop: support, document classification, text generation, or data extraction. What changes across them is the type of signal, not the idea of closing the cycle.