From Answer to Action: Why One Call Isn't Enough

A model can produce a convincing plan for changing a codebase in one response. At that point, no file has necessarily been searched, no edit has necessarily been applied, and no test has necessarily run.

The answer may be useful. It is still an answer, not evidence that the task happened.

Closing that gap requires machinery outside the model invocation: software must perform external operations, capture what happened, supply those observations to a later call, and decide whether the work should continue. That surrounding system is the beginning of an agent loop.

The ceiling of one call

A model call begins with a bounded request: instructions, current messages, available tool descriptions, and any other context assembled for that invocation. The model generates an output from what the call makes available.

One call can do substantial work when the requested result is itself an answer and the needed evidence is already present. It can explain a linter, summarize pasted release notes, classify supplied records, or propose an implementation from included code.

The boundary appears when the task depends on external reality that is not already in the request. A call cannot, by generation alone:

• discover which files currently exist in a repository;
• change those files;
• run a test process;
• observe whether the process passed;
• inspect a website whose current contents were not supplied;
• confirm that an external side effect completed.

The model can generate language or structured data proposing any of those operations. An application, provider runtime, or other external program still has to perform them.

That distinction is easy to miss because products often present the whole system under one name. In this chapter, model behavior means generating a candidate next output from supplied context. Agent or application behavior includes assembling state, dispatching tools, enforcing policy, and deciding what happens after the output arrives.

A plan is not an observation

Suppose the task is:

Update the config loader and make sure the tests pass.

With no repository contents or test output in its request, one call can infer a plausible sequence:

1. Find the config loader.
2. Inspect its callers.
3. Edit the implementation.
4. Run the relevant tests.
5. Fix any failures.

The sequence sounds like progress because it names the right actions. But every item is still prospective. The call has not learned which loader the repository uses, whether the proposed edit fits the code, or what the tests report.

To turn that plan into controlled work, the system needs a causal chain:

1. The application assembles the task and current state for a model call.
2. The model proposes a next step, such as searching for a symbol.
3. External code performs the approved search.
4. The application captures the search result.
5. That result is included in a later model call.
6. The next output can now depend on observed files rather than a guess.
7. The application repeats or stops according to its policy.

The observation is load-bearing. If the search returns two paths but neither path enters the next call, the next model invocation cannot use that result. The tool ran; the useful evidence still failed to cross the boundary.

Stateless calls create the need for reinjection

Conversation continuity is commonly constructed outside the model by replaying messages, restoring a conversation object, or loading framework-managed session state. Agent continuity follows the same principle.

After each operation, the orchestrating application or platform must retain the task state that matters and make relevant pieces available again. That state might include file contents, command output, a patch, an error, approvals, a remaining budget, or a record of attempted steps.

This act of putting an observation into a later call is reinjection. It creates the next link in the chain:

external result -> next request context -> next model output

Reinjection does not make the model permanently remember the result. It makes the result available for one later invocation, subject to the context that the application actually assembles.

What turns repeated calls into controlled work

Calling a model several times is not enough by itself. A useful loop needs responsibilities around those calls:

Responsibility	Why it is needed
State assembly	Select the task, instructions, prior observations, and available operations for the next call.
External execution	Perform searches, reads, commands, edits, API calls, or other real operations.
Observation capture	Represent successes, failures, partial results, and errors so later decisions can use them.
Reinjection	Put relevant observations into a later request.
Continuation policy	Decide whether to call the model again, ask the user, retry, or stop.
Safety and budget policy	Reject disallowed actions and bound time, cost, retries, and side effects.

These are application or runtime capabilities. The model can influence the path by proposing actions, interpreting results, and generating a final response. It does not therefore own every action or policy decision in the system.

The word agent is used differently across products and research. Some systems follow fixed workflows; others let model outputs choose more of the next path. Some applications execute client-side tools, while providers may execute hosted tools on their own infrastructure. Those differences change where orchestration runs, not the basic need to connect proposals, execution, observations, and continuation.

When one call is enough

An agent loop adds latency, cost, state management, and new failure modes. It should not be the automatic answer to every prompt.

Task	Usually one call or a loop?	Reason
Explain what a linter does.	One call can answer.	The requested product is an explanation; no current external state is required.
Summarize release notes pasted into the request.	One call can answer.	The source material is already present, assuming no outside verification is required.
Find and fix every failing lint rule in a repository.	Needs a loop.	The system must inspect files, run the linter, change code, and observe new results.
Fetch the latest release notes and verify that their examples compile.	Needs a loop.	The task requires current retrieval, local execution, observation, and a completion decision.

“One call can answer” does not mean the answer is guaranteed correct. It means the task does not inherently require the system to act on and repeatedly observe an external environment.

A loop is necessary, not sufficient

Adding a loop does not guarantee correctness, safety, or completion. The system can expose the wrong tool, pass stale state, misread a result, repeat a failed action, or stop too early. It can also continue forever if no policy bounds retries or detects a lack of progress.

Those failures should be attributed to the layer that controls them. A malformed tool request may originate in model output. Executing a destructive request without approval is an application-policy failure. A command timeout belongs to the tool or runtime. Omitting the timeout from the next context is a state-assembly failure.

“An agent is a new kind of model that can take action.”

An agent system may use the same kind of stateless model call as a chat application. The new capability comes from composition: external state, executable tools, repeated calls, and host-side control connect generated proposals to observed consequences.

The first missing link between answer and action is tool calling. It begins not with the model reaching into the world, but with the model emitting a structured proposal that other software may choose to execute.