How it works
A feedback loop closes the distance between an agent’s action and the evidence of what that action produced. Without the return path, the agent can continue acting from its original plan even after the environment has changed or an earlier step has failed.
A practical loop has five parts:
- The agent acts through a tool or workflow step.
- The harness captures the result, including errors, state changes, and relevant side effects.
- A verifier turns that result into a signal. The verifier may apply deterministic rules, a model-based check, human judgment, or a combination.
- A policy decides what the signal permits: continue, retry, revise, escalate, compensate, or stop.
- The next decision receives the signal together with enough state to act on it.
The signal must be more precise than “good” or “bad.” It should identify the failed condition, the evidence behind that judgment, and the actions still allowed. A failed schema check, for example, should return the violated fields rather than a generic rejection.
The loop also needs a boundary. Retry limits, execution budgets, and stop conditions prevent feedback from turning into unbounded self-correction. The harness, not the agent’s prose, should enforce those limits.
Why it matters in an agent harness
Agent output is non-deterministic, but many operating requirements are not. A file either matches its schema or it does not. A credential either permits a requested operation or it does not. A workflow either reached a recorded checkpoint or its recovery state is uncertain. Feedback loops connect these inspectable conditions to the agent’s next move.
That connection improves control. The harness can refuse progression when a required invariant fails, while still allowing the agent to revise work inside a bounded scope. This is more useful than treating every failure as terminal, and safer than letting the model decide whether its own result is acceptable.
Feedback also makes recovery legible. If each correction records the triggering observation, chosen response, and resulting state, an operator can reconstruct why the run changed direction. That record supports debugging, trajectory evaluation, and later policy changes. Without it, repeated attempts look like unexplained model behavior.
The main design risk is feeding back the wrong signal. A verifier that rewards superficial completion can push the agent toward outputs that pass a check while missing the actual objective. A stale observation can cause needless correction. An ambiguous error can encourage broad, speculative changes. Feedback quality therefore depends on attribution: the signal should correspond to the action being evaluated and distinguish content failure from provider, permission, or infrastructure failure.
A loop should not expand authority. If an attempted action exceeds its permission scope, the response is not to grant more access so the agent can continue. The loop should route the request through the applicable approval policy or stop at the control boundary.
Feedback Loop vs Evaluation
Evaluation measures behavior or outcomes. A feedback loop uses a measurement to change subsequent execution. The distinction affects where the mechanism runs and what authority it carries.
| Axis | Feedback loop | Evaluation |
|---|---|---|
| Primary purpose | Steer an active or later decision | Assess quality, behavior, or compliance |
| Timing | Usually inside or between execution steps | During execution, after a run, or offline |
| Required effect | Produces an actionable control signal | May produce only a score or finding |
| Main risk | Runaway retries or misdirected correction | Misleading conclusions from weak measures |
An evaluation becomes part of a feedback loop only when a policy consumes its result. Keeping that transition explicit matters. A score should not silently gain the power to retry tools, rewrite state, or approve an irreversible action.
The Rifty take
We optimize for feedback that is attributable, bounded, and visible in the execution record. We accept that explicit verification and policy steps add latency because correction without a control boundary is just another source of unpredictable behavior. Signals may guide the agent, but the harness retains authority over permissions, retries, and stopping.
Implementation checks
- Define the observation each action must return, including side effects and unknown outcomes.
- Keep verification separate from the agent’s claim that its work succeeded.
- Return specific failure conditions and evidence, not an undifferentiated score.
- Map each signal to an explicit policy outcome such as revise, retry, escalate, compensate, or stop.
- Put hard limits on retries, tool calls, elapsed work, and repeated state transitions.
- Preserve the triggering action, verifier result, policy decision, and resulting state in the execution trace.
- Test whether stale, malformed, or adversarial feedback can redirect the agent or widen its permissions.
- Treat missing observations as unknown outcomes rather than implicit success.
- Verify that a corrective action is safe to repeat or has a defined compensating action.
- Escalate infrastructure and permission failures instead of disguising them as content-quality feedback.
Frequently asked questions
Does every agent action need a feedback loop?
No. Use a feedback loop when the result can change what should happen next, especially around correctness, state transitions, permissions, or irreversible effects. Low-risk read operations may only need recording. Adding correction logic to every step can increase latency and create unnecessary opportunities for retries or oscillation.
Can the same model generate an output and evaluate it?
It can provide a useful critique, but that critique should not be treated as independent proof. Pair self-evaluation with deterministic checks, external observations, or human judgment when consequences are significant. The harness should also decide what the critique permits rather than letting the model silently authorize its own retry.
How do you stop a feedback loop from running indefinitely?
Enforce limits outside the model. Set retry counts, execution budgets, stop conditions, and rules for detecting repeated states or unchanged errors. When the limit is reached, preserve the latest known state and route to escalation, compensation, or failure instead of asking the agent to keep trying.
What should happen when feedback is missing or ambiguous?
Treat the outcome as unknown, not successful. The harness can retry a safe observation, request a more specific verifier result, or stop at a checkpoint. It should not infer completion from silence. Ambiguous feedback needs a bounded resolution path because acting on a guessed state can compound side effects.