The Anatomy of Successful Agents

The agent is the employee—not the LLM

The first misconception arises from the term itself: the LLM is not the agent. The LLM is the agent’s brain. An agent is the complete employee: the brain, the hands, and a nervous system that connects the two. Each of these components requires its own infrastructure, its own runtime environment, and its own costs.

• The brain (LLM) thinks, plans, and formulates. It’s usually not located on-premises but externally—an API call to Anthropic, OpenAI, or a self-hosted model server. Only those who run their own model need their own (usually GPU) computing power for this.
• The hands (MCP) are what the employee uses to get things done: querying a database, writing a file, calling an API. Each tool—database, CRM, file system—runs as its own MCP server, on its own infrastructure, independent of the employee themselves.
• The nervous system is the code that connects the two: the loop that translates a thought from the brain (“I need data from the customer database”) into a hand movement, returns the result, and triggers the next thought. This is not a byproduct—it is a process that actively runs as long as the employee is “awake,” and it is often the most easily overlooked cost factor.

These three parts together—brain, hands, nervous system—are the agent. No more, no less.

When the employee hits a roadblock: the phone

Sometimes one’s own hands aren’t enough. Then the employee picks up the phone and calls a colleague—perhaps in another department, perhaps at another company. This is A2A (Agent-to-Agent): One agent sends a task to another agent, who thinks and acts entirely at their own desk—their own brain, their own hands, their own nervous system. You only get the result back over the phone; you have no insight into everything the other person had to do to get there: just like when you’re on the phone, you can’t see it. 

The key difference from MCP: MCP is silent; A2A is a conversation. A tool doesn’t think for itself. Another agent does.

The Office Manager: An Agent with the Big Picture

As soon as more than one employee is involved, someone is needed to coordinate—the orchestrator. Important: The orchestrator is not part of the employee; it is a separate entity outside of it. Like a foreman or office manager, it decides which employee is assigned to which task and equips them:

• He hands them an excerpt from the phone book (the Agent Registry)—which colleagues are they allowed to call in this case?
• He provides them with the appropriate tools from the inventory (the Tool Registry)—what “hands” options are available to them for this task?

Both registries are purely reference databases—no thinking, no action, just metadata (which tools are available, which agents are reachable, with which schemas and permissions). But even reference databases must be hosted somewhere.

This brings us to at least five separate compute resources that must run simultaneously and be paid for:

1. The brain of each agent (LLM hosting)
2. Each agent’s nervous system (the orchestration loop within the agent itself)
3. The “hands” / MCP servers that are used
4. The office manager / orchestrator, who selects and equips employees
5. The registries (phone book, tool inventory) that the office manager consults

And the list isn’t even necessarily complete: Optionally, one could add an “agent memory”—that is, a long-term memory—which could be implemented technically in a wide variety of ways. But that’s precisely why it would go beyond the scope of this discussion, so I’ll leave it out for now.

None of these individual elements is “the agent.” And “choosing an agent” actually means making at least five infrastructure decisions and maintaining them over the long term.
And yes: you can also structure the capabilities differently than described here. For example, you can delegate tool selection to an agent (more autonomy) or you can choose not to let the orchestrator select the tools (less autonomy). That’s a decision for the CEO!

The top level: the CEO is a person just like you and me

One level is still missing—and it’s different from all the others because, categorically speaking, it isn’t a technique: the CEO. He is the only person in this entire picture. He determines:

• what is to be achieved in the first place (the business goal)
• which offices or “orchestrators” there are
• which employees are hired
• which tools are generally permitted—a governance and security decision
• which external companies are even permitted to be contacted

The key point: The CEO is not a computer. He doesn’t run anywhere in the system. He designs and approves the architecture but is not part of it. Every new tool approval, every new agent, every new external connection is ultimately a decision made at the top by a human—everything below that is merely the technical implementation.

Conclusion: there is no single place where “the agent runs”

Anyone who asks, “So where does it run, then?” won’t get a single answer. It’s a small distributed system made up of several components that run, scale, and fail independently: the brain, the nervous system, the hands, the office manager, the registries—plus third-party infrastructure that you don’t even control yourself.

That’s not bad news. It’s the reason why this architecture scales robustly and flexibly—each component can grow, fail, or be replaced on its own without dragging the others down with it. But it also means that “you just grab an agent” is a phrase that involves many parts, and none of them comes for free.