Reward and Feedback Loops for Autonomy

An agent I saw fail did something instructive: it took a small wrong turn on step two - misreading a column name - and then ran eight more steps building confidently on that mistake, producing a final result that was elaborate, well-formatted, and completely wrong. Nobody caught it mid-run because the agent never checked its own work against reality. It ran open-loop, and open-loop agents compound their errors into nonsense.

An autonomous agent feedback loop is the mechanism by which an agent's actions produce observations that inform its next actions - closing the gap between what it did and what actually happened. Without it, an agent is guessing blind after step one. This is the case study of that failing agent, the feedback loop that fixed it, and a specific lesson about what kind of feedback works for language-model agents - because the answer isn't the reward number you might expect from reinforcement learning.

The problem the team faced

A analytics team built an agent to produce recurring reports from a database. It planned a sequence of steps - query, transform, aggregate, format - and executed them in order. On paper, a clean pipeline. In practice, when any early step went subtly wrong, the whole report went wrong, and the agent never noticed.

The specific failure: step two referenced a column that had been renamed. The query didn't error - it returned data, just the wrong data. The agent, seeing some result, proceeded. Every downstream step faithfully processed the wrong data into a polished, confident, worthless report. The error was tiny; the blast radius was the entire output.

The wrong approach

The original design executed its plan open-loop - each step ran, and the next step assumed the previous had succeeded:

data = run_query(plan.query)          ,[object Object],
transformed = transform(data)          ,[object Object],
report = ,[object Object],(aggregate(transformed)),[object Object],
,[object Object], report                          ,[object Object],

What this does: it runs each step in sequence and passes the output straight to the next step with no check that the output is actually correct - so a step that silently returns wrong data poisons everything after it with no signal that anything went wrong.

The flaw is the absence of any observation-and-check between steps. "The query returned data" was treated as "the query succeeded," and those are not the same thing. Open-loop execution assumes every step does what was intended, and that assumption is exactly what fails silently.

⚠️ Common mistake: Equating "the action didn't error" with "the action did what I wanted." An action can complete cleanly and still produce wrong results - a query returns the wrong rows, a file writes to the wrong path. Only a feedback loop that checks the result, not just the absence of an exception, catches this.

The correct approach

The fix was to close the loop: after each step, observe the actual result and check it against an expectation before proceeding.

[object Object], ,[object Object],(,[object Object],):
    result = execute(step)
    check = verify(result, expectation)     ,[object Object],
    ,[object Object], ,[object Object], check.ok:
        ,[object Object],
        ,[object Object], agent.reconsider(step, feedback=check.details)
    ,[object Object], result

,[object Object],
,[object Object],
,[object Object],
,[object Object],

What this does: after each step it verifies the result against an explicit expectation and, when the check fails, feeds the specific discrepancy - not a generic failure flag - back into the agent's next decision, so the agent corrects the actual problem instead of proceeding blind.

Now the renamed-column failure surfaces at step two. The check notices the expected column is missing, reports the specific discrepancy ("found net_revenue instead"), and the agent adjusts - rather than processing wrong data for eight more steps.

Results and what changed

Reports stopped being silently wrong. The renamed-column class of failure - and every other "completed but incorrect" failure - now got caught at the step where it happened, when it was cheap to fix, instead of at the end when the whole run was wasted. The team's rate of quietly-wrong reports dropped to near zero.

But the more interesting finding was about what kind of feedback worked. The team's first instinct, borrowed from reinforcement learning, was to score each step with a number - a reward - and let the agent optimize it. It barely helped. A scalar "0.3" told the agent something was wrong but not what, and a language model can't do much with a bare number. When they switched to rich textual feedback - "missing column revenue, found net_revenue instead" - the agent's corrections became sharp and immediate. The model reasons over language, so language-shaped feedback is what it can actually use.

⚡ Pro tip: For language-model agents, rich textual feedback beats a numeric reward. A scalar score says that something's wrong; a sentence says what and why. The model can reason over the sentence and fix the actual problem - it can only guess at the number.

⚡ Pro tip: Make every step declare its expected result before it runs, then check against that expectation. The mismatch between expected and actual is where the useful feedback lives - "I expected columns X, got Y" is exactly the signal the agent needs, and it only exists if the expectation was stated.

One calibration the team learned: not every step needs a feedback check, and checking everything is its own cost. The checks that earn their keep are the ones guarding a step whose silent failure would poison everything after it - the query that feeds the whole report, the transform that reshapes the data. A cosmetic formatting step at the end rarely needs a guard, because a mistake there is visible and local. So the discipline isn't "verify every step"; it's "verify every step that later steps depend on." Placing feedback checks at the dependency chokepoints catches the compounding failures for a fraction of the cost of checking everything, which keeps the closed loop from becoming its own source of overhead.

Why doesn't a reward signal work for LLM agents?

The team's failed first attempt - scoring steps with a number - wasn't a random misstep. It's the natural instinct if your mental model of agents comes from reinforcement learning, where a scalar reward is the whole feedback channel. But a language-model agent isn't an RL policy, and the reward framing actively misleads.

The problem is bandwidth. A number carries almost no information. "0.3" tells the agent it did poorly but nothing about what to change - and a language model's entire strength is reasoning over rich context. Feeding it a scalar is like giving a fluent writer a single thumbs-down and expecting a targeted revision. The channel is too narrow for the reasoning the model can do.

The second problem is credit assignment. When a ten-step run gets one final reward, which step earned the blame? RL solves this statistically over many episodes. An LLM agent usually gets one shot, so a single end-of-run score can't tell it which step to fix. A per-step textual check - "step two returned the wrong column" - assigns credit precisely, immediately, in a form the model can act on.

⚡ Pro tip: Don't port reinforcement-learning reward thinking onto language-model agents. Their feedback channel isn't a scalar you optimize - it's language they reason over. Give them descriptive feedback ("wrong column, expected revenue") not a score, and the correction becomes precise instead of a guess.

This reframes what an autonomous agent feedback loop should produce. The output of each check isn't a grade; it's a description the model can use - what was expected, what happened, and if possible why they differ. The richer and more specific that description, the sharper the correction. Optimizing for informative feedback, not quantified feedback, is the design principle that made the reports reliable.

⚡ Pro tip: Judge your feedback by whether a human reading it would know exactly what to fix. If "expected X, got Y, likely because Z" passes that test, it'll drive a good correction; if all you have is a number, it won't.

How to apply this to your situation

Audit your agent for open-loop stretches - sequences where steps run without checking results between them. Each such stretch is a place a silent error can compound. Insert an observe-and-verify step wherever a wrong-but-not-erroring result would poison what follows.

For a data team, the check is schema and sanity expectations after each query or transform. For an operations team, it's confirming the system reached the expected state after each action, not just that the command returned. For a content team, it's verifying each section meets its brief before building the next on top of it. In every case, the feedback should be descriptive - what's wrong, specifically - not a score.

The general principle: an autonomous agent feedback loop needs to check results against expectations, and for language-model agents that feedback should be words, not numbers.

Next steps

Take one agent and add a single expectation-check after its most failure-prone step. Watch it catch a silent error it would previously have carried to the end. That one insertion often does more for reliability than any model upgrade, because it converts an open-loop stretch into a closed one.

The expectation definitions and feedback-formatting prompts - the ones that turn a raw failure into "expected X, got Y, likely because Z" - are reusable across every agent you build. Keeping them in PromptABCD means your next agent closes the loop with rich, descriptive feedback by default, instead of running open-loop until a tiny early error compounds into a confident, worthless result that nobody catches until it's already been sent.