semiAIfoundry

Agent systems · Atlas v1.3.0

Tools, memory & agent loop

Connect model inference to actions and evidence.

Explore in AtlasLogical 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

at∼πθ(⋅∣ht),ot=Tool⁡(at),ht+1=Update⁡(ht,at,ot)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

st+1={T(st,at)V(st,at)=1stV(st,at)=0s_{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

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

Published lesson data · Atlas releases and licensing

Continue exploring

Foundations

Related lessons