Steering a Run
By the end of this module
- Place steering against the controls that run before and after a step
- Choose an intervention by how forcefully it lands and how long it holds
- Say who is doing the steering, and what that costs each of them
Definition
The last two modules covered controls that sit at a fixed point and either let something through or do not. Steering is the third option: changing what an agent is doing while it is still doing it, without stopping the run.
It matters because the alternative to steering is usually starting again. An agent six iterations into a task that has drifted has produced work worth keeping, and killing the run throws it away along with the drift.
Before, During and After
| When | What it can do | What it costs |
|---|---|---|
| Before a step | Stop something happening, or change what the model is about to be asked. | Knows least. It has not seen what the model would have done. |
| During the run | Change course while keeping the work done so far. | Competes with the original instruction instead of replacing it. |
| After the run | Record, classify, and improve the next one. | This run already happened. Nothing can be prevented from here. |
The Guide action from the tool gate in unit two was a steering move, not a blocking one. It withheld the call and handed the turn back with feedback, so the agent corrected course instead of failing. That is the shape: intervene, and let the run continue.
Choosing a Lever
Steering is not one operation. The levers differ in how forcefully they land and in how likely the agent is to drift back. A run in trouble is below. Try several.
The agent is three iterations into a refund query. It has called the pricing tool four times, each with slightly different arguments, and is about to call it again. Nothing has failed. It is circling.
The pattern worth taking away is that the mechanical interventions hold and the interpretive ones fade. Withdrawing a tool is enforced outside the model, so nothing the model decides can undo it. Reweighting a goal asks the model to decide differently, which it will, until the next ambiguity re-raises the original priority.
That maps exactly onto the requirement and control distinction from two modules back. Most steering is a requirement delivered late. Tool restriction is the one on this list that is actually a control.
Who Steers
| Steerer | How it decides | The catch |
|---|---|---|
| A person watching | Judgement, on whatever they happen to notice. | Does not scale, and only covers runs someone is actually watching. |
| A rule in the runtime | A deterministic condition: iteration count, repeated arguments, budget spent. | Catches only what was anticipated, and anticipating is the hard part. |
| A decision model | A typed question on every iteration, cheap enough to ask every time. | Needs the question and the threshold chosen by someone, as in unit two. |
| Another agent | Reads the run and intervenes in natural language. | The most flexible and the most expensive, and it can oscillate with the agent it watches. |
An agent keeps producing over-long answers. A monitor adds 'be concise' to its context each time. Three iterations later it is still over-long. What is the most likely reason?
Discussion
Think of a time someone on the team corrected a running agent by adding text to its prompt. Ask whether the correction held for the rest of that run, and how anybody would have known if it had not.