How do you steer an AI agent mid-run without restarting the whole investigation?

An incident agent was investigating the wrong environment.

The operator noticed early and sent a short correction: “Use staging, not production.” The feedback was accepted by the interface. The run continued. The agent delivered the original production-focused answer anyway.

Nothing crashed. The correction was stored. The audit trail even showed that it arrived.

It simply reached the agent too late to matter.

Mid-run AI agent steering is not a messaging feature. It is a control-flow problem. Getting it right means rethinking the easy answer first.

Why Restarting Is the Wrong Default

The easy answer is to cancel the run and start again with a better prompt.

That wastes:

  • evidence already gathered,
  • tool calls already paid for,
  • context the operator still trusts,
  • and time during an active incident.

It also forces the human to restate the task, copy useful findings, and explain which parts should survive.

A good steer means: keep the valid work, change the direction from here.

That is different from both a new task and an approval decision. Approval asks whether a proposed action may proceed. Steering changes how the current task should proceed.

The First Failure: Feedback Waiting at the Wrong Boundary

Long-running agents have natural checkpoints: after a model turn, after a tool result, before the next planning step, and before completion.

If feedback is only checked when the task finishes or becomes stuck, a healthy-looking run can sail past the correction. The operator’s message sits in a queue while the model continues from stale assumptions.

The next iteration boundary is the useful handoff point:

  1. Finish the in-flight operation safely.
  2. Check for pending operator feedback.
  3. Add the feedback to the active working context.
  4. Let the next reasoning turn respond to it.

Interrupting arbitrary code in the middle of a tool call is risky. Waiting until the entire task ends is useless. Iteration boundaries provide a controlled middle.

This resembles asynchronous human approval: human input must join a live workflow without freezing unrelated work or corrupting state.

The Second Failure: An Empty Interrupt

We fixed delivery timing and found another bug.

The runtime forced an extra turn for the feedback. The model produced little or nothing, then the task closed with the answer it had prepared before the correction. Technically, the feedback had been “processed.” Behaviorally, it had been ignored.

This is why acknowledgments are not proof.

The system needs a completion debt: once valid feedback arrives, the run is not complete until the next output addresses it or explains why it cannot.

That does not require the model to obey every request. The steer may conflict with policy, evidence, or the task’s scope. But the final answer must make the disposition visible:

  • incorporated,
  • rejected with a reason,
  • or blocked pending clarification.

Silence is not a disposition.

Steering Should Usually Be Additive

The most useful operator corrections are extensions:

  • “Also check the staging cluster.”
  • “Prioritize customer impact.”
  • “Do not restart anything.”
  • “Compare this with yesterday’s deployment.”

Replacing the whole task with the steer can erase the original objective. Ignoring the steer preserves the objective but misses the correction.

The default should be additive:

Continue pursuing the original goal, with this new constraint or direction.

Replacement still has a place, but it should be explicit: stop investigating the original target and switch to a new one. Treating every short message as replacement makes terse operational feedback destructive.

This is especially important in chat and incident channels, where people communicate in fragments.

Reject Empty No-Ops

Human interfaces generate noise: blank messages, accidental reactions, duplicated events, and whitespace-only inputs.

An empty steer should not:

  • force another expensive model turn,
  • mark feedback as handled,
  • delay completion,
  • or change the final answer.

Validate feedback at the boundary. If it contains no instruction, reject it visibly and leave the run alone.

This sounds minor until a no-op interrupt consumes a limited recovery opportunity available to a stalled task.

Acknowledge Quickly, Apply Carefully

Operators need immediate confirmation that their correction was received. Otherwise they repeat it, creating conflicting or duplicate steers.

A short status message is enough:

Direction received. Applying it on the next investigation step.

That acknowledgment should not claim the change is complete. It only confirms queueing.

The final response provides the second receipt:

  • what changed,
  • which earlier findings still apply,
  • and what the new direction uncovered.

This two-receipt model — received, then applied — makes the workflow legible without flooding the channel.

Steering Is a Governance Surface

Mid-run feedback can change tool choice, target environment, and the interpretation of evidence. It needs the same identity and policy discipline as the original request.

Questions to answer:

  • Who is allowed to steer this run?
  • Can one user redirect another user’s task?
  • Does a steer inherit the original permissions?
  • What happens when two corrections conflict?
  • When does old feedback become stale?
  • Can a steer expand the task into a higher-risk action?

Steering must not become a side door around approval. “Use production instead” should still encounter the production policy boundary. Human input changes intent; it does not grant authority.

When Not to Use a Steer

Start a new task when:

  • the new request has a different goal,
  • the old evidence would bias the new investigation,
  • permissions or ownership have changed,
  • or the original run has already committed an irreversible action.

Use a steer when the operator is correcting scope, priority, constraints, or emphasis inside the same goal.

That distinction prevents one immortal conversation from accumulating unrelated work forever.

Lessons Learned

  1. Check feedback between iterations. End-of-run delivery is too late; mid-tool interruption is too risky.
  2. Feedback creates completion debt. The run must address it before claiming done.
  3. Add by default, replace explicitly. Most operational corrections refine the goal rather than erase it.
  4. Reject empty feedback. A no-op should not consume time, budget, or recovery opportunities.
  5. Use two receipts. Confirm receipt quickly, then show how the final result changed.
  6. Keep policy in force. Steering changes direction, not authority.

Human-in-the-loop should mean more than approving a button at the end. Sometimes the safest and most useful human action is turning the wheel while the agent is still driving.

Acknowledgments. Built with the StackGen Aiden team — the engineers behind the agent runtime and platform this series describes.

Where should operators be able to redirect your agents without restarting the task? Find me on GitHub or LinkedIn.

🚀 We’re building AI-powered SRE at StackGen. If you’re tired of 3 AM pages and want AI agents that triage incidents, run diagnostics, and draft RCA reports — check out ai.stackgen.com and try our new SRE offering.