# Tools, memory & agent loop

Canonical: https://semiaifoundry.com/learn/atlas/tool-loop/
Revision: 2026-10-07
Rights: https://semiaifoundry.com/ai-atlas/licenses.html

Agent systems · Atlas v1.3.0

# Tools, memory & agent loop

Connect model inference to actions and evidence.

[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#tool-loop)Logical structure · mapped onto physical hardware

Learning objectiveTrack which state changes in a tool-assisted inference loop and account for its sequential latency.

## The mechanism

A model can propose a structured tool call, but a surrounding runtime must validate it, execute the tool, and return the result. The next model invocation can use that observation. Search, code execution, file operations, and external memory are therefore parts of a larger system around the neural network. Permissions, state tracking, error handling, and verification determine what the system can do reliably. A retrieved document and a model parameter are different kinds of memory.

An observable tool loop needs a contract for effects as well as returned text. The durable incident experience now executes proposals through schema validation, authority, exact human review, service and receipt recording. Its fixed workflow and bounded branching policy are authored code. Their visible decisions demonstrate runtime boundaries without claiming a language model generated them. A future real-model adapter must identify its model/configuration and preserve the same runtime checks.

A model policy can propose a structured action, but a separate environment contract determines whether it is valid and authorized. The tool response becomes an observation, not an instruction with authority over the system. A plausible final sentence does not establish that the requested state transition occurred. The connected automation experience supplies bounded actions and verifiable outcomes; the lifecycle decoder itself generates symbols and does not call external tools or receive extra training from a tool response.

1.  Interpret the task and generate a response or proposed action.
2.  Execute an allowed tool through the runtime and capture its result.
3.  Use observations to revise the plan, continue, or finish.
4.  A proposed call remains separate from permission and the external effect; the caller observes the returned result or explicit uncertainty.
5.  After a write commits but its response is lost, a receipt or idempotent retry resolves the original action before another dependent action starts.
6.  Log the policy input and proposed structured action.
7.  Validate schema, capability, preconditions and budget before any state mutation.
8.  Record the actual observation and independently score the desired state change.

## Science and assumptions

### A closed loop changes context and the environment

$$
a_t\sim\pi_\theta(\cdot\mid h_t),\qquad o_t=\operatorname{Tool}(a_t),\qquad h_{t+1}=\operatorname{Update}(h_t,a_t,o_t)
$$

Sample an action from the policy given current history, execute the permitted tool to obtain an observation, then update history with the action and observation.

These are typed state-transition relations, not physical scalar equations. Tool failures, permissions and asynchronous execution remain runtime conditions.

Symbols and units

aₜ

Proposed action sampled from the policy

action object

π\_θ

Policy conditional on supplied history

probability distribution

θ

Fixed inference-time trained parameters

model coordinates

hₜ

Supplied history or context at step t

structured state

oₜ

Returned tool observation

observation object

Tool

Allowed tool execution in this sequential abstraction

action → observation

Update

Context update operation

state/action/observation → state

t

Interaction-step index

integer index

The model conditions an action proposal a on available history h. A runtime executes an allowed tool and returns an observation o. The next invocation receives updated context and can change its next action. This creates feedback with the world while ordinary inference keeps the trained parameters θ fixed.

Assumptions This is a schematic sequential loop, not a hidden implementation. Tools may fail, be asynchronous, or change external state; the runtime enforces permissions and can decline actions. Context management may summarize rather than retain all history.

### A model policy with validated observations and actions · worked relation

$$
s_{t+1}=\begin{cases}T(s_t,a_t)&V(s_t,a_t)=1\\s_t&V(s_t,a_t)=0\end{cases}
$$

Distinguish a proposed model action, validated execution and an observed successful outcome.

Symbols and units

s\_t

Environment state before validation

state

a\_t

Proposed action with identity

record

V

Schema capability and precondition validator

Boolean

T

Authorized transition including idempotency semantics

function

In an authored inventory environment, stock starts at 3. A proposed reserve(2) passes a bound of available stock and commits stock=1. Retrying the same committed action with the same idempotency key returns its prior receipt rather than subtracting again. A fresh reserve(2) fails because only one remains. Saying “reserved” after that rejection is an answer failure even if its JSON syntax is valid.

Assumptions Authored finite inventory contract, not an actual external order. Model generation, validator execution and learning updates have separate state boundaries.

## Engineering example

Synthetic loop: first model call takes 0.8 s, a permitted tool takes 0.3 s, and the follow-up model call takes 0.7 s. With sequential execution, elapsed time is 1.8 s before overhead. Tool output changes the next call’s context; it does not by itself update the model’s learned weights.

In the commit-timeout case, reserving two FILTER-A units leaves two of the original four units before the caller has any successful response. The fixed workflow retries the same keyed action; the authored policy looks up the receipt. Both can finish with one reservation and one work order. Neither can infer that the timeout meant no effect occurred.

In an authored inventory environment, stock starts at 3. A proposed reserve(2) passes a bound of available stock and commits stock=1. Retrying the same committed action with the same idempotency key returns its prior receipt rather than subtracting again. A fresh reserve(2) fails because only one remains. Saying “reserved” after that rejection is an answer failure even if its JSON syntax is valid.

## Distinctions and tradeoffs

Tool access is a system capability, not a new physical neuron inside the model.

More tools expand reach while increasing dependencies and failure modes. Useful autonomy requires measurable completion and recovery behavior.

Advanced assistants combine learned inference with software and infrastructure.

## Specifications and interfaces

Boundary

Model ↔ runtime ↔ environment

Tools execute outside the weight matrices.

Persistence

Application dependent

External memory differs from a context window.

### Interfaces

User and observations Input

Context plus task state

Runtime Output

Structured calls or final response

## Check your understanding

### What actually executes a model-proposed tool call?

1.  A surrounding runtime or application
2.  The embedding table itself
3.  A silicon atom

Answer and reasoning

A surrounding runtime or application

The model emits a proposal; software carries out the operation and returns observations.

### What does a lost tool response establish about whether the write committed?

1.  It establishes no effect
2.  It leaves the outcome uncertain until checked
3.  It automatically authorizes a second logical write

Answer and reasoning

It leaves the outcome uncertain until checked

Transport failure does not determine external state; check the original keyed effect.

### What establishes successful reservation after a tool call?

1.  A fluent sentence saying the reservation succeeded.
2.  The presence of a syntactically valid action proposal alone.
3.  A validated committed receipt and the corresponding environment state.

Answer and reasoning

A validated committed receipt and the corresponding environment state.

A validated committed receipt and the corresponding environment state. Authored finite inventory contract, not an actual external order. Model generation, validator execution and learning updates have separate state boundaries.

## Historical context

### 2022 · ReAct interleaves language-model reasoning and actions

Yao and colleagues explored alternating reasoning and actions that gather observations from external environments. The preprint appeared in 2022 and the conference version at ICLR 2023.

[Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)

## Evidence and scope

The model–action–observation pattern follows the linked Toolformer/ReAct context. Times are synthetic; parallel tools, failure, retries and context management alter timing. The runtime validates permissions and results rather than treating a proposal as completed work.

The executable extension is a fictional local environment with two authored policies. It adds no claim of real LLM agency, MCP conformance or production durability. Model parameters, invocation context and the workflow journal remain separate objects.

Mode: worked example. Authored finite inventory contract, not an actual external order. Model generation, validator execution and learning updates have separate state boundaries. Numerical examples are authored calculations, except explicitly identified automated core fixtures. Primary sources support the scoped mechanism; no human specialist review or learner outcome is implied.

Use the execution investigation for the shared tensor-to-memory-to-result thread; no current standalone calculator models this lesson’s full mechanism.

## Sources

-   [Schick et al. — Toolformer](https://arxiv.org/abs/2302.04761)
-   [Yao et al. — ReAct](https://arxiv.org/abs/2210.03629)
-   [Temporal Activities](https://docs.temporal.io/activities)
-   [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
-   [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/html/2210.03629v3)

[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/tool-loop-50255241730ddbf9.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)

## Continue exploring

### Foundations

-   [Output head & decoding](https://semiaifoundry.com/learn/atlas/output-head/)
-   [Inference serving and request scheduling](https://semiaifoundry.com/learn/atlas/serving/)

### Related lessons

-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)
-   [Post-training & feedback](https://semiaifoundry.com/learn/atlas/post-training/)
-   [GPT-6 Astra](https://semiaifoundry.com/learn/atlas/astra/)
-   [Durable actions and the ambiguous timeout](https://semiaifoundry.com/learn/atlas/durable-actions-idempotency/)
-   [Tool schemas and semantic validation](https://semiaifoundry.com/learn/atlas/tool-contracts-schemas/)
-   [Human review, interruption and cancellation](https://semiaifoundry.com/learn/atlas/human-review-cancellation/)
-   [Confidence, errors and refusal to guess](https://semiaifoundry.com/learn/atlas/probability-calibration-abstention/)
-   [Human and model judgments under a rubric](https://semiaifoundry.com/learn/atlas/judge-rubric-agreement/)
-   [From lexical retrieval to model answers with evidence](https://semiaifoundry.com/learn/atlas/retrieval-supported-generation/)
-   [Sampling more candidates versus selecting correct ones](https://semiaifoundry.com/learn/atlas/test-time-search-verification/)
-   [Version the entire evaluated system](https://semiaifoundry.com/learn/atlas/model-system-regression-contract/)