AI Learning Hub › Learn AI › Self-Paced Courses › Agents Without the Hype › When the Plan Changes
Module 6 ยท Intermediate
When the Plan Changes
Plans meet evidence. Adaptation, fallbacks and dead ends, and why flexibility about the route leaves the boundaries where they were.
By the end
- Explain how an agent can change route without changing the goal
- Distinguish a retry from a genuine adaptation
- Identify a permitted fallback
- Recognize when failure should trigger a stop condition instead
- Explain why a failed route does not expand the agent’s authority
- Describe recovery using observable actions and results
A plan is allowed to fail
Module 5 showed that results determine what becomes useful next. Every result in that module was helpful. This module asks the obvious follow-up:
What should happen when the next step does not work?
Sometimes the result is failure, absence, conflict, or something nobody anticipated. Adaptation means responding to that new state without quietly rewriting the job.
A fixed workflow is designed around a route selected in advance. An agent can operate differently: it may begin with a reasonable route and then discover that the route no longer fits the current state. A plan is useful because it gives the work direction. It is not useful if the system must follow it after the evidence says it no longer works.
Changing the route is not the same thing as changing the assignment. A failed step does not hand the agent permission to use prohibited sources, contact someone, upload material, create an account, change the requested deliverable, or ignore the stop condition. Adaptation happens inside the job’s boundaries.
Three more words to learn
Plan
A proposed route for pursuing the job that may change as results arrive.
Adaptation
A change in the next step or route in response to what the system has observed.
Fallback
An alternative permitted approach used when the preferred approach is unavailable or unhelpful.
“Plan” here means an observable proposed route — not a transcript of the model’s private reasoning. Depending on the product, a system may expose intended next actions, a task list, selected tools, milestones, or status information, and some products let you read and edit that before work begins. This course does not require access to hidden internal reasoning, and none of these three words is standardized vocabulary; they are how this course talks about the idea.
The obvious next step fails
Same job as the last four modules, same two tools, same boundaries. The briefing needs current information about whether the platform supports exporting research results, and no supplied source addresses it.
The reasonable next action is search_official_sources with query = "research results export". The result:
Result
No matching official sources found.
The action completed. The information need did not.
That distinction matters, and it is easy to skip past. Nothing broke. The tool did exactly what it was asked to do and reported honestly that there was nothing to report. A tool can work perfectly and still leave you no better off.
Repeating the same action is not automatically adaptation
Retry
search_official_sources
query = "research results export"
Again, unchanged.
Adapt
search_official_sources
query = "download research results"
Or query = "export project output" — recognizing that the provider may use different terminology.
A retry may be perfectly sensible when a service temporarily failed, a connection timed out, or the same operation has a reasonable chance of succeeding later. Nothing about the situation has to change for a retry to be worth trying.
But if the result itself tells you this query found nothing, simply repeating it may add nothing at all. The search did not fail; it succeeded and returned an empty answer. Adaptation changes something relevant in response to the result.
Watch a route change
This is an invented trace of observable actions and results, not a model transcript or a private reasoning record. Everything below was written for this tutorial.
Start
- Current state
- Need current primary-source evidence about exporting research results.
- Available
search_official_sourcesandopen_source. Boundaries unchanged.
Iteration 1 — the preferred route
- Action
search_official_sources- Input
query = "research results export"- Result
- No matching official sources found.
- New current state
- The exact terminology did not produce evidence. The information need remains.
Iteration 2 — adapt the query
- Action
search_official_sources- Input
query = "download project output"- Result
- Two official results: Download Your Project (current), Export Formats (current).
- New current state
- The alternate terminology exposed two candidate sources.
Iteration 3 — inspect
- Action
open_source- Input
source = "Export Formats"- Result
- The source describes several supported export formats for completed project results.
- New current state
- The required point now has official support.
Finish
- Next action
- Finish this line of research and use the source in the briefing.
What stayed the same
- the goal;
- the boundaries; and
- the tools.
What changed
- the route.
One word in a query, and everything downstream of it.
This is why current state matters
Module 5 defined current state and context close enough together that the difference may not have landed. This example separates them.
Context
The information available to the model.
Here: the result text, No matching official sources found.
Current state
The task-relevant situation now: what is known, what remains unresolved, what has already been attempted, what tools remain available, what boundaries still apply, and whether success or stopping conditions have been reached.
The sentence No matching official sources found becomes context. But the current state also includes that this approach has already been tried, that the need is unresolved, that the same boundaries remain, and that alternate permitted actions remain available.
None of those four are in the result text. Without them, the only obvious move is to run the same search again. Context supplies information. Current state describes where the job stands.
Failure did not start a new job
The failed search and the successful adapted search belong to the same run. Nothing restarted. No new assignment was issued.
A run can contain successful steps, unhelpful results, retries, adaptations, fallbacks, and eventual completion or stopping. All of it is one attempt at one job. A run is the whole attempt, not only the steps that worked.
Adapt the route, not the rules
A second kind of failure. Suppose open_source on Export Formats returns:
Result
Page temporarily unavailable.
But the same search also returned Download Your Project. A reasonable fallback is to open that one instead.
Notice what the fallback does and does not do. It serves the same information need, uses the same permitted source type, uses the existing toolset, and stays within the job. Nothing about the assignment moved. A fallback is useful because it offers another permitted route — not because failure erases the boundaries.
“Try something else” still has limits
Now the harder case. The official sources do not answer the required point. Outside the defined job, three things are technically possible: a private shared-drive file, emailing the vendor, and creating an account to inspect the product directly.
Should failure make those options available?
Reveal the discussion
Not under the job as defined. The original boundaries still apply, and they were not conditional on the research going well.
What the system can do is try another permitted primary-source approach, report the unresolved gap, or return control.
What it should not do is silently expand its own authority — and silently is the operative word. An agent that asks whether it may look at the shared drive is behaving reasonably. One that simply starts looking, because the approved route ran out, has replaced your judgment with its own.
A dead end does not grant new permission.
This is worth holding onto, because the reasoning that leads there is genuinely appealing: the goal is still unmet, the boundary is inconvenient, and the alternative would work. All three can be true, and the boundary still holds.
Sometimes there is another route. Sometimes there is not.
Fallback available
The preferred official page is unavailable, but another current official source may address the same question.
Try the permitted alternative.
No permitted fallback
The permitted primary sources do not answer the question, and every remaining option would cross a boundary.
Use the stop condition or return control.
Adaptability includes knowing when not to adapt further.
Recovery should not erase what happened
The run above ended well. A reader seeing only the briefing would never know that the first search found nothing.
That may be fine. But if you are supervising the work, what you often need to know is what was attempted, what result came back, and what changed afterwards. A first search that found nothing is a fact about the evidence, not just a fact about the agent. A successful ending does not make the failed steps irrelevant.
“It didn’t work” can mean different things
No useful result
The tool worked, but the result did not answer the need.
Search returned zero matches. Adapt the query, or stop.
Tool unavailable
The intended capability could not complete its operation.
Page temporarily unavailable. Retry, or use another permitted source.
Evidence conflict
The available information disagrees.
Inspect provenance, look for newer permitted evidence, or surface the conflict.
These are three different problems wearing the same sentence. “Failure means retry” is the right answer to exactly one of the three, and the wrong answer to the other two.
When two sources disagree
Suppose two current-looking official pages disagree about whether a particular export format is supported.
The tempting move is to pick one. It resolves the state, it lets the run continue, and it produces a briefing. It is also the one move that destroys the most information.
Better options are all forms of looking harder: inspect the dates, inspect which product or version each page describes, search for a current authoritative clarification, or report the conflict if it cannot be resolved. Adaptation can mean investigating uncertainty rather than choosing a convenient answer.
Retry, adapt, fallback, or stop?
Four independent situations. For each, decide the most reasonable next move.
Situation A
search_official_sources returned zero results for "research results export", but the provider’s documentation frequently uses the word “download” rather than “export.”
Situation B
open_source returned a temporary service error for a source that appears directly relevant. No other candidate source has been found yet.
Situation C
The preferred official page is unavailable, but another current official page returned by the same search appears to address the question.
Situation D
No permitted primary source answers the question. The only remaining possibilities would require contacting the vendor or using private files, both outside the job’s boundaries.
One possible review
- Situation A
- Adapt. Change the query while keeping the same source boundary. The search worked; the wording did not match the provider’s.
- Situation B
- Retry. A temporary execution failure may justify trying the same operation again. But repeated failure should eventually cause another choice rather than unlimited retrying — at some point the retry has become the thing that is not working.
- Situation C
- Fallback. Inspect the alternate permitted source. The need is unchanged and a permitted route remains.
- Situation D
- Stop and return control. Report the unresolved gap. Every remaining route crosses a boundary, so there is nothing left to adapt to.
Notice that A and B look similar on the surface — both are “the step did not get me what I needed” — and call for opposite responses. The difference is why it failed: A returned a real answer that happened to be empty, B did not return an answer at all.
The useful response follows from why the previous step failed and what the job still permits.
A plan can change. A prescribed workflow does not change itself.
Here is the shortcut to avoid this time.
A software workflow can absolutely contain branches, retries, exception handling, and fallback paths. Those paths can be elaborate — a well-built workflow may handle a timeout more gracefully than an agent would. Recovering from a failure is not, by itself, evidence of anything.
The Module 1 distinction has not moved: it is about who selects among routes, and whether the route was substantially predetermined. A workflow’s fallback was chosen by a person, in advance, for a failure they anticipated. An agent may encounter a failure nobody anticipated and choose a response that was never written down. Adaptation alone does not prove something is an agent. A fixed workflow can have fallback logic too.
Module 5 warned against loop means agent. This is the same warning wearing a different coat.
A plan is provisional
A reasonable agent may begin with search → inspect → summarize, and later discover that search → inspect → search differently → inspect → summarize better fits the state it encountered. A useful plan provides direction without pretending future results are already known.
The temptation, having watched a plan fail, is to plan harder next time — to anticipate every branch in advance. Resist it. A plan that specifies every possible response to every possible result is no longer a plan. It is the workflow from Module 1, and you have given up the thing that made the agent useful.
What changes, and what stays fixed?
Usually fixed unless the human changes it
- the goal;
- the success condition;
- the boundaries; and
- what the system is allowed to do.
May change during the run
- the current state;
- which tool is useful;
- the tool input;
- the proposed route; and
- whether a fallback is needed.
What to notice
Adaptation is not permission to improvise without limits.
The system may change its query, its next tool, which source it investigates, whether it retries, and whether it stops.
It should not quietly change the user’s goal, the relevant boundaries, the permitted source types, or the actions it is allowed to take. A flexible route can still operate inside a fixed job.
Before you continue
You are ready for Module 7 if you can:
- explain what a plan means in this course;
- distinguish retry from adaptation;
- identify a permitted fallback;
- explain how failure changes current state;
- explain why failed steps remain part of the same run;
- recognize when stopping is better than finding another route;
- explain why a failed route does not expand the job’s boundaries; and
- explain why adaptation alone does not prove a system is agentic.