The hardest agent infrastructure question is not “how do we run agents?” It is “where do we run them?”

Agents that operate customer data might need to run inside the customer’s cloud. Agents accessing internal systems might need to run inside the private network. Agents supporting regulated workloads might need to run on-prem.

Most agent platforms force you to pick one environment. Run everything in our cloud, or build it yourself.

sypho takes a different approach: central control, distributed execution.

The control plane manages orchestration

The control plane is where you:

  • Define agent deployments
  • Configure tool, secret, and budget policies
  • Manage structured-data scopes
  • Track runs and observe traces
  • Review logs and track spend

This is the single operational view for all agent execution, regardless of where the agents actually run.

Runners execute workloads locally

Runners are worker pools that claim steps from the control plane and execute agent containers in their environment.

A runner might live:

  • On your local machine (for development)
  • Inside your private cloud (for internal workloads)
  • Inside a customer’s infrastructure (for customer-specific agents)
  • On-prem (for regulated environments)
  • In sypho-managed infrastructure (for simple hosted execution)

A runner is a lightweight binary plus Docker — it connects to the control plane, claims work, spawns a network-isolated sandbox for the agent, and reports results back. Nothing about it is tied to a specific cloud.

Why this separation matters

Data locality — Agents can run close to the systems and data they need to access.

Security and compliance — Sensitive workloads stay inside controlled environments without losing visibility.

Hybrid execution — You can mix environments. Some agents run in your cloud, others in customer clouds, all managed from one place.

Portability — If requirements change, you can move execution without rebuilding the agent.

How sypho routes work to runners

When you create a run, you specify the target environment:

deployment: support-agent
version: 0.4.2
deployment_type: production

The control plane queues the work. Runners registered against that deployment claim it — wherever that runner happens to be running. The agent executes inside its sandbox. Results stream back to the control plane.

Runners use lease-based claiming:

  • Runner claims step → Lease issued (30s TTL)
  • Runner heartbeats every 10s to renew lease
  • If runner crashes, lease expires → Step auto-requeued
  • Completion → Lease released

This makes execution fault-tolerant by default.

Central visibility, distributed execution

Even though agents run in different environments, all observability flows to the control plane:

  • Every tool call is logged
  • Every step is traced
  • Every run is auditable

You get one operational view, regardless of where execution happened.

This is how production infrastructure scales

Most serious infrastructure platforms separate control from execution:

  • Kubernetes has a control plane and worker nodes
  • Cloud platforms have control APIs and regional compute
  • CI/CD systems have orchestrators and distributed runners

Agent infrastructure needs the same separation.

sypho gives you a control plane for managing agent execution, and portable runners for executing workloads where they need to live.

Need a control plane built for how agents actually run? Join the sypho waitlist to get early access to the control plane and runner architecture.