AI Learning Hub › Learn AI › Self-Paced Courses › Agents Without the Hype › Let It Take More Than One Step

Module 5 · Beginner

Let It Take More Than One Step

One result changes what the next step should be. How iteration works, how a run differs from a single response, and why the route cannot be written down in advance.

By the end

Explain why a multi-step agent does not have to know its entire route in advance
Identify the current state of a task at a particular moment
Recognize one iteration of an agent process
Explain how a result can affect the next action
Distinguish a model-directed sequence from a fixed workflow
Explain how the system knows when to finish or return control

One tool call is not the whole story

Five modules, five questions:

Module 1 — Who decides what happens next?
Module 2 — What job and limits has the human defined?
Module 3 — What information is available?
Module 4 — What capabilities can the system use?
Module 5 — How can the result of one step change what happens next?

Module 4 ended mid-sentence, in a way. The model noticed a gap, selected a tool, supplied an input, the tool returned a result, and that result became available for the next decision.

Then what?

The new result may answer the question, reveal another question, make a different tool useful, show that the requested information cannot be found, satisfy the success condition, or trigger the stop condition. The result changes the situation the next decision is based on.

Three more words to learn

Current state

The information about the job, context, available capabilities, and results so far that matters to the next decision.

Iteration

One pass in which the system chooses a next step, receives or observes the result, and reaches a new current state.

Run

The period of work from the beginning of an agent task until it finishes, stops, or returns control.

These are simplified for teaching, with one exception. Run is a real term of art: OpenAI’s guidance says every orchestration approach needs the concept of a run, and describes it as a loop that continues until an exit condition is reached. Current state is close to source language but broader here than where OpenAI uses the phrase. Iteration is this course’s word. The Sources section sets all three beside the originals.

Watch the job change step by step

This is an invented example of observable agent behavior. It is not a transcript from a model, and it does not reveal private reasoning. Every action, input, and result below was written for this tutorial. What it shows is the shape of the process — the things you could watch from outside — not what any system was thinking.

The assignment, still unchanged

Prepare a one-page background briefing for a faculty member who is considering whether to explore a new AI research platform.

Tools available: search_official_sources and open_source. Boundaries unchanged: no account creation, no uploading Stanford materials, no contacting the company, no changes outside the research session.

Start

Available: The bounded briefing job, the selected reference materials from Module 3, and the two research tools from Module 4.
Known gap: The supplied materials do not clearly explain how uploaded documents are handled.

What useful action is available?

Iteration 1

Action: search_official_sources
Input: query = "document uploads privacy"
Result: Three official sources returned: Product Overview (current), Data Use Overview (current), Document Handling FAQ (current).
New current state: Three possible sources may address the gap. The briefing is not yet complete.

Iteration 2

Action: open_source
Input: source = "Data Use Overview"
Result: The page explains how uploaded material is processed and whether it is used to improve the service, but it does not state how long uploaded documents remain available.
New current state: One question is partly answered. A narrower question remains: how long are uploaded documents retained?

Iteration 3

Action: search_official_sources
Input: query = "uploaded documents retention"
Result: One official result: Document Retention Help Article (current).
New current state: A specific source is available to inspect.

Iteration 4

Action: open_source
Input: source = "Document Retention Help Article"
Result: The help article states a defined retention period for uploaded documents and identifies when deletion occurs.
New current state: The missing point can now be supported by an official source. The success condition can be reassessed.

Finish

Next action: No additional research tool is needed for this question. The system can proceed to the briefing using the evidence gathered.

The important thing is not that this took four iterations. It might have taken one, three, six, or none. Nobody specified a number, and no number was available to specify — the second search only became a good idea once the first source turned out to be incomplete. The sequence emerged from what each result made useful next.

The route was not written in advance

Here is the uncomfortable part. Write down what the example did:

The agent run above

search → open → search → open → finish

Later actions depended on earlier results.

A fixed workflow

search → open → search → open → finish

The route was selected before those results existed.

They are the same five steps. After the fact, the two are indistinguishable from the sequence alone. You cannot identify an agent merely by looking at how many steps it completed. You need to know how those steps were chosen.

That is Module 1’s question arriving in a new disguise. There it was easy, because the descriptions told you who chose. Here you are looking at a finished trace, and the trace does not say.

Each result changes what “next” means

Follow the current state through the demonstration:

Before Iteration 1: We need information about document handling.
After Iteration 1: We have three possible sources.
After Iteration 2: Part of the question is answered, but retention remains unresolved.
After Iteration 4: The missing point has evidence.

The job stayed the same. The current state did not.

Current state is broader than the context of Module 3, though context is part of it. Depending on the system it may reflect the original job, the boundaries, useful context, which tools are available, the tool results received so far, what remains unresolved, and whether completion or stopping conditions have been met.

One iteration changes the next decision

The pattern underneath all four iterations is the same four moves:

Choose — select a useful next step from the options available.
Act — perform that step, which may include calling a tool.
Observe — receive the result or outcome.
Update — the current state now includes what was learned or what changed.

Then the system may decide again.

You do not need the model’s private reasoning

To supervise an agent, you can often inspect observable things: the job, the tool selected, the tool input, the returned result, the action taken, the final output, and whether the system stopped or continued.

This tutorial does not attempt to display hidden internal reasoning, and the demonstration above contains none. Every line of it is something you could watch from outside.

Observable actions are enough to understand the structure of the process — which is fortunate, because they are also what you will actually have.

The whole sequence is one run

A run begins when the system starts working on the assigned job. It ends when, for example, the success condition has been reached, a stop condition is reached, the system cannot continue, the human takes control, or some other implementation-specific exit condition occurs.

Products implement runs differently, and what counts as the end of one is partly a product decision rather than a universal fact.

A loop needs a reason to end

Repeating actions indefinitely spends time and money without moving the job forward.

At each relevant point, the system needs some way to determine whether enough has been accomplished to finish, whether continuing would violate a boundary, whether required information is simply unavailable, or whether human input is needed.

You already have the vocabulary for this. Module 2’s success condition says we have enough to finish. Its stop condition says we should stop even though the goal is incomplete. Those are the two reasons a run ends well, and this module is where they earn their keep: they were written before the work started, and they are what the system checks against as the state changes. “Keep going” is not a complete operating rule.

You may meet a third phrase. OpenAI calls the conditions that end a run exit conditions, and lists things like a final output, an error, or a maximum number of turns. That is the same territory as success and stop conditions, described from the implementation side. This course does not add it as a fourth term, because two are enough to think with and a third near-synonym would only blur them.

Repeating is not enough

Consider a system that always searches exactly three times, opens the first result after each search, then writes a summary.

Does repetition make this an agent?

Reveal the discussion

Not under the working distinction in this course.

The path is still substantially predetermined. It repeats, but the result of one iteration does not meaningfully determine the structure of the next — the third search happens whether or not the first two answered the question, and the first result gets opened whether or not it is the most promising one. A loop can be a workflow too.

This is worth guarding against, because “it loops, therefore it is an agent” is exactly the kind of shortcut Module 1 warned about, just with a new surface. Repetition is not the test. Conditional repetition is.

And an agent does not have to use every opportunity

The opposite mistake is just as easy. Suppose the initial context already contains enough verified information to complete the briefing. The model may decide that no research tool is needed at all. Or one search might completely answer the missing question, and the run ends after a single iteration. Agentic architecture does not require a long visible chain of actions on every task.

The ability to make the route conditional matters more than the number of steps actually taken. A system that could have searched five times and correctly searched zero is behaving exactly as designed.

Which next step fits the current state?

Four moments in a task, each described by its state alone. For each, decide what next step is useful. Your options are the same two tools — search_official_sources and open_source — or finish and report.

State A

The briefing requires current information about whether the platform supports citation export. None of the supplied context addresses it, and no candidate source has been found yet.

State B

A search returned one current official page titled “Citation Export Guide,” but its contents have not been inspected.

State C

The opened official guide directly answers the question and provides enough current information for the briefing.

State D

Two searches found no official material addressing the required point. The job permits only primary sources and says unsupported gaps should be identified rather than filled in.

Work through all four before opening this.

One possible sequence

State A: search_official_sources — because there is not yet a source to open.
State B: open_source — because a candidate source now exists.
State C: Finish that line of research — rather than searching merely because a search tool remains available.
State D: Report the gap, using the stop condition — rather than changing the source rules or guessing.

Notice that these four states do not form a single story. search → open → finish is one path through them. search → search → stop is another. Both are correct, for different runs.

The correct next step depends on the current state, not a universal script. That is why the exercise gave you states rather than a sequence: if you could answer from position alone, the route would have been fixed after all.

Same toolbox, different path

Three runs of the same job, with the same two tools and the same boundaries:

Run A

Initial material is sufficient.

finish

Run B

Important evidence is missing.

search → open → search → open → finish

Run C

Required evidence cannot be found within the permitted sources.

search → search → stop and report the gap

The job and toolbox can stay the same while the path changes because the results differ.

Run C is worth a second look. It ends without completing the briefing, and that is the stop condition working exactly as Module 2 intended.

What if the expected path does not work?

So far, every tool in this module has worked normally. Searches returned results, pages opened, information was consistent.

Real tasks are messier. Searches return poor results. Pages are unavailable. Information conflicts. A chosen approach fails. The system discovers that its original route will not work at all.

The next question is whether the agent can change course without leaving the job’s boundaries — which is Module 6.

The pieces now move

The human defines

the job;
success and stopping conditions;
important boundaries;
starting context; and
available capabilities.

During the run, the agent may

assess the current state;
select a permitted next action;
receive a result;
incorporate that result;
choose again; and
finish or return control.

Agent behavior emerges from repeated decisions inside a human-defined environment.

Note what that sentence does not say. Not that the system thinks for itself, not that it decides everything, and not that it works autonomously. It makes repeated decisions, of a kind someone specified in advance, inside limits someone else set.

What to notice

What makes a multi-step agent interesting is that the repetition is conditional.

Each useful result can change:

what is known;
what remains unresolved;
which capability is useful; and
whether another step is necessary.

The next step is a function of the current state, not simply the next line in a script.

Before you continue

You are ready for Module 6 if you can:

explain current state in plain language;
identify one iteration of a multi-step process;
explain how a tool result can change the next action;
distinguish a conditional agent path from a fixed repeated workflow;
explain why an agent may finish after zero, one, or many tool calls;
identify success or stop conditions that can end a run; and
describe observable agent behavior without relying on hidden chain-of-thought.