Understanding the Core Elements of a Simple Agent Scenario

Hello! In the previous lesson, you saw how an agent can use a search result to decide what to do next. Now we will make that process easier to inspect. By the end of this lesson, you should be able to look at a simple agent scenario and identify five things: its goal, state, available actions, observations, and stopping condition.

These are not five names for the same thing. The most important distinction is between an observation—what just came back from an action—and state—the working record the agent carries forward.

Five questions that describe an agent run

Imagine an agent helping with a small research request. To describe its run, ask:

• Goal: What result is it trying to produce?
• State: What does it currently know about its progress?
• Actions: What is it allowed to do next?
• Observations: What results has it received from those actions?
• Stopping condition: When should the run end?

A goal describes the desired result, not a script of every step. State is the agent’s current working record: it might contain facts found so far, unanswered questions, searches already tried, and the number of tool calls used. An action is something the agent chooses from the options its application permits, such as searching a source. An observation is what the application reports back: a passage, “no results,” or an error.

The IBM diagram below shows a broader version of this idea. Its “sensors” and “actuators” are useful labels even when an agent has no physical body. For a research assistant, a search-tool result can serve as a perception, and a permitted tool call can serve as an action.

Notice the box labelled “State” inside the agent. It is not the same as the entire outside world. The agent may have an incomplete or mistaken picture of that world; its state records the information available to it. A fresh observation can change that record.

Watch the central explanation in IBM Technology’s What is OpenClaw? Inside AI Agents, LLMs and the Agentic Loop. You do not need to learn the product discussed in the video; focus on what happens to information between tool calls.

The model does not directly watch a webpage change or execute a search by itself. As in the previous lesson, the surrounding application performs permitted actions and supplies their results. State is what the system retains and makes available for subsequent decisions; the model can only use the parts it is given.

A scenario we can inspect

Consider this invented request:

“Which opens earlier on Saturday, Garden A or Garden B? Give both opening times and a supporting passage from each garden’s posted hours.”

Suppose the agent is allowed to use a source-search tool that returns passages from posted opening-hour pages. It may search again with different wording, and it may give a final response. It cannot change the gardens’ hours, and it should not invent hours that a returned passage does not contain.

The goal is more precise than “find some hours.” A successful response must contain both Saturday opening times, identify which is earlier, and support each time with a passage. That precision matters: a passage about weekday hours may be genuine information, yet still fail to answer the request.

At the start, a useful snapshot of state would say: “Saturday time for Garden A: unknown. Saturday time for Garden B: unknown. Supporting passages: none. Searches used: zero.” The goal and the state are related but different. The goal states what must ultimately be true of the answer; the state records how far the agent has got.

Now follow three possible passes through the run. These are made-up tool results, not claims about real gardens.

First pass. The agent searches for “Garden A opening hours.” The tool returns: “Weekday hours: 09:00–17:00.” That text is the observation. The agent should not silently turn 09:00 into a Saturday opening time. Instead, its state now records that the first search found weekday hours, while Saturday hours for both gardens remain unknown. Because of that observation, a sensible next action is a more specific search for Garden A’s Saturday hours.

Second pass. The new search returns a passage from Garden A’s posted hours: “Saturday: 10:00–16:00.” The observation supplies one needed fact. The state can now record Garden A’s Saturday opening time as 10:00, retain the supporting passage, and mark Garden B’s Saturday time as unknown. The agent has made progress, but it should not stop: it cannot yet compare the two gardens.

Third pass. The agent searches for Garden B’s Saturday hours and receives: “Saturday: 09:00–15:00.” It records Garden B’s 09:00 opening time and its supporting passage. It now has enough information to report that Garden B opens earlier on Saturday: 09:00 is earlier than 10:00. Its response should point to the two passages, rather than treating the irrelevant weekday passage as support.

The key change from pass to pass is not the goal—it stayed the same. What changed was the state, informed by each observation. That is why the agent chose a more specific search after the first result and a search for the other garden after the second.

Observation versus state: the distinction worth keeping

It is easy to call everything the agent has seen “state.” For analysis, a sharper distinction helps:

An observation is a result received at a particular step. State is the working record available when choosing a later step.

The sentence “Saturday: 10:00–16:00” arrives as an observation. Once the system retains the time, its source passage, and the fact that Garden B remains unresolved, those items form part of the updated state. The same passage can therefore inform state without the two terms meaning the same thing.

This distinction also handles errors. Suppose the search tool returns “request timed out.” That error is an observation; it is not evidence about either garden’s hours. The state might record that the attempted search failed and that Garden B’s Saturday time is still unknown. If the agent instead stores “Garden B is closed,” it has made an unjustified leap.

State need not be a special memory system. In a small agent, it could be a short record held by the surrounding program and included with the next model call. What matters here is its job: preserving enough of the run that the next choice can depend on what actually happened. Later in the course, you will represent this changing record with Python data structures.

MindStudio’s Agent Loops Explained: Trigger, Action, and Stop Condition adds two practical points: an agent needs to retain progress across cycles, and “stop when done” is too vague to be a reliable rule.

The article also discusses triggers, which are worth keeping separate from our five labels. A trigger is what starts a run—for example, receiving the garden question. It is not the goal: the goal describes the result the run is supposed to achieve.

“Stop” does not always mean “success”

For the garden agent, an explicit success stopping condition could be:

Stop with an answer once the state contains a Saturday opening time and supporting posted-hours passage for each garden, so the times can be compared.

This rule explains why the agent did not stop after finding Garden A’s time. It also prevents a confident-sounding answer based only on weekday hours.

The application should have a fallback stopping condition too—for example, a maximum of four searches. Suppose the fourth search still produces no Saturday hours for Garden B. The run must end, but the goal has not been met. A suitable final response would say that it found Garden A’s Saturday time but could not verify Garden B’s, so it cannot reliably say which opens earlier.

There is a subtle difference between an action and a stopping condition here. Giving a final response is something the agent can do. Having enough supported information, or reaching a safety limit, is the condition that tells the system when to end the run. A model may propose an answer too early; the mere act of producing one does not prove that the success condition was satisfied.

This gives you a way to read any simple agent scenario without memorising a definition in isolation. If a sentence describes what is wanted, it belongs to the goal. If it describes what is currently recorded, it belongs to state. If it describes a permitted choice, it is an action. If it describes what came back after that choice, it is an observation. If it says when the run must end, it is a stopping condition.

Takeaways

An agent run becomes easier to understand when you separate its fixed goal from its changing state. It chooses among permitted actions, receives observations, updates what it knows, and checks a stopping condition. A successful stop means the stated requirements have been met; a fallback stop means the run has ended safely, possibly without an answer.

In the next lesson, you will use this way of describing tasks to decide when an agent is actually useful—and when a fixed workflow or an ordinary program would be the better choice.