When an electrical engineer hears "closed loop," they don't think of AI — they think of a thermostat, a cruise control, an op-amp. Control theory has an eighty-year head start on the question agent builders are now stumbling into, and borrowing its vocabulary makes the current state of AI agents embarrassingly legible.
An open-loop controller executes a fixed policy and never checks the result. A closed-loop controller measures the output, compares it to the reference, and feeds the error back into its next action. Today's AI agents are open-loop controllers wearing autonomous branding.
The washing machine test
A classic open-loop example: a washing machine timer. It runs the motor for 40 minutes whether the clothes are clean or filthy, because it has no sensor for "clean." Your agent's prompt is that timer. It encodes, at design time, everything the designer believed would produce good outcomes — and then executes it regardless of what actually happens. If the world matches the designer's assumptions, great. When it doesn't, the machine keeps confidently running its 40-minute cycle on muddy clothes, forever.
Cruise control, by contrast, measures actual speed 100 times a second, computes the error against the target, and adjusts throttle continuously. Hills, headwinds, and cargo don't break it, because deviations are precisely what it's built to consume.
What the loop needs: sensor, error, actuator
Mapping the control diagram onto agents makes the missing pieces concrete:
- The sensor measures the actual output. For agents this is outcome capture plus evaluation — did the task truly succeed, scored against explicit criteria. Most stacks have no sensor beyond "did it return without an exception," which is like a thermostat that only detects whether the furnace is on fire.
- The error signal is the difference between what happened and what should have. It must be quantitative and trustworthy — this is where rubric design earns its keep, because feedback computed from a noisy sensor is worse than none.
- The actuator applies the correction. For agents: prompt revisions, tool-policy updates, memory writes, retrieval changes. Crucially, corrections are applied to the system, not the frozen model.
Control theory's warning label
The discipline also predicts exactly how naive loop-closing fails. Feed a controller a noisy sensor and it oscillates. Overcorrect and it becomes unstable. This is precisely what happens to teams that wire eval scores directly to automatic prompt rewrites with no validation: each update fixes this week's complaints and breaks last week's fixes, and behavior swings run to run. The remedy is the same as in control engineering — trust your sensor before you act on it, damp your corrections, and gate every adjustment through regression testing so a correction that makes things worse never reaches production.
The question that actually matters
Framed this way, "should agents learn from production?" stops being philosophical. No control engineer would ship an open-loop controller into a disturbance-rich environment, and production traffic is nothing but disturbances. The real questions are engineering questions: what's your sensor, how trustworthy is your error signal, what's your actuator, and what keeps the loop stable. Those have concrete answers — I've laid out the full architecture in How to Build a Feedback Loop for AI Agents — and teams that answer them get agents that behave like cruise control: boring, steady, and self-correcting. Teams that don't are running washing-machine timers and calling them autonomous.