The smallest agent architecture is a loop: it receives a request, the LLM (large language model) reasons, it uses a tool when needed, and the tool result is sent back to the LLM. An advanced harness does not discard this basic structure. It adds middleware, hooks, summarization, context offloading, and other behavior around it.
1. まず、一般的なループを見る
1. First, look at the general loop
Harrison Chaseは、エージェントの一般的なアーキテクチャを、LLMを中心にしたループとして説明します。ここでいう「一般的」は、すべての製品が同じ動きをするという意味ではありません。多くの異なるハーネスに共通する、最小限の考え方という意味です。
Harrison Chase describes the general architecture of an agent as a loop centered on an LLM. Here, "general" does not mean that every product behaves in exactly the same way. It means a minimal idea shared by many different harnesses.
The important point is that a tool call does not automatically end the agent run. For example, suppose the LLM calls a tool that reads a file. When the file contents return as an observation, the LLM can read them, call another tool, or answer the user. This repetition of "generate, use a tool, observe, and generate again" is the center of an agent.
図：汎用エージェントループと、より詳しいハーネスの流れを並べたスライドです。
Figure: A slide placing the general agent loop next to a more detailed harness flow.
The figure shows a request entering the model, a tool running when needed, an observation returning to the model, and a result being returned at the end. The more detailed flow on the right also places hooks around agent, model, and tool calls. It contrasts the basic loop with a harness that adds processing around it.
Even with the same basic loop, harness implementations can differ greatly. Middleware and hooks do not replace the model or the loop itself. They are places where processing can be inserted before or after the running flow. Plugins can also be understood as a way to extend the flow in this manner.
話の中で示される主な調整点は、次のとおりです。
The main customization points shown in the talk are as follows.
エージェントを呼び出す前（before_agent）
各モデル呼び出しの前（before_model）
モデル呼び出しを包む処理（wrap_model_call）
ツール呼び出しを包む処理（wrap_tool_call）
モデル処理の後（after_model）
エージェント処理の後（after_agent）
Before invoking the agent (before_agent)
Before each model call (before_model)
Processing that wraps a model call (wrap_model_call)
Processing that wraps a tool call (wrap_tool_call)
For example, a system can check the input before calling the model, record a log in a wrapper around the model call, and normalize the result in a wrapper around the tool call. These additions keep the loop from request to result while adding behavior needed for a specific use case.
図：最小のエージェントループと、より多くのライフサイクル処理を含むハーネスを比較したスライドです。
Figure: A slide comparing a minimal agent loop with a harness that includes more lifecycle processing.
This slide places a minimal loop next to a detailed lifecycle that surrounds agent, model, and tool calls. It shows that more before-and-after processing and wrappers can be added while retaining the minimal flow. The comparison presents a structure; it does not claim that every harness has the same detailed steps.
This figure explicitly places before_agent, before_model, wrap_model_call, wrap_tool_call, after_model, and after_agent around the basic request-model-tools-result flow. Customization therefore does not always mean building a separate architecture from scratch. Adding processing at the right places in an existing loop is also important customization.
The harness also supplies capabilities needed to run the loop. The examples in the talk include a sandbox, a file system, sub-agents, and memory access. Here, a sandbox is the execution environment where the agent works. A sub-agent is a mechanism for assigning part of the work to another agent. Memory handles information that can be used in later runs.
For example, for an agent that works with code, the harness gives it a work environment and access to files. The agent can read and edit files with tools, observe the results, and decide what to do next. Even when part of a research task is assigned to a sub-agent, the central loop of "generate, use a tool, observe, and continue" remains the same.
As a loop continues, the conversation and tool results grow. The system therefore checks whether the context is too long before calling the model. If it is too long, the system summarizes the necessary content and then calls the model. The purpose of summarization is to reduce the information needed for the current model call to a manageable size.
Summarization and context offloading are similar, but they are not the same. Summarization makes an already long context shorter before the call. Offloading, in contrast, wraps a large tool call and writes its contents outside the active context instead of keeping all of them there. In other words, the first method compresses information, while the second moves large content outside the current context.
This case-study slide divides the base deepagents harness into execution environment, delegation, steering, and context management. Context offloading appears under context management. However, the image itself does not show the specific procedure of wrapping a tool call and writing its contents out. Understand that procedure as part of the talk's explanation.
The main point of this chapter is not to set the general loop against advanced harnesses. A harness can keep the core of request, generation, tool call, observation, and another generation while adding processing with hooks and middleware. It can provide an execution environment, files, sub-agents, and memory as the use case requires, and manage long contexts through summarization or offloading. In this way, a team can start with a common loop and add only the needed control step by step.
The transcript in this section contains duplicated fragments and false starts around the transition. One product name sounds like "Quad Code" in a fragment, but its exact spelling is uncertain. This chapter does not extend that name into a technical claim and stays with the parts about the loop and its customization points that are supported by the plan.