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.
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.
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. |
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.
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