# Step 3: Tools and the loop

How the agent loop runs, what the harness controls, and when several agents are worth their cost.

Author: Murali Sid (https://linkedin.com/in/muralisid)
Source: https://www.agenticarchitectureskills.com/ladder/tools-and-the-loop
Published: 2026-08-29
Updated: 2026-10-15
Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/
Cite as: Murali Sid. Step 3: Tools and the loop. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/ladder/tools-and-the-loop

---


The agent finds the right evidence and still goes wrong. It calls the wrong tool, repeats itself or stops too early. &#x2A;*What controls how the agent acts, if the model is not the problem?** The answer is the loop around the model. An agent is not one call to a model. The model asks for something and the system fetches it. The model reads the result and decides what to do next. Everything that runs that loop is the <Term k="harness">harness</Term>. Teams often skip it on the way from "the context is fine" to "we need to train a model". The evidence says the harness is usually what was missing. This is the third step on [the intelligence ladder](/ladder).

## How the loop runs [#how-the-loop-runs]

The model is stateless. It remembers nothing between calls. Every turn, your code sends the whole conversation again. The model replies with either an answer or a request to use a tool. If it is a tool request, your code runs the tool and appends the result. This repeats until the model answers or you stop it.

Four design choices follow, and together they are harness design.

**The context grows every turn.** Each tool result is appended, so a long investigation fills the <Term k="context window">context window</Term> with old evidence. The context window is the model's working memory for one task. You must decide what to do about that, and the choice matters. **Compaction** summarises the history. It loses detail and can quietly drop what the model needed. **Reset** starts fresh with a stated goal and a short handover. It keeps lasting state in files or a record, not in the conversation. Reset is harder to build and generally more reliable. A summary of a summary degrades, while a written record does not.

**What outlives the run is memory.** A record kept only for the task is working data. Once it is kept for later runs, it becomes [memory](/memory). It then needs a named owner and must carry its source. It waits in quarantine before later runs trust it, and deletion must reach it. [Step 2](/ladder/context#what-the-agent-remembers) sets out those rules.

**Nothing stops the loop unless you stop it.** A model can call a tool that returns an unhelpful result, decide to try again, and do that forever. Real harnesses cap the number of turns and the elapsed time. Each run also has a cost cap within the <Term k="agent budget">agent budget</Term>. Harnesses check for cancellation between turns and offer a stop hook, a point where code can end the run. These are not edge cases. They are the normal path.

**Tools are an interface you design.** A tool with a vague description gets called at the wrong times. A tool that returns ten thousand tokens of JSON fills the context window the reasoning needs. Design tools for a reader with no memory of your system, because that is what the model is. Every tool call also passes the tool gateway. The gateway checks that the agent may make the call. The gateway is one of [the seven capabilities an agent platform provides](/architecture/system-view).

<GuideFigure id="agent-loop-anatomy" />

<TeachingIllustration src="/images/ladder/tools-loop-labeled-v4.webp" alt="A clockwise loop in six steps. The model decides to answer or to ask for a tool. The gateway checks whether this caller may do this now. The tool runs while the model waits. The result is added, so the context grows every turn. Caps on turns, time and cost are checked. The loop repeats or stops. In the centre: the model proposes, the harness controls." title="The harness owns the loop around the model" caption="The model proposes. The harness authorises, executes, records and decides whether another turn is allowed. Lasting state and hard stops sit outside the model because they must survive and stay enforceable." />

## The harness changes what the agent does [#the-harness-changes-what-the-agent-does]

Hold the task, the environment and the model constant. Harness choices still measurably change the beliefs that drive the agent's later decisions. This holds even where the final success rate looks the same (arXiv 2607.04528, July 2026). In retrieval-heavy work, the harness can matter more than the retrieval design itself (arXiv 2605.15184, May 2026).

Two things follow. Published comparisons of models run in different harnesses are confounded. A claim that model A beats model B may really be a claim about the harness around each. And your own agent's behaviour depends on your loop, not only on the model you licensed.

A third finding is worth carrying. When several agents fail together, the cause is usually the design, not the model. One study built a list of failure types from 150 traces of agent runs. It checked the list on more than 1,600 traces across seven frameworks. It found fourteen failure modes in three groups, and design failure is its central conclusion. A stronger model does not fix a badly designed loop.

## When several agents pay off [#when-several-agents-pay-off]

Splitting work across several agents buys breadth in parallel and keeps each agent's context separate. It costs roughly 1.4 to 20 times as much. It does not buy better reasoning per token.

One study tested 10,000 SEC filings across 25 field types. It compared five models and four ways of coordinating agents. A supervisor directing worker agents reached 0.921 F1 at 1.4 times the cost. F1 is a 0 to 1 score that balances missed answers against wrong ones. That design gave the best accuracy for its cost. A pattern where agents check and correct their own work reached 0.943 at 2.3 times the cost. A hybrid got 89 percent of the accuracy gain at 1.15 times the cost (arXiv 2603.22651, March 2026).

The threshold that follows is the only published one. &#x2A;*Several agents are justified when the accuracy you need is above about 0.92 F1.** Below that, you pay a multiplier for what a single well-built loop delivers.

## Worked example: a vegetation candidate at a utility [#worked-example-a-vegetation-candidate-at-a-utility]

<TeachingIllustration src="/figures/ladder/industrial-tools-and-the-loop.svg" mobileSrc="/figures/ladder/industrial-tools-and-the-loop-mobile.svg" title="Investigate a vegetation candidate" alt="Four boxes in order. Candidate: an image near an asset. Tool call: check the map and work orders. Observation: read the evidence and the gaps. Next step: inspect, request or stop." caption="Proposed industrial example. Evaluate against the simpler existing process before adopting it." />

A vegetation candidate arrives with a location and an observation date. The agent checks the asset map, recent inspections and existing work orders. If the image cannot show the required detail, the agent prepares a field-inspection request. It does not guess the exact clearance.

Each tool returns a bounded result with source references. The loop has a deadline, a cost limit and a stopping rule. Permission checks stay outside the model, as set out in [enforcement outside the model](/architecture/enforcement). How far the agent may act on its own is set in [the autonomy contract](/architecture/autonomy-contract). Creating a request is not the same as completing the inspection.

Begin with one agent or a fixed workflow. Add specialist agents only when they improve the result, or useful parallel work, enough to justify the coordination. See [vegetation inspection](/use-cases/vegetation-inspection).

## Where to go deeper [#where-to-go-deeper]

[The agent platform layer (R07)](/layers/r07-agent-platform) covers the harness, recovery after a crash, portability and what to build or buy. [The Agentic OS](/agentic-os) sets out the parts of an agent platform, which you buy and which you build. Its harness section covers what a platform provides here and what stays yours.

## When this step is done [#when-this-step-is-done]

**The loop is instrumented, and failures are traced to a specific cause. What remains is the model not knowing your domain.**

"Traced" is the test. If you cannot say which turn failed and why, you cannot know the model is at fault. Every option that changes the model costs more than finding out. For an inspection, a <Term k="trace">trace</Term> should show the sources consulted, the tool responses, the checks made and the confirmed action.

## Evidence and limits [#evidence-and-limits]

<EvidenceBadge status="independently-measured" /> The harness and multi-agent findings are independent published work, not ours. They are arXiv papers from 2025 and 2026. The 0.92 threshold comes from one study on one task, extracting fields from filings. Treat it as a guide and test on your own work.

## Next step [#next-step]

Decide whether the task needs a workflow, one agent or several, on [workflow, one agent, or several](/ladder/single-and-multiple-agents).

<details>
  <summary>
    Explore this topic
  </summary>

  * Harness choice changing downstream decisions: arXiv 2607.04528, July 2026.
  * Harness outweighing retrieval architecture: arXiv 2605.15184, May 2026.
  * The multi-agent cost-accuracy frontier: arXiv 2603.22651, March 2026.
  * Fourteen multi-agent failure modes in three groups (MAST): Cemri et al., arXiv 2503.13657, first posted March 2025. Title: "Why Do Multi-Agent LLM Systems Fail?"
  * What a record kept past the run becomes: [from data to memory](/architecture/data-to-memory) and [the memory-pipeline architecture](/library/architecture/memory-pipeline-architecture).
  * Depth on [the agent platform layer (R07)](/layers/r07-agent-platform).
  * Industrial scenarios on this page are proposed designs, illustrated in the [use cases](/use-cases).
</details>
