tool-calling loop

The loop is one mechanism, not the whole machine. An agent harness is the execution scaffold around a model, and its own definition lists the tool-calling loop as one component among several: the context plumbing, the sandboxing, the permissions, and the gates that decide what runs next. The loop is the piece of that scaffold which lets the model act at all. The rest of the harness decides what the model may do; the loop is what happens when it does something.

The other half of the boundary is who executes. A model does not run a tool. It emits a request to run one, the harness runs it, and the result comes back as more context. The loop is that handoff, repeated until the model stops asking for anything.

Retrieval as the worked example

Give the model the tools, not the context builds memory retrieval on this loop. Layer 4 of that system is a tool surface: tools over JSON-RPC that the model calls to read and write every layer below, among them chat_search, entity_search, memory_context, summarize_and_archive, write_memory and entity_supersede.

Ask the assistant what was decided about some project. It calls a tool, searches the turns or the entity graph, and comes back with an answer that carries its source and a timestamp, instead of scanning whatever happened to land in the injection window. The pattern holds across all of those tools: the model decides when to search, when to compress, and what to surface.

The ordering is the argument

The layer between wording and wiring draws the sharpest line yet on how that handoff gets timed, reading the same shift in give the model the tools, not the context: the harness stopped injecting the last N turns and started exposing retrieval as tools the model calls once it has read the request, a payload fixed before the question was known replaced by a decision taken after.

That sentence is about when the decision gets made: once, late instead of early. It says nothing yet about why the mechanism is a loop. The loop shows up after the first tool call returns: the model reads the result and can decide it needs something else, then call again. A single deferred decision still fires once, however well timed. A loop keeps firing until the model stops asking, which is what lets it recover from a first guess that was wrong instead of being stuck with it. A design that pre-loads context and runs the model once might have tools sitting there unused past the first pass, but it has no loop, because nothing brings the model back for another turn.