The Goal–Action–Observation Loop and the Language Model’s Role

Hello! Last time, you distinguished a chatbot, a fixed workflow, and an agent by asking who decides what happens next. An agent gives the language model a bounded role in making that decision.

This lesson looks inside that decision-making process. You will see how an agent pursues a goal, chooses an action, receives an observation, and decides whether to continue. The same pattern will later become the core of the small research assistant you build in this course.

A goal is not a list of instructions

Consider the request: “Find when a public library first opened, and check the date against two sources.” That is a goal: it describes the result you want. It does not specify which search to make first or what to do if the first result discusses a renovation rather than the original opening.

An agent can make those intermediate choices. It has access to permitted actions, such as searching for information. After each action, it receives an observation—perhaps a search result, a passage from a source, or an error. The observation may change what the agent should do next.

The diagram below captures the basic arrangement. Notice that the human supplies the task, while the language model interacts with an environment and may eventually stop.

The curved lines are easy to misread as one language-model call continuously watching the outside world. In a typical implementation, the surrounding program calls the model, carries out a requested action, and then calls the model again with the result. The model can take the result into account because the program supplies it, not because the model directly observed the world.

Watch these portions of Tech With Tim’s AI Agents Explained for a close look at that division of labor.

The phrase “the model uses a search tool” is convenient shorthand, but the video makes the mechanics more precise. The model produces a request to search; the application runs the search and returns its output. The model then considers that output when choosing what to do next. It may request another permitted action, or it may produce a final answer.

Why the observation matters

Suppose the first search result says, “The library was renovated in 2018.” If the goal is to find when it first opened, 2018 does not answer the question. The useful next action might be a more focused search for the original opening date. Without examining the observation, the agent could mistake the first date it saw for the answer.

This is the heart of the goal–action–observation loop:

1. The agent considers the goal alongside what it has learned so far.
2. The language model chooses a next action from the options the system permits.
3. The surrounding application carries out that action and returns an observation.
4. With that observation available, the model decides whether another action is needed or whether it can answer.

The goal stays in view throughout; the observations can change the route. An observation might be useful evidence, an irrelevant result, conflicting information, or a tool error. None of these automatically tells the agent what to do. The model must interpret the result in light of the goal—though it can interpret it incorrectly.

One established way to describe this pattern is ReAct, short for reasoning and acting. Read IBM’s explanation for a nontechnical example and its discussion of when a loop ends.

ReAct is one way to organize an agent; not every agent needs to display a written “thought” at each step. The essential idea for this lesson is simpler: a result from the world informs the next model-directed choice.

One research task, several passes through the loop

Let us follow a complete example. The library and search results below are invented; they illustrate an agent run, not facts about a real place. The goal is to find the year a library originally opened and support it with two independent sources. The permitted action is to search for source passages.

On its first pass, the model requests a search for the library’s opening date. The search tool returns a passage about a 2018 renovation. That passage is an observation, but it is not yet an answer. The model compares it with the goal and notices the mismatch: a renovation date is not necessarily an original opening date. It requests a more specific search.

The second search returns a directory entry saying the library opened in 1998. The model now has a candidate answer, but the request asks for two sources. If it stops here, it has not met the whole goal. It requests another search aimed at finding an independent account.

The third search returns a newspaper excerpt describing an opening ceremony in 1998. The model can now produce an answer that names the year and points to both passages. It should not present the 2018 renovation as evidence for the opening year; that observation was useful chiefly because it showed the first search was off target.

Notice what repeated and what changed. The model considered the same overall goal more than once, but its next search depended on the result of the previous one. A fixed workflow could certainly be programmed to perform three searches in a set order. Here, the agent’s defining role is choosing a more specific search because the first result was about a renovation, then searching again because it had only one relevant source.

The observation does not have to be a successful search result. If a tool reports “no results,” the model might try different wording. If two sources disagree, it might investigate the disagreement instead of declaring a winner. If the tool fails repeatedly, the right final response may be that the answer could not be verified. Continuing the loop is useful only when another permitted action has a reasonable chance of improving the answer.

The model decides, but the system sets boundaries

It helps to keep three roles separate. You provide the goal. The language model proposes the next step using the goal and the information it has been given. The surrounding application decides which actions are available, executes valid requests, and supplies the resulting observations. That application can also enforce limits, such as a maximum number of steps.

This separation matters for both understanding and reliability. A model cannot retrieve a fresh source merely by writing, “I searched.” A search happened only if the application actually ran a search tool and returned its result. Likewise, a model’s statement that it has “finished” does not prove that it met the goal. In the library example, an answer based solely on the directory entry would still be missing the requested second source.

A run therefore needs a way to stop. Ideally, it stops because it has enough information to satisfy the goal. It may also stop because it reaches a step limit or cannot make useful progress. A limit prevents an agent from searching indefinitely; reaching it does not turn an incomplete answer into a verified one.

One final distinction connects this lesson to the last: a loop alone does not make an agent. A program that always searches three predetermined sites and then writes a summary also repeats actions and receives results. What makes the library example agent-like is that the model uses each observation to choose among permitted next actions—or to decide that it is time to answer.

Takeaways

An agent’s loop is easiest to understand as a recurring question: Given the goal and what just happened, what should I do next? The language model helps answer that question. The surrounding application performs the chosen permitted action and returns an observation. The process repeats when more information is needed and stops when the task is sufficiently complete or a boundary is reached.

Next, you will take a simple agent scenario and identify its parts explicitly: the goal, its changing state, available actions, observations, and stopping condition.