Changing requirements mid-task without throwing away completed work
Real projects change while work is in progress. A customer changes a requirement, a security team rejects an approach, a manager says the output must be ready for a different audience, or a production incident becomes more important than the original task. Older AI workflows handled this badly: the user stopped the task, rewrote the prompt and began again.
How does direction change without losing valid work? Frontier systems are moving toward keeping the useful work, changing the direction, and continuing.
A Short Reminder: Steering Is Not the Same as Starting Over
Steering means introducing new instructions while a task is already underway and incorporating them into the remaining work. The system must decide what completed work remains valid, which assumptions are now wrong, what must be undone, which pending tool calls are still useful, and whether the new instruction conflicts with safety or authorization rules.
Chapter 9 explained how work survives failure. This chapter is about how it survives a change of mind, which is harder, because nothing broke.
Astra Makes Mid-Turn Steering Explicit
OpenAI documents mid-turn steering for Astra through a WebSocket continuation flow. A user can send a correction or changed requirement while the model is working, and the Responses API preserves completed work and includes the update in the continuation. This treats steering as a first-class system capability rather than an accidental consequence of chat history.
Preserving Work Requires Dependency Awareness
Suppose an agent is preparing a migration plan with four sections: database, network, application and testing. Halfway through, the user changes the target cloud region. The network design may need to be redone, the testing methodology may remain valid, some cost calculations are now wrong, and the database migration sequence may need only minor adjustment.
A useful agent does not discard everything. It identifies which pieces depend on the changed assumption. Good steering requires more than obeying the newest sentence; it requires understanding how the new instruction changes the dependency graph of the work already completed.
A New Instruction Can Invalidate State
State should not be treated as permanently correct simply because it was previously verified. A requirement change can make an earlier checkpoint obsolete. State records should therefore include the assumptions or plan version under which they were produced, so that when those assumptions change the system can mark dependent work as needing review rather than silently carrying it forward.
This is the connection between the two chapters: a checkpoint records what was true, and steering is the event that decides whether it still is.
Steering Can Change Reasoning Effort Too
Astra also allows an application to change reasoning effort during a conversation while preserving the cached prefix. That is another form of steering: not changing the goal, but changing how much computation the model should spend on the next stage. A system might use lower reasoning during routine drafting, then increase it when a security-sensitive design decision appears.
Side Questions Should Not Destroy the Main Task
OpenAI describes Astra as able to answer side questions and incorporate new requirements without losing track of the broader task. That requires the system to distinguish temporary conversation from durable goal changes. If the user asks "Why did you choose this library?", the agent should answer without treating the question as a new project objective.
When Steering Becomes a New Task
Not every change is a correction. Some changes alter the goal itself, invalidate most of the completed work, or require authority the task was never granted. Treating those as steering produces a task that carries the residue of its old objective: stale checkpoints, assumptions nobody re-examined, and permissions granted for a narrower scope.
A practical test has three parts. If the objective is still the same and only inputs or constraints changed, steer. If the objective has changed but most artifacts are reusable, close the task, keep the artifacts, and start a new task that imports them deliberately. If the change needs authority the original task did not have, it is a new task by definition, because authorization was granted for the old one. The judgement is familiar engineering work: decide whether the existing task can still be trusted, or whether the new objective deserves a clean boundary.
Human Intervention Is Part of the Architecture
Steering is one form of human control over an autonomous workflow. Others include pausing, approving, rejecting, changing priority, reducing scope, adding new evidence, and taking over a step manually. A long-running system should make these interventions possible without forcing the user to reconstruct the entire task from scratch.
Conflicting Instructions Need Resolution Rules
Mid-task steering creates instruction conflicts. A new user instruction may conflict with an earlier user requirement, a system policy, an organizational constraint, an approval already granted for a narrower scope, or a safety boundary. The newest user instruction should not automatically override higher-priority policy or extend authority. Chapter 12 returns to where that rule is enforced.
Where It Can Still Fail
The newest instruction erases an older constraint. The model follows the change and forgets a requirement that did not change.
Hidden dependencies survive. Completed work is reused even though an assumption beneath it moved.
A pending result arrives after the turn. An asynchronous tool call returns for a task that has already changed direction.
A question becomes a goal. The agent treats a side question as a new objective.
A change smuggles in authority. A user request quietly expands permissions beyond what was originally authorized.
A capable long-running model must remain interruptible, and interruption must be cheap enough that people actually use it.
The goal of autonomy is not to remove human control. It is to preserve useful progress while allowing human judgment to change the direction when reality changes.
Three Things to Remember, One Thing to Do
1. Steering should preserve valid work and invalidate only what the new requirement changes.
2. Requirement changes should update state and permissions, not merely add another sentence to context.
3. Human intervention is a core control mechanism for long-running AI, not evidence that autonomy failed.
One thing to do. Take one task an AI system completed for you and invent a single requirement change. Before re-running anything, write down which outputs survive and which are invalidated, then apply the three-part test above to decide whether it is a steer or a new task. If you do re-run it with the change, compare what the system kept against your list.
How much do you need? Platform/DevOps: Master · Developer: Use · Architect: Use. Everyone else: Know.