The general agent loop and its middleware levers

The most useful starting point for understanding an agent harness is surprisingly small: an LLM in a loop. The harness does not replace that loop. It organizes what happens around it.

1. The minimal loop

The speaker describes the general flow like this:

1. A user request enters the agent.
2. The LLM generates a response or decides that it needs to use a tool.
3. The harness invokes that tool.
4. The tool produces an observation—the result returned by the external system.
5. The harness gives the observation back to the LLM as new context.
6. The LLM takes the next step. It may call another tool, or it may return the final result.

The important point is step 5. A tool call does not automatically end the run. Its result becomes input to another model step, so the model can interpret what happened and decide what to do next.

flowchart LR
    A[User request] --> B[LLM generates]
    B -->|needs a tool| C[Harness invokes tool]
    C --> D[Observation]
    D --> B
    B -->|finished| E[Return result]

This is a general loop, not a claim that every agent behaves identically. Different harnesses can add different policies, capabilities, and checks while preserving this basic request–generation–action–observation cycle.

Click to enlarge

Source visual: The slide places the core loop beside a more detailed agent-harness flow. It visibly supports a request entering the model, an optional tool action producing an observation that returns to the model, and an eventual result.

2. Middleware surrounds the loop

Once the core loop is clear, middleware is easier to understand. Middleware is additional behavior inserted at defined points in a running process. In this talk, hooks and wrappers are ways to insert that behavior around the agent, model, and tool calls. They are not replacements for the LLM or for the loop itself.

The speaker names several useful insertion points:

• Before agent invocation: prepare or check the run before the agent starts.
• Before each model call: adjust what is about to be sent to the model.
• Around a model call: wrap the call with behavior that can act before and after it.
• After a model call: inspect or process the model's result.
• Around a tool call: control what happens before the tool runs and after it returns.
• After agent completion: handle the completed run.

These levers let a team change the behavior of a general harness locally. For example, a wrapper around a tool call can control how a large result is handled, while a hook before a model call can check or reshape the active context. The model still participates in the same loop.

Click to enlarge

Source visual: The side-by-side diagrams contrast a minimal model–tools–result loop with a broader lifecycle that adds stages and wrappers around agent, model, and tool calls. The visual supports the idea that a harness can add substantial behavior without discarding the common core.

3. The named levers in one view

The next slide makes the insertion points more concrete. It labels hooks such as before_agent and before_model, wrappers such as wrap_model_call and wrap_tool_call, and later points such as after_model and after_agent around the basic flow.

Click to enlarge

Source visual: The visible labels explicitly show before_agent, before_model, wrap_model_call, wrap_tool_call, after_model, and after_agent around the request/model/tools/result flow. They are examples of where customization can enter the lifecycle.

The exact implementation will vary by framework. The general design question stays the same: at which transition should the extra behavior run? A check that belongs before the model call is different from a wrapper that must manage a tool's output. Keeping that location explicit makes a customized harness easier to reason about.

4. Capabilities supplied by the harness

The loop is also a place where the harness supplies capabilities. The speaker mentions access to:

• a sandbox, an execution environment in which the agent can perform work;
• a file system, so the agent can read or change files;
• a sub-agent, another agent used for delegated work; and
• memory, information retained for later use.

These capabilities do not create a new core architecture. They give the agent more ways to act or more information to use at the existing tool-call and context-assembly points. A harness can therefore become much more capable while still repeatedly doing the same high-level work: call the model, act when needed, return the observation, and call the model again.

5. Managing context before it becomes a problem

One important middleware behavior is summarization. Before a model call, the harness can check whether the current context has become too long. If it has, the harness reduces that context—by summarizing it—before invoking the model.

The causal sequence matters:

1. Earlier model messages and tool observations accumulate.
2. The harness checks the size of the context before the next model call.
3. If the context is too long, the harness summarizes it.
4. The model receives the reduced context and continues the loop.

Summarization changes the representation of the accumulated conversation or work history. It does not mean that the tool itself is skipped, and it does not mean that every large output should remain fully in the active context.

6. Context offloading is different from summarization

The speaker also describes context offloading. This is a separate strategy for large tool calls. Instead of keeping all of a tool's contents in the model's active context, the harness wraps the tool call and dumps the large content elsewhere. The agent can then continue without carrying the entire result in every subsequent model input.

The distinction is useful:

Strategy	What it manages	Basic action
Summarization	Context that has accumulated before a model call	Reduce the context before invoking the model
Context offloading	A large tool result	Move or dump the tool output rather than keeping all of it active

Both strategies are harness behavior around the general loop. Summarization reduces what the model sees. Offloading changes where a large tool result is kept so that the active context does not grow unnecessarily. The source describes these capabilities at a high level; it does not specify a particular storage design or retrieval protocol for offloaded content.

Click to enlarge

Source visual: The case-study slide organizes the base deepagents harness into execution environment, delegation, steering, and context-management components. It visibly identifies context offloading as one context-management capability. The frame does not itself show the tool-call wrapper or the content-dumping sequence described in the talk.

The mental model to keep

Think of a general harness as a stable loop with configurable boundaries:

request
  -> model step
  -> optional tool call
  -> observation returned to the model
  -> next model step or final result

hooks and wrappers can run before, around, or after these steps

This model prevents two common mistakes. First, a harness is not merely a list of tools; it controls context, calls, actions, and returned observations. Second, customization does not require abandoning the general architecture. A team can begin with the common loop and add middleware, capabilities, summarization, or offloading exactly where the use case requires them.

That layered view leads to the next design question: when are these local adjustments enough, and when does a domain require a more explicit custom flow?