What is an agent control plane, and what stays with the vendor when you self-host runners?

Quick answer

An agent control plane is the service that decides who may start an agent session, what the agent is told to do next, which credentials it receives, and what record is kept afterwards. It is separate from the machine where commands execute. When a vendor lets you self-host runners, usually only execution moves into your network. Orchestration, transcripts, credentials and inference often stay with the vendor unless the contract and the architecture say otherwise.

The five parts, drawn separately

Vendors say self-hosted, private and in your VPC about different things. The way to compare them is to split a coding agent into five parts and ask where each one lives.

• Execution. The sandbox or runner where the agent clones the repository, runs commands and edits files. This is the data plane.
• Orchestration. The service that accepts a request from Slack, a schedule or a webhook, checks who is asking, starts a session, and drives the agent loop: what to do next, when to stop, where to report. This is the core of the control plane.
• Transcripts. The record of every prompt, tool call, command output and file diff. A transcript of a coding session contains your source code.
• Credentials. Repository tokens, cloud keys, integration tokens and model keys. Somebody stores them and somebody hands them to the session.
• Inference. The model call. Each call carries the code and context the agent is working on to wherever the model runs.

A plain picture of the usual self-hosted runner arrangement:

            VENDOR CLOUD                      YOUR NETWORK
  +-----------------------------+      +----------------------+
  | Orchestration (agent loop)  | <--> | Execution (runner)   |
  | Transcripts                 |      |  repo checkout       |
  | Credential store            |      |  shell, tests        |
  | Inference routing --> model |      +----------------------+
  +-----------------------------+

  Moved to you: 1 of 5.  Still with the vendor: 4 of 5.

Nothing is wrong with that arrangement if it matches what you need. The problem is assuming that a runner in your VPC means your code stays in your VPC. The runner sends file contents and command output back to the orchestrator, and the orchestrator sends them to a model.

Where each part lives, vendor by vendor

The table records only what each vendor's own pages state. Not documented means the pages we read do not establish it. It does not mean the answer is no, and it does not mean the answer is yes. Ask the vendor.

Three notes on reading it. Self-hosting is not the same as no outbound traffic: Coder's docs describe an outbound usage reporting endpoint, and OpenHands documents that self-hosted Slack needs publicly reachable HTTPS. An airgapped option can cost you features: Factory's negotiated airgap excludes Slack and cloud sync. And a beta label matters: Anthropic's customer-run environments are a public beta as of November 2026.

Why the difference matters

Each part answers a different question from a security or procurement review.

• Execution answers can the agent reach our internal services? A runner in your network can reach a private package registry or staging database.
• Orchestration answers who can start an agent and tell it what to do? If the vendor runs it, access to your runners is decided by the vendor's service, and an outage or a compromise there affects agents inside your network.
• Transcripts answer where is a copy of our code? Wherever transcripts are stored, your source and command output are stored.
• Credentials answer who holds the keys? A session needs a repository token. If the control plane stores it, the control plane's operator is in your trust boundary.
• Inference answers which third parties see the prompt? If the vendor routes model calls, the vendor sees them. If your gateway routes them, your existing provider agreements apply.

Inference also decides who bills you for tokens. That side is covered in do cloud coding agents mark up token costs.

Questions to send a vendor

Send these in writing and ask for one answer per part. A diagram is better than a sentence.

1. In the deployment you are proposing, which hosts run the service that starts sessions and drives the agent loop, and who operates them?
2. Where are session transcripts stored, in which account, and who at your company can read them?
3. Where are our repository tokens and integration credentials stored, and how do they reach the runner?
4. Which endpoint does the runner call for model inference: yours, the provider's, or our gateway?
5. Which outbound connections does the deployment need after installation: licensing, usage reporting, updates, telemetry?
6. Which features are removed in the most private option you sell: Slack, schedules, sync, web UI?
7. Does sign-in use our identity provider through SAML or OIDC, and are users provisioned and removed through SCIM?

If an answer is the runner is in your VPC, the question has not been answered. Ask again about the other four parts.

How Nori draws the line

Nori treats the control plane as part of the product you deploy, not as a service you call.

Enterprise. Nori deploys the full stack, control plane included, into your own AWS VPC or Azure VNet, or on-prem. Orchestration, transcripts, credentials and execution all run on your compute. Sign-in uses your identity provider with SAML, SCIM and OIDC. Inference goes to your own model accounts or your LLM gateway.

Hosted. Every Nori organization gets a dedicated, single-tenant control plane and data store. The service that starts your sessions and the store that keeps their record serve your organization only.

In both shapes the team works the same way. People start sessions from Slack, Discord, the web or the CLI. Cron schedules, reminders and webhooks start the same sessions with run history and approval paths. Org skillsets and shared memories give every session the team's context. Sessions run Jiro, Nori's AI engineering teammate, or any harness: Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Droid, Amp or any ACP agent. Nori never charges for tokens.

A request then looks like this from the inside. An engineer writes @nori rotate the staging API key in billing-api and open a PR in Slack. The control plane in your VPC checks the engineer against your identity provider, starts a sandbox on your compute, hands it that engineer's scoped credentials, sends model calls through your gateway, and stores the transcript in your data store. No part of the session leaves the boundary you already audit, except the model call you already approved.

For the basics of how sessions work, see what a cloud coding agent is. Security leaders can find the longer account on the security leaders page.

Frequently asked questions

Sources

Vendor pages were read on November 11, 2026. Deployment options and beta labels change; check the linked pages before you decide.

• Devin docs: Enterprise deployment overview
• Factory docs: Network and deployment
• Factory docs: Airgapped deployment
• Cursor docs: Self-hosted cloud agent workers
• Claude Code docs: Self-hosted environments
• Warp docs: Factories infrastructure and security
• Warp docs: Harness authentication
• Augment docs: Cosmos daemons
• OpenHands: Pricing
• OpenHands docs: Slack integration
• Coder: Pricing
• Coder docs: Agent licensing and usage