AIエージェントを理解したい人に捧げる地図 — ツール名でなく層(Layer)で理解するReference ArchitectureThis article introduces a reference architecture for AI agents organized by…

The proliferation of AI agent tools has outpaced most people's ability to keep track of them, and a new blog series published on Zenn sets out to impose order. Rather than cataloguing the field by product or vendor names, the series proposes a reference architecture that organizes AI agents by functional layers. The reasoning is that tool names shift constantly and overlap in confusing ways, while the layers beneath them—what each part of a system is responsible for—stay comparatively stable and are easier to reason about over time.

This piece is the parent article of a multi-part series, setting out the overall map before later installments examine individual layers in depth. Its core proposition is that anyone hoping to understand the big picture of AI agents is better served by thinking in terms of structure: which layer presents a product to users, which layer controls execution, which layer handles memory, and how those responsibilities connect. Framing the discussion this way is intended to give readers a mental model that outlasts the rapid turnover of the current market.

One layer covers what the series calls the Agent Product. The corresponding installment organizes 33 products into a "chaos map" plotted on two axes: degree of autonomy and delivery format—that is, how independently a product operates and how it is packaged and offered to users. Two-dimensional maps of this kind are a familiar way to make a crowded market legible, letting readers place each offering relative to its peers rather than memorizing a long list.

A separate layer addresses the Execution Engine, described as the execution-control layer for the agent">multi-agent era and likewise organized as a chaos map. In agent systems, this is the part responsible for orchestrating steps, coordinating multiple agents, and managing how tasks actually run. As deployments move from single assistants toward multiple cooperating agents, execution control becomes a more prominent concern, which appears to be why the series treats it as its own layer rather than folding it into the product discussion.

Memory forms another layer. The relevant article distinguishes between built-in memory, external memory, and what it labels a new "dreaming" layer. Built-in and external memory correspond to the familiar split between state a model or agent retains directly and information stored in outside systems such as vector databases or other retrieval stores. The "dreaming" concept appears to describe a newer, more experimental approach to how agents consolidate or generate information, though the parent article positions it as an emerging idea rather than a settled category.

The series also touches on infrastructure-level constraints, including a note that Ollama is weak at parallelism. Ollama is a widely used tool for running large language models locally, and limitations around parallel execution are the sort of practical detail that matters when an execution engine needs to drive many agent calls at once. Observations like this underline the broader point of the architecture: performance and behavior depend not only on which product sits at the top but on the characteristics of each underlying layer.

For readers new to the space, it helps to recall that an AI agent generally combines a large language model with tools, a planning or control loop, and some form of memory, so that it can take multi-step actions rather than simply answer a single prompt. The layered view aligns with how orchestration frameworks and copilots in the wider industry are increasingly structured, separating model, control, memory, and interface concerns. By naming these layers explicitly and comparing tools within each, the series aims to function as a map—one that stays useful even as the specific products occupying each layer continue to change.