Is agent steering the same as human-in-the-loop?

No. They are sibling patterns distinguished by who initiates. In human-in-the-loop, the agent initiates: it pauses at a checkpoint it chose and waits for the user to approve, edit, or reject. In steering, the user initiates: they inject input into a running agent at a moment of their choosing, without the agent having asked. Real applications use both, over the same bi-directional connection.

Can every agent be steered?

No. Steering only works if the agent loop checks for new input at points during execution and can revise its plan when input arrives. An agent built as a one-shot pipeline that runs to completion cannot be steered, no matter what the frontend offers. Steerability is a property of the agent loop first and the interface second.

Does steering lose the work the agent has already done?

No, preserving that work is the point of steering. The agent folds the new instruction into its live state: completed steps that remain valid are kept, and only the parts the instruction invalidates are redone. Killing the run and re-prompting, by contrast, discards everything and pays the full cost again.

What does agent steering require from the frontend?

Three things: a persistent bi-directional connection to the agent rather than a one-shot request, an input affordance that stays live while the agent runs, and a rendering of the agent's intermediate work and state so the user can see what is happening and knows when to steer.

What Is Agent Steering?

Q: How is steering different from just sending another prompt?

A new prompt starts a new run: the agent begins again, and the in-progress state of the previous run is gone. Steering mutates a live run: the instruction lands inside the loop that is already executing, which adjusts course while keeping its accumulated context, plan, and partial results.

Agent steering is the ability to redirect, correct, or refine a running AI agent mid-run, without killing the run and starting over. The user injects new instructions while the agent works, and the agent incorporates them while preserving the work already done. Steering turns a one-shot request into a live collaboration: the user shapes the output in flight instead of waiting for a finished result and prompting again.

Steering names a capability, not a widget. An agent is steerable when its loop can accept new user input while it runs and fold that input into work already in progress. The pattern matters because it changes the basic economics of working with agents: a quick correction mid-run costs seconds, while the alternative, killing the run and starting over, costs everything the run had already produced.

Why steering exists

Two facts about agents collide. First, agents are long-running: they research, plan, call tools, and produce work over minutes, not milliseconds, which is why they break the request-response paradigm the web was built on. Second, instructions are never complete on the first try. Users discover what they actually want by watching work unfold: the brief was ambiguous, a constraint went unstated, the agent picked a reasonable but wrong interpretation.

In a request-response world, the second fact is cheap to live with: the response arrives in a second, so you refine and resend. With agents, the same fix is expensive. Without steering, the only remedy for a run drifting off course is to kill it and start over, which discards completed research, tool calls, and intermediate results, pays the full latency and token cost a second time, and does not even guarantee the good parts of the first run come back. Steering exists to make the correction proportional to the mistake: change the one thing that is wrong, keep everything that is right.

What steering looks like in practice

Concretely, steering is the user doing any of the following while the agent is mid-run:

Interjecting a correction. The agent starts querying the wrong environment and the user types “use the staging database, not production.” The agent redirects its remaining queries and keeps the analysis it has already assembled.
Tightening scope. A research agent fans out across ten sources; five results in, the user says the first two threads are the ones that matter. The agent drops the rest and goes deep instead of wide.
Changing priorities. Twenty minutes into drafting a report, the user says “skip the executive summary, focus on the migration plan.” The plan reorders; finished sections survive.
Canceling one branch while others continue. In a run with parallel workstreams, the user kills the branch that has gone stale without touching the branches that are producing.
Adding context the agent never had. “The client meeting moved to Thursday” arrives mid-run, and the schedule the agent is building absorbs it.

In every case the shape is the same: input lands inside a live run, the agent acknowledges it, revises its plan, and preserves the completed work the new instruction did not invalidate.

Steering vs. human-in-the-loop

Steering is often conflated with human-in-the-loop, and the two are siblings, but they differ on who initiates. In human-in-the-loop, the agent initiates: it reaches a checkpoint it decided was consequential, pauses, and asks the user to approve, edit, or reject before it proceeds. In steering, the user initiates: they inject input at a moment of their own choosing, whether or not the agent asked for anything.

The distinction is also one of rhythm. Human-in-the-loop is checkpoint-based: discrete gates at points the agent’s designer anticipated. Steering is continuous: the channel is open for the entire run, and the user can speak into it whenever the work on screen tells them to. Mature agentic applications use both, and both ride on the same underlying capability: a connection between user and agent that carries input in both directions for the lifetime of the run.

Steering vs. prompting again

Sending a new prompt is not steering. A new prompt starts a new run: the agent begins from the top, and whatever the previous run held in flight, its plan, its partial results, its accumulated context, is gone. Conversation history may carry over, but the work does not; the agent re-derives it or loses it.

Steering mutates a live run. The instruction lands inside the loop that is already executing, and the loop adjusts course while keeping its state. The difference is the difference between telling a contractor mid-job “move the outlet to the other wall” and firing the contractor, hiring a new one, and re-explaining the whole project with one sentence changed.

What steering requires from the stack

Three capabilities have to exist before an agent can be steered, and most stacks were built with none of them:

A bi-directional connection. Request-response gives the user exactly one moment to speak: before the run starts. Steering needs a channel that stays open for the whole run and carries user input upstream while agent output streams down.
An agent loop that absorbs input mid-run. The loop must check for new input at boundaries between steps, fold what it finds into its plan, and decide which in-flight work survives. An agent that runs to completion no matter what arrives is unsteerable regardless of transport.
State synchronization. The user and the agent have to see the same picture. If the interface shows a stale view of the run, the user steers against work that no longer exists; shared, continuously updated state is what makes the steering input coherent by the time it lands.

The AG-UI protocol, the Agent-User Interaction protocol, models agent steering as one of its building blocks: dynamically redirecting agent execution with real-time user input, alongside the streaming, shared state, and interrupt primitives the rest of the interaction rides on. CopilotKit implements this layer, giving any agent framework a steerable connection to a user-facing application.

Designing steerable agents

Steerability is a design property, and two decisions dominate it. The first is checkpoint granularity: how often the loop pauses to consume pending input. Check too rarely and steering feels ignored, with instructions sitting in a queue while the agent barrels on; the right granularity is the natural step boundary, after each tool call or reasoning stage, so a steer takes effect within one step of arriving.

The second is visible intermediate work. Users can only steer what they can see: an agent that goes silent for three minutes and returns a finished artifact offers nothing to steer against. Streaming the plan, the tool calls, and the drafts as they happen is what tells the user that a run is drifting while the drift is still cheap to correct. Two smaller decisions follow: acknowledge every steer explicitly, so the user knows the instruction landed, and be deliberate about what survives it, keeping completed work that remains valid and redoing only what the new instruction invalidates.

Put together, a steerable agent is one that works in the open, listens while it works, and treats new instructions as course corrections rather than reasons to start over. That is the standard agents are converging on, because it is how people already work with each other.