Observation (Agent)

An agent that acts without looking at the result is only guessing twice. Every time it runs a search, writes a file or calls an API, something comes back — and that return value, handed to the model on its next turn, is the observation.

Where it sits in the loop
The plan–act–observe cycle closes here. The model proposes an action, the runtime executes it, and the outcome is appended to the conversation as a message the model reads before deciding what to do next. In the ReAct pattern it is an explicit labelled step — Thought, Action, Observation, then round again. What arrives is rarely tidy:

• Tool results: a JSON payload, rows from a query, the text of a file.
• Failures: a 404, a validation error, a stack trace — equally informative, and usually more.
• Environment state: a screenshot, a directory listing, the exit code of a shell command.

Why it matters
Observation is what makes an agent correctable. A single model call has to commit to its answer; a loop can discover that the file was empty, the customer id was wrong, or the test still fails, and adjust. Remove the feedback and the agent confabulates a result it never verified.

Shaping what comes back
Observations are also the main cost and risk channel. A 40,000-token API dump buries the plan it was meant to inform, so runtimes truncate it, summarise it, or write it to disk and return a handle instead. And because the text is untrusted, instructions hidden in a fetched web page arrive as an observation — the standard route for prompt injection.