Agent、Agent Runtime、Agent Platformの違いを、「作業者」「仕事場」「会社」という例えで整理してみたThis article clarifies the often-confused distinctions between Agent, Agent…

As teams rush to build software around large language models, one of the most common sources of confusion is terminology: the words Agent, Agent Runtime, and Agent Platform are often used interchangeably, even though they describe distinct layers of a system. This article proposes a simple mental model that maps those three concepts onto a familiar workplace hierarchy, where an Agent is a worker, an Agent Runtime is the workplace, and an Agent Platform is the company. Getting these boundaries right matters because muddled definitions tend to produce muddled architectures, with responsibilities leaking across layers that should be cleanly separated.

The Agent, in this framing, is the individual worker. It is the unit that reasons about a goal, decides what to do next, and takes action, typically by combining a language model with a prompt, a set of tools, and some memory of the task at hand. A worker has skills and judgment, but on its own it has no desk, no building, and no colleagues. In the same way, an Agent is essentially a loop of planning and acting that needs something around it to actually function. Defining the Agent narrowly, as the decision-making logic rather than the entire application, helps keep the concept portable and testable.

The Agent Runtime is the workplace that surrounds the worker. It provides the desk, the tools, the network connection, and the rules that govern how work gets done. Concretely, a runtime handles execution concerns: invoking the model, managing the tool-calling loop, enforcing timeouts and retries, persisting state, streaming output, and isolating one task from another. Just as a worker cannot be productive without a functioning office, an Agent cannot operate without a runtime to host its execution. This layer is where reliability, observability, and security controls naturally live, because it is the point through which every action passes.

The Agent Platform is the company that contains many workplaces and many workers. It is concerned with the broader organization: provisioning and deploying agents, managing identities and permissions, routing requests, tracking cost and usage, storing shared knowledge, and coordinating multiple agents that may need to collaborate or hand off tasks. A company sets policy, handles hiring and onboarding, and provides shared infrastructure that no single office would build alone. Similarly, an Agent Platform offers the governance, orchestration, and lifecycle management that let an organization run agents at scale rather than as one-off scripts.

This layered view aligns with an emerging industry pattern, and the Model Context Protocol (MCP) is a useful reference point for understanding it. MCP, introduced by Anthropic, is an open standard that defines how an agent connects to external tools and data sources through MCP servers. In the workplace analogy, MCP servers resemble the standardized equipment and supply contracts that any office can plug into, which means the tools an Agent uses can be developed and maintained independently of the Agent itself. The runtime is what actually establishes those connections and mediates the calls, while the platform decides which servers are approved and who is allowed to use them.

Several adjacent tools illustrate where each layer tends to sit in practice. Frameworks such as LangChain, LlamaIndex, and the OpenAI Agents SDK largely operate at the Agent and runtime levels, giving developers primitives for reasoning loops and tool integration. Managed offerings and orchestration systems, including those that add multi-agent coordination, deployment, and monitoring, lean toward the platform role. The boundaries are not always crisp, and many products span more than one layer, so the analogy is best treated as a reasoning aid rather than a strict specification.

The practical payoff of this separation appears when systems grow. When the Agent is decoupled from its runtime, the same reasoning logic can run in different environments, from a local test harness to a production service. When the runtime is decoupled from the platform, teams can swap execution backends without rewriting governance and orchestration. Conversely, collapsing these layers often leads to designs that are hard to secure, scale, or debug. While no single vocabulary has been universally adopted across the industry yet, thinking in terms of worker, workplace, and company gives developers a shared language for deciding where a given responsibility belongs, which is likely to become more valuable as agent architectures mature.