Table of Contents

Beyond the Label: Why Simple AI Agent Classifications Fail

The current grouping of open-source AI agents under monolithic labels, such as ‘coding agent,’ fundamentally obscures critical architectural distinctions necessary for scalable development and robust governance. This simplification is an abstraction that ignores the functional separation between the foundational mechanics of an agent system and the developer-facing orchestration layers.

The Problem of Monolithic Labeling

Grouping diverse tools like OpenCode, Pi, and Goose under a single umbrella hides the specific roles and responsibilities of each component. This monolithic labeling prevents engineers and governance bodies from understanding where security boundaries are defined, where state is managed, and where developer labor is focused.

The distinction is not arbitrary; it defines the system’s operational reality:

  • OpenCode: Positioned as a coding-first software-development agent. Its scope is narrowly focused on tasks inside repositories, including exploring codebases, planning changes, editing files, and implementing features.
  • Pi: Functions as the agent kernel, harness, or toolkit. It is the foundational layer responsible for agent runtime design, tool calling, state management, and provider abstraction. Its utility is understanding how agents are built and the underlying mechanics.
  • Goose: Functions as the local AI agent workbench and orchestration surface. It is designed to be a local system integrating models, tools, files, terminal workflows, and extensions, extending naturally beyond coding to encompass research, writing, automation, and data analysis.

Defining the Necessity of Layer Separation

Agent systems must be architected as distinct layers to ensure predictability, security, and focused development. This layered approach dictates specific boundaries for usability, security, and developer focus.

We define three essential layers:

  1. Kernel/Harness Layer (Pi): This layer establishes the core agent runtime. It manages the internal mechanics of model calls, tool calls, state, and provider abstraction. As analyzed in the context of the agent harness, this layer is the engine that dictates reproducible workflows.
  2. Workbench Layer (Goose): This layer provides the orchestration surface for the developer. It integrates the agent runtime with desktop/CLI interfaces, allowing for MCP-style extension workflows and local developer workflows that are not limited to code.
  3. Application Layer (OpenCode): This layer is the end-user-facing agent, specialized for a specific task (e.g., software development).

The Impact of Architectural Distinction

Layer separation is critical because it directly impacts three key areas:

  • Security Boundaries: The architectural statement of the agent harness (Pi) explicitly states that security boundaries (filesystem, network access) belong to the environment surrounding it. This means that true security requires external mechanisms, such as containerization or sandboxing, rather than relying on the agent itself to manage permissions.
  • Usability and Focus: By separating the low-level runtime (Pi) from the high-level orchestration (Goose), developers can focus on optimizing the agent’s mechanics without being burdened by the friction of the desktop interface. This shifts the focus from execution to system design and orchestration.
  • Governance: Granular distinctions allow for the development of effective regulatory frameworks. Policy frameworks must be built around the agent harness and the orchestration surface, rather than treating the end-user application as a monolithic entity. This architectural clarity is the prerequisite for managing AI risk and control.

The Agent Kernel: Infrastructure, Runtime, and Economic Implications

The foundational architecture of AI agents depends on establishing clear separation between the core execution mechanism and the user-facing orchestration layer. This distinction is embodied by the concept of the Agent Kernel, which governs the agent’s runtime and tool-calling capabilities.

Agent Harnesses and Runtime Design

The Agent Harness, exemplified by projects like Pi, serves as the critical layer defining the agent system’s operational mechanics. Pi is positioned as an agent kernel or toolkit, focusing on the low-level design of how an agent system functions rather than just providing a finished assistant.

Key architectural components within the Agent Harness dictate system reliability and scalability:

  • Agent Runtime: The runtime design is crucial for reproducibility. Pi includes a runtime layer that manages state management and tool calling. This design directly impacts the scalability and reproducibility of complex AI operations by defining how agent states transition and how external tools are invoked.
  • Provider Abstraction: The architecture must handle unified multi-provider LLM APIs. This abstraction layer is essential for decoupling the agent logic from specific model implementations, allowing for flexible system extensions and easier swapping of underlying models or tool providers.
  • Layer Distinction: The separation matters because it dictates development focus. Pi’s purpose is to facilitate understanding how agents are built, allowing developers to experiment with agent runtime design, provider abstraction, and workflow control. This contrasts with the orchestration surface (e.g., Goose), which focuses on the developer-facing workbench and workflow management.

Hardware, Energy, and Economic Load

Running complex agent systems imposes significant resource demands, which translate directly into substantial economic implications. The investment in AI infrastructure is massive, with estimates reaching $1,450 billion, primarily driven by the need to control specialized chips required for high-performance model training.

The economic cost is determined by two factors:

  1. Specialized Hardware: High-performance training and execution require specialized chips that dictate the supply chain and control the economics of agent system deployment.
  2. Runtime Overhead: The runtime design directly affects operational costs. Designing efficient state management and tool-calling mechanisms is necessary to mitigate the overhead associated with maintaining complex agent states and executing tool calls repeatedly.

Security Boundaries and Sandboxing

A critical architectural implication of the Agent Kernel is the handling of security boundaries. The Agent Harness itself must be architected to delegate security responsibility to the surrounding environment.

  • Permission Models: The Agent Harness (Pi) explicitly states it does not include a built-in permission system for restricting filesystem, network access, or credential access.
  • Sandboxing Necessity: To ensure secure execution of agent tools and minimize risk, developers must implement external mechanisms, such as containerization and sandboxing, around the agent harness. This architectural decision establishes that security boundaries belong to the environment surrounding the agent, not the agent itself.
  • Governance: These granular architectural distinctions inform the development of effective regulatory frameworks. Understanding where the execution state resides—in the kernel, the runtime, or the orchestration surface—is necessary for managing AI risk and control.

The Workbench Layer: Transforming Developer Workflows and Labor

The separation of AI agent systems into distinct layers—from the kernel to the workbench—is critical because it dictates the scope of development, security boundaries, and the nature of the labor required from developers. Grouping disparate systems under a single label, such as “AI coding agent,” obscures these architectural distinctions and prevents effective scaling and governance.

Orchestration Surface vs. Agent Harness

The distinction between the Agent Harness (e.g., Pi) and the Orchestration Surface (e.g., Goose) defines the functional focus.

  • Agent Harness (Pi): This layer focuses on the foundational mechanics of the agent system. It provides the core infrastructure for execution, including agent runtime design, provider abstraction, tool calling, state management, and reproducible workflows. Its purpose is to allow developers to understand how agents are built, enabling experimentation with the structure of agent systems rather than just consuming a finished assistant.
  • Orchestration Surface (Goose): This layer functions as the local AI agent workbench and the primary orchestration surface for developers. It aggregates the foundational capabilities of the harness with external tools, files, terminal workflows, APIs, and extensions. Goose is designed to be a holistic local system where models, tools, files, terminal workflows, and extensions are brought together, positioning it as a system for research, writing, automation, data analysis, and local developer workflows, extending far beyond narrow coding tasks.

Shifting the Nature of Labor

The introduction of the workbench layer fundamentally shifts the role of the software developer from execution to system design and orchestration.

  1. From Execution to System Design: Developers move away from writing explicit execution logic and instead focus on defining the system architecture: defining the agent’s runtime, managing provider abstraction, and designing reproducible workflows.
  2. Focus on Orchestration: The developer’s primary task becomes orchestrating complex, multi-agent systems and managing the interaction between tools, models, and external environments, rather than merely executing a single prompt.
  3. New Specialized Roles: This architectural shift necessitates a change in job requirements. Specialized roles must evolve to manage and build complex, multi-agent systems, requiring expertise not only in model interaction but also in agent system infrastructure, runtime design, and robust security boundaries.

Architectural Implications for Security

The layer separation is essential for establishing clear security boundaries. The agent harness itself (like Pi) is designed to operate with the permissions of the launching user and process. This architectural statement dictates that security boundaries (filesystem, network access, credentials) must reside in the environment surrounding the agent harness, rather than being embedded within the agent itself. This principle mandates the use of containerization and sandboxing to enforce secure execution of agent tools and minimize potential security risks.

Governance and Security: Architecting Boundaries for AI Agents

The failure to apply consistent security boundaries across disparate AI agent systems stems from treating the agent as a monolithic entity rather than recognizing the distinct architectural layers. Effective governance requires anchoring security policies to the system’s execution environment, not the agent’s internal logic.

Permission Models and Architectural Separation

The core architectural statement regarding security is that security boundaries—specifically access to the filesystem, network, processes, and credentials—must reside in the environment surrounding the agent harness, not within the agent itself. This principle is most evident in the distinction between foundational components, such as the agent kernel and the agent workbench.

For example, the Pi agent harness functions primarily as the agent runtime and toolkit. Due to its design as a low-level foundation for building and extending agent systems, Pi explicitly omits a built-in permission system for restricting access to external resources. By default, Pi runs with the permissions granted to the user and the launching process. This architectural choice establishes a clear permission model: the agent harness is a mechanism, and the security boundary is dictated by the surrounding execution environment.

Sandboxing Requirements for Secure Execution

Because the agent runtime itself does not inherently enforce system-level security, secure execution of agent tools necessitates external mechanisms. This mandates the requirement for containerization and sandboxing to mitigate potential security risks and ensure predictable behavior.

The necessity of sandboxing is critical for environments where agents interact with external tools or data. When an agent, such as a local AI agent workbench like Goose, is designed to integrate diverse local workflows, the ability to isolate execution is paramount.

The requirements for secure execution include:

  • Isolation: Ensuring that agent tools and their operations are confined to a specific, limited environment.
  • Risk Minimization: Reducing the potential attack surface by preventing unauthorized access to the host system (filesystem, network, credentials).
  • Reproducibility: Guaranteeing that the execution state remains consistent regardless of external system state.

Informing Policy Frameworks

Granular architectural distinctions directly inform the development of effective regulatory frameworks for AI risk management and control. Grouping diverse tools under a single label, such as “AI coding agents,” obscures these critical distinctions and prevents the application of context-specific controls.

Architectural separation allows policy frameworks to be applied based on the layer of operation:

  • Kernel/Harness Layer (Pi): Governance focuses on runtime design, provider abstraction, and reproducible workflows.
  • Workbench Layer (Goose): Governance focuses on developer workflows, orchestration surfaces, and local system integration.
  • Application Layer (OpenCode): Governance focuses on task-specific execution (e.g., code generation, file manipulation).

By recognizing these layers, regulatory bodies can mandate specific security and accountability standards based on the risk profile of the component being executed, rather than applying a uniform, inadequate standard across the entire agent stack.

References