There is a phrase that has echoed through MIT's engineering labs for decades: demo or die. Build the thing, run it against reality, and let the results speak. It was also at MIT that Norbert Wiener gave us cybernetics β the science of control and communication in systems that sense, decide, and act. Both ideas matter enormously the moment you move an AI agent out of a chat window and into a business process.
Because a deployed agent is not a clever autocomplete. It is a controller sitting inside a feedback loop, acting on a live system, changing its state, and β if you build it right β correcting itself when reality drifts from intent.
The chat window is open-loop. Production is not.
In a chat window, you are the feedback loop. You read the answer, notice it is wrong, and retype. Nothing is at stake but your patience. That is an open-loop system: output with no automatic correction.
A production workflow cannot work that way. When an agent drafts a quote, chases an overdue invoice, or reconciles a ledger, there is no human staring at every token. The loop has to close on its own β the system must sense what it did, compare it against what was intended, and route the difference somewhere useful. That difference is the single most important quantity in the whole design.
Every control loop has four parts
Classical control theory β the kind formalized in texts like Γ strΓΆm and Murray's Feedback Systems β describes any regulated system with four elements. Map them onto an AI workflow and the design becomes obvious:
- Setpoint β what good looks like. For a workflow this is an explicit spec: quotes within a 2% margin tolerance, replies in the customer's language, zero PII in outbound text. If you cannot state the setpoint, you cannot control anything.
- Sensor β how you observe the actual output. Traces, evals, guardrail checks, and human approvals are your sensors. A workflow with no evals is a thermostat with no thermometer.
- Controller β the logic that reacts to error: retry, re-route to a different model, escalate to a human, or halt.
- Actuator β the thing that changes the world: the connector that sends the email, writes to the ERP, posts to Slack.
The error signal is the whole point
Control is built on one quantity: error β the gap between setpoint and measured output. In an AI workflow, error shows up in concrete, catchable forms. An eval scores a draft below threshold. A guardrail flags PII. A reviewer edits a number before approving. Each of these is a measurement of error, and each is worth capturing as structured data, not just fixing and forgetting.
This reframes the human approval gate. An approval is not bureaucracy; it is a sensor with extremely high signal quality. When a manager changes a delivery date before approving a quote, the loop just measured error precisely β and that measurement is the most valuable training signal the system will ever get.
Gain, oscillation, and why aggressive retries make it worse
Here is where teams that skip the theory get burned. In any feedback system, how hard you react to error is the gain. Turn the gain up too high and the system oscillates β it overshoots, corrects, overshoots the other way, and never settles.
AI systems oscillate too. An agent that retries instantly and aggressively on every low eval score can thrash: it burns tokens, floods downstream systems, and sometimes amplifies the original mistake. Add delay in the loop β a slow eval, a human who reviews once a day β and naive high-gain correction becomes unstable. The control-theory fix is well known: damp the response, add hysteresis, rate-limit corrections, and design for the latency your feedback actually has. Concretely: cap retries, back off exponentially, and never let a correction path trigger itself.
You cannot control what you do not measure
Wiener's core insight was that control and information are the same problem. You can only regulate a system as well as you can observe it. This is why observability is not a nice-to-have bolted on after launch β it is the sensing half of the loop, and without it the controller is blind.
That means every run should emit: which connectors were called, what data they returned, which model ran with which prompt, every guardrail decision, every approval, and the final cost. Not for a dashboard's sake β because that telemetry is literally the sensor signal the rest of the system regulates against. This is the same discipline that Google's Site Reliability Engineering practice built for distributed systems, and the same systems-thinking Nancy Leveson argues for in safety-critical engineering: the accident is rarely one broken part; it is a loop that stopped sensing.
What this looks like in practice
At PromptRails the operating layer is built as a closed loop on purpose. Every workflow carries an explicit spec (the setpoint). Evals and guardrails score each output (the sensor). Routing, retries, and approval gates decide what happens on error (the controller). Connectors act on the world (the actuator). And full tracing makes the whole loop observable, so when reality drifts we see the error before a customer does.
The teams that treat their agents like software features struggle. The teams that treat them like control systems β with setpoints, sensors, bounded gain, and relentless measurement β ship things they can actually trust in production.
The model is not your system. The loop around it is.
References
- Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine, MIT Press, 1948.
- Karl Johan Γ strΓΆm and Richard M. Murray, Feedback Systems: An Introduction for Scientists and Engineers, Princeton University Press, 2008.
- Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering, O'Reilly, 2016.
- Nancy G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety, MIT Press, 2011.
Want to see the loop instrumented end to end? Book a 30-minute demo.