Feedback Sensor

A feedback sensor is any check that runs after an agent acts, telling it what went wrong so it can correct course.

“You can’t control what you can’t observe.” — W. Edwards Deming

Also known as: Sensor, Feedback Control, Post-hoc Check

Understand This First

• Harness (Agentic) – the harness orchestrates when and how sensors run.
• Tool – each sensor is a tool the agent invokes or the harness runs automatically.

Context

At the agentic level, feedback sensors live inside the harness alongside their complement, feedforward controls. Where feedforward steers the agent before it acts, feedback sensors observe after the act and report what happened. Together they form the two halves of a harness’s control system.

Control theory provides the mental model. A feedback controller measures a process’s output and adjusts future inputs to shrink the error. In agentic coding, the “process” is the agent generating or modifying code. The sensors are tests, linters, type checkers, and other automated tools that inspect the result and return a signal the agent can act on.

Problem

How do you detect and correct mistakes in agent-generated code without relying on human review of every change?

An agent that generates code without post-hoc checking can’t distinguish working output from plausible-looking failures. Early data bears this out: studies of AI-generated pull requests find they contain significantly more issues than human-written code, even when the agent had access to project context. Feedforward controls reduce the odds of mistakes, but they can’t prevent all of them. Some errors only surface when code runs, types are checked, or tests exercise edge cases. Without feedback, the agent can’t self-correct, and every mistake lands on the human reviewer.

Forces

• Agents can’t judge their own output. A model that generated incorrect code will often describe that same code as correct when asked. External verification is the only reliable check.
• Speed matters. The faster a sensor returns results, the more correction cycles fit within a single task. Slow sensors reduce the agent’s effective iteration count.
• Deterministic signals are cheap; semantic signals are expensive. Running a type checker costs milliseconds and returns a clear pass/fail. Asking another model to review code costs tokens, time, and introduces its own error rate.
• Not every error is checkable. Some quality dimensions (design taste, naming clarity, architectural fit) resist automated sensing. Feedback sensors cover the checkable surface; human judgment covers the rest.

Solution

Place automated checks in the agent’s iteration path so it receives concrete signals after every change. Feedback sensors split into two kinds based on how they produce their verdict.

Computational sensors are deterministic tools run by the CPU. They return the same result for the same input every time. Examples include type checkers, linters, test suites, schema validators, static analyzers, and security scanners. These are fast (milliseconds to seconds), cheap, and reliable. A harness can run them on every change without meaningful cost.

Inferential sensors use a model to evaluate the agent’s output. An LLM-as-judge reviewing code for architectural fit, a semantic diff checker comparing output against a specification, or an AI code reviewer flagging suspicious patterns are all inferential sensors. They’re slower, more expensive, and non-deterministic. They catch things that computational sensors miss, like whether the code actually does what the user asked for.

The practical rule: run computational sensors on every change, alongside the agent. Reserve inferential sensors for checkpoints where the cost is justified, like before committing or before submitting for human review.

Sensor results must flow back into the agent’s context in a form it can act on. A test failure message that includes the failing assertion, the expected value, and the actual value gives the agent what it needs to fix the problem. A linter error with a file path and line number does the same. Strip noise: the agent doesn’t need a stack trace for a type mismatch. Match the signal to the repair.

How It Plays Out

A team configures their harness to run three feedback sensors after every code change: the TypeScript compiler (type errors), ESLint (style and correctness rules), and a focused subset of their test suite (tests in the modified module). The agent writes a function that returns undefined where the caller expects a string. The type checker catches it in 200 milliseconds. The agent reads the error, adds a default return value, and the next check passes. Total cost: one fast correction cycle instead of a broken commit.

A developer building a user-facing feature adds an inferential sensor at the commit checkpoint: an LLM reviewer that compares the diff against the original task description and flags gaps. The agent writes the feature and passes all tests, but the reviewer notes that the error messages use internal codes instead of user-friendly text. The agent revises the messages before the human ever sees the pull request. The inferential sensor caught a quality issue that no test or linter could detect.

Consequences

Feedback sensors make agents self-correcting within the bounds of what automation can check. They reduce the volume of mistakes that reach human review, freeing reviewers to focus on design, intent, and architectural fit. Over time, a well-tuned sensor suite makes the verification loop faster and more reliable.

The cost is infrastructure. Feedback sensors only work when the project has tests, type checking, linting, and other automated quality tools in place. Projects with weak test coverage get limited benefit. Inferential sensors add token cost and latency. There’s also a design cost: choosing which sensors to run when, and how to format their output for the agent, requires thought about what matters most for each project.

Related Patterns

• Depends on: Harness (Agentic) — the harness orchestrates when and how sensors run.
• Depends on: Tool — each sensor is a tool the agent invokes or the harness runs automatically.
• Contrasts with: Feedforward — feedforward prevents errors before the act; feedback sensors detect them after.
• Enables: Verification Loop — the verification loop is the process that consumes sensor output and drives correction.
• Enables: Steering Loop — the steering loop connects feedback sensors with feedforward controls into a closed control system.
• Uses: Test — tests are the most common computational feedback sensor.
• Uses: Eval — evals are feedback sensors applied to the agent’s overall performance across tasks.
• Related: Observability — observability provides the runtime signals that feedback sensors provide at development time.

Sources

• The concept of feedback control originates in control theory and cybernetics. Norbert Wiener formalized the feedback loop in Cybernetics: Or Control and Communication in the Animal and the Machine (1948), establishing the principle that a system can self-correct by measuring its own output and adjusting its inputs.
• Birgitta Boeckeler introduced the guides (feedforward) and sensors (feedback) taxonomy for agentic coding in “Harness engineering for coding agent users”, published on Martin Fowler’s blog. The computational-vs-inferential sensor distinction used in this article comes from that framework.
• OpenAI’s “Harness engineering” extended the guides-and-sensors model and provided evidence that sensor quality dominates model quality in determining agent performance on real tasks.

Further Reading

• Martin Fowler and Birgitta Boeckeler, “Harness engineering for coding agent users” — defines the guides-vs-sensors taxonomy and distinguishes computational from inferential sensors.
• OpenAI, “Harness engineering: leveraging Codex in an agent-first world” — describes how feedback loops and sensor quality dominate model quality in agent performance.