Trace the reason–act–observe loop

Learning objective

Trace a reason–act–observe loop from a request to a bounded outcome, including its stopping and failure conditions. This lesson explains the control cycle, not the implementation details of a particular agent framework.

Core idea

An agent does not turn every request directly into a final answer. It can repeat three logical stages:

1. Reason: interpret the current goal and available evidence, then choose the next step.
2. Act: produce an answer or request a tool operation.
3. Observe: incorporate the tool’s result or error into the next decision.

The observation closes the loop. A tool call without its result gives the model no new evidence, and a result that is not correlated with the call can update the wrong plan. A production design therefore traces the cycle as structured events and places deterministic limits around it.

How it works

Start with an explicit state that contains the goal, permitted actions, evidence, remaining budget, and status. Each iteration transforms that state:

goal + state -> decision -> action -> observation -> updated state

The decision normally has one of three forms:

• return a final result because the success condition is satisfied;
• request a permitted action with structured arguments;
• stop because progress is unsafe, impossible, or outside the remaining budget.

If the decision requests a tool, the controller validates its name and arguments, checks policy, executes it, and records the result. The next model call receives that observation. In the Model Context Protocol (MCP), a tool result can contain structured or unstructured content and can mark an execution failure with isError; see the MCP tools specification. The controller must preserve that status instead of presenting an error string as successful evidence.

Tracing should capture at least the iteration number, decision, tool call ID, validated arguments, start and end time, result status, state change, and stop reason. Do not log secrets or unrestricted sensitive payloads. The trace is an execution record; it is not a requirement to expose the model’s private internal reasoning.

Define terminal states before running the loop:

• Succeeded: a verifiable completion condition is true.
• Needs input: a required fact or authorization can come only from the user.
• Denied: policy rejects the requested action.
• Failed: an unrecoverable error prevents completion.
• Exhausted: a turn, time, call, or cost limit is reached.
• Cancelled: the caller or operator stops the run.

Every requested action passes through the controller before its observation closes the loop.

Retries belong inside these bounds. Classify a failure before retrying it. A timeout or rate limit may be transient; invalid arguments may be repairable; a permission denial or non-existent resource is usually not repaired by repeating the same call. Apply a retry limit and backoff where appropriate, and preserve idempotency for actions that might be submitted twice.

Workflow frameworks expose the same control ideas in different forms. For example, ADK’s Loop agents support a maximum iteration count and an escalation signal to end a loop. These are controller mechanisms, not requests that depend only on a model deciding to obey a prompt.

Key distinctions and trade-offs

Observation versus state: An observation is the new fact returned by an action. State is the accumulated information used for later decisions. A raw observation may need validation and normalization before it updates state.

Tool error versus agent failure: A tool can fail while the turn succeeds by using a fallback or reporting a bounded partial result. The agent fails only when the goal cannot reach an accepted terminal outcome.

Progress versus activity: Repeated calls are not proof of progress. Track a progress measure such as unresolved items, newly acquired evidence, or completed workflow states. Stop when repeated observations do not change it.

More iterations may solve harder tasks, but they increase latency, cost, and the number of opportunities for unsafe side effects. Use the smallest bound that supports measured task success.

Architecture / decision scenario

An incident assistant must identify a failing service and open a ticket. It first queries recent alerts. The result identifies three candidate services, so the agent requests logs for the highest-confidence candidate. The log tool times out.

The controller records a transient failure and permits one retry. The second call succeeds and provides an error signature. The agent proposes a ticket, but the controller checks the completion rule: a ticket ID must exist. It calls the ticket tool with an idempotency key, observes the returned ID, and stops as Succeeded.

If the second log call also timed out, the loop would stop as Exhausted and return the known alert evidence. It would not keep alternating between planning and the unavailable tool.

Common exam traps

• Treating a tool request as proof that the action happened. Only the correlated observation confirms execution.
• Letting the model be the sole enforcer of iteration, time, or cost limits.
• Retrying every error. Permanent, policy, and invalid-input failures need a different transition.
• Marking a run successful because the model produced fluent text rather than because a completion condition is true.
• Recording private reasoning when structured decisions, calls, observations, and state transitions provide the needed traceability.
• Forgetting idempotency when an action’s result may be lost after its side effect completes.

What to remember

• The observation closes each reason–act–observe iteration.
• Validate actions before execution and results before they update state.
• Define success, pause, denial, failure, exhaustion, and cancellation states.
• Bound retries and total iterations with deterministic controller logic.
• Measure progress, not the number of actions taken.

Knowledge check

References

• Google Agent Development Kit, Runtime
• Google Agent Development Kit, Loop agents
• Model Context Protocol, Tools specification
• Google Cloud, Retry strategy