Agent Architecture: Why Layer Count Misses the Point — Google's 4-Layer Model

Introduction: The Layer Count Confusion

As an architect researching agents, the first step is to clarify the basic layering of agent architecture. However, there is no unified answer: some propose six layers, others seven, eight, or more. Dimensions vary — model, memory, planning, tools; interaction, orchestration, execution, governance; knowledge, data, security, operations. The problem is not that these are wrong, but that they may be discussing entirely different architectural levels . Model, memory, and planning describe internal agent capabilities; tools, interfaces, and MCP address system integration; security, evaluation, and observability belong to runtime governance; ERP, CRM, and databases are existing enterprise information systems. Stacking all these dimensions vertically creates "eight-layer" or "ten-layer" architectures that appear complete but actually blur architectural boundaries.

Google Cloud's Four-Layer Enterprise Agent Reference Architecture

After reviewing multiple vendor materials, the author highlights Google Cloud's enterprise-grade agent reference architecture . It avoids piling up technical components and instead defines four restrained layers:

Interaction Channel Layer

Agent Core Layer

Standardized Integration Layer

Backend Systems Layer

The following analysis is based on this four-layer model, extended with the author's enterprise architecture perspective. Google's original content and personal interpretation are distinguished where possible.

1. Interaction Channel Layer: Where Tasks Originate

This layer solves the entry point problem for agent systems. Many assume agents start only via chat windows, but in enterprise environments agents are not necessarily triggered by humans through natural language. Google's architecture includes custom frontends, chat entry points, and event triggers . Therefore, enterprise agents have at least three types of entry points:

Human-initiated tasks

System-initiated calls

Business events that proactively trigger agents

For example, a device alert can trigger an operations agent, inventory changes can trigger a procurement agent, and a customer complaint can trigger a service agent. This is why the layer is better named "Interaction Channel Layer" rather than simply "User Interface Layer."

2. Agent Core Layer: Deciding What to Do

This is where the architecture truly changes. Google places the orchestrating agent here, responsible for understanding tasks, maintaining state, and coordinating subsequent execution. Expanding further, this layer contains the agent's most core capabilities:

Intent understanding

Context management

Reasoning

Planning

Task decomposition

Memory

Tool selection

Multi-agent collaboration

Traditional applications run on pre-designed processes and rules: "If condition X occurs, execute program Y." Agents introduce a new processing mode: "First understand the goal, then decide the next step based on current context." From an enterprise architecture perspective, the core change brought by agents is not merely adding a large model interface, but the emergence of an agent core capable of dynamic decision-making and dynamic orchestration within enterprise IT.

3. Standardized Integration Layer: How Agents Invoke Enterprise Capabilities

This is a critical layer in Google's four-layer architecture. After understanding a task, an agent cannot just generate text; to enter real business it must query data, submit orders, initiate approvals, modify states, and call external services. Therefore, a stable capability interface is needed between agents and backend systems. Google emphasizes MCP Toolbox and MCP Services to wrap databases, enterprise applications, and external systems into tools that agents can understand, discover, and invoke.

The architectural idea is familiar. SOA and microservices abstracted system functions into reusable services. In the agent era, we must go further: transform enterprise services into capabilities that agents can understand, discover, and invoke. Agent architecture does not negate APIs, microservices, or enterprise service platforms; rather, it raises the bar for existing service capabilities.

4. Backend Systems Layer: Where Business Operations Actually Execute

The bottom layer remains the familiar enterprise digital systems: ERP, CRM, MES, SRM, databases, data platforms, internal applications, and various external systems. These systems still hold the true business objects, business data, and transaction states. Agents do not replace them. They change the relationship between humans and these systems:

Past: Humans operate systems.

Later: Processes call services.

Now: Agents understand goals and dynamically invoke enterprise capabilities to complete tasks.

This is the most important point for understanding enterprise agent architecture.

Conclusion: How Many Layers Should an Agent Architecture Have?

From an enterprise architecture perspective, if the goal is to answer how agents enter the enterprise, complete tasks, invoke existing capabilities, and integrate with traditional IT architecture, Google's four-layer structure provides high reference value:

Interaction Channel Layer → Agent Core Layer → Standardized Integration Layer → Backend Systems Layer.

Cross-cutting concerns such as security, identity, permissions, evaluation, observability, and agent operations are better treated as horizontal governance capabilities spanning all layers , rather than mechanically adding a fifth or sixth layer.

There is no single correct layering for agent architecture, but good layering must have clear boundaries, explicit responsibilities, and explain how agents collaborate with existing enterprise systems. Google's four-layer architecture at least offers an excellent reference.