---
title: The Execution Plane
url: https://revworx.ai/architecture/10/
date: 2026-10-20T14:59:29+00:00
modified: 2026-11-08T03:08:32+00:00
lang: en_US
---

Section 10 · Part two

# The Execution Plane

Most agent architectures are hosting-agnostic, which in practice means every operational concern is left to vendors. That is a legitimate choice with a real cost: capability is limited to what vendors expose, and spend scales with seats and usage tiers rather than with the computing you actually use. This architecture owns and operates its infrastructure instead, and the trade is explicit. In exchange for owning uptime, patching and monitoring, cost shifts from per-seat subscriptions to predictable infrastructure spend, and the capability ceiling becomes whatever can be deployed.

In this section

[10.1The system that extends itself](#10-1)[10.2Running a fleet of servers](#10-2)

Part two

[§7The shape of the architecture](/architecture/7)[§8The Cognition Plane](/architecture/8)[§9The Tool Plane](/architecture/9)

§10The Execution Plane

[§11The Data Plane](/architecture/11)

[Download the PDF →](/wp-content/uploads/2026/10/composable-reference-architecture.pdf)

In brief

Most agent architectures leave operations to vendors. This one owns and operates its infrastructure: in exchange for owning uptime, patching and monitoring, cost shifts from per-seat subscriptions to predictable infrastructure spend. Because the agent can reach the infrastructure, it can provision, deploy, repair and expose new capability, and each integration lowers the cost of the next.

The internal split matters as much as the ownership. Orchestration runs on one host; the website, social scheduling and analytics run on another. The reason is containment during ordinary work, not disaster recovery. A website plugin upgrade should never interrupt an agent mid-task, and an agent restart should never take your public site down.

![Figure 8 — The Execution Plane: two hosts on shared infrastructure](https://revworx.ai/wp-content/uploads/cra-figure-8-execution-plane.png)

*Figure 8 — The Execution Plane: two hosts on shared infrastructure*

## 10.1The system that extends itself

Once infrastructure is reachable through the same protocol as everything else, the Cognition Plane can extend its own capability. In one conversation it can set up a new server, deploy software to it, propose a code change to a tool it maintains, test and release that change, and point a web address at the result. It can add a server from the catalog to the live session and drop it when the task is done, and it can restart, inspect and repair the services it runs on.

The effect compounds. Each new integration extends what the Cognition Plane can reach, which makes the next one cheaper. New capability arrives through conversation rather than re-platforming, so the architecture in month eighteen is not the architecture in month six, and the difference was built, not bought. This is how capability grows faster than team size, and it is composability seen from the operator's side.

## 10.2Running a fleet of servers

A handful of servers can run from hand-edited configuration. A fleet of dozens cannot, or rather it can, right up until the management overhead quietly becomes the largest operating cost. Five problems appear specifically at fleet scale, and each needs a structural answer rather than discipline. Table 1 lists them.

One distinction keeps the claim honest. The gateway routes and holds credentials for every server, hosted and self-hosted alike. Direct management applies only to the self-hosted ones. Vendor-hosted servers show up as a health signal, not as something the agent can restart.

| Problem at fleet scale | Structural answer |
| --- | --- |
| Tool bloat | Progressive disclosure (Section 4): zero standing definition cost, one tool inspected at a time. |
| Login credentials everywhere | One place, the gateway, supplies them. Credentials are passed in at the moment of each call and never sit with the agent or on an operator's machine. |
| Version drift and tampered software | A curated catalog that locks each server to a specific, verified release, checked at deployment, with the catalog itself under version control. |
| Keeping servers running | Direct control over the servers' containers, and a deployment tool for the applications. The agent can recreate, inspect and repair its own fleet. |
| Limiting the damage of a fault | Resource limits on every server, a separate network, and a permission filter that allows only the operations a workflow needs. |

Table 1 — Fleet-scale problems and their structural answers

Current implementation

Two Vultr VPS instances separate the control plane from the application plane. The shared infrastructure runs Docker Engine, Dokploy with registry auto-deploy, the Docker MCP Gateway against a version-controlled custom catalog, Traefik for reverse proxy and TLS, GitHub Actions for CI/CD, and Cloudflare for DNS. In production, access to the container runtime goes through a permission-scoped socket proxy, with the agent runtime on a dedicated network.

What composes hereThe host provider, the deployment tooling and any individual service. An organization with no appetite for running infrastructure can substitute a managed Execution Plane and keep the other three planes intact.

Key takeaway

Infrastructure the agent can reach makes the system self-extending: it can provision, deploy, repair and expose new capability through the same surface it uses for the work. Each integration lowers the cost of the next.

Cite as: revWorx (2026). A Composable Reference Architecture for Autonomous GTM Operations, First Edition, §10. revworx.ai/architecture/10