Architecture

The control plane

The control plane handles identity, policies, approvals, and execution routing. Managed agents and tools run in connected deployments on Kubernetes, hosts, or ECS. The available runtimes and isolation controls depend on the deployment type.

Clients & triggers

Console · CLI · SDK & API clients · webhooks & triggers

Web

Every request enters at the Auth Layer

Industric control plane

One authenticated entry point; every action passes the same checks before it is dispatched

Auth Layer

Sign-in, workspace roles & resource permissions

RESTMCPWebhooksWebSocket

Decision layer

How a tool action is checked and sent to a deployment

1AuthorizeCaller, workspace & resource access

2Evaluate policyBound policies, optional OPA: allow, deny or hold

3Approvewhen requiredAn eligible approver, the exact action, used once

4DispatchOver the owning deployment's connection; streams relayed back

Operational Layer

Shared by every surface

Policy distributionEffective policies for harnesses, deployments & gateways

OrchestrationAgent runs, workflows, schedules & live sessions

Sentinel ingestionWorkstation inventory, activity & add-on control

Audit & usagePolicy decisions, approvals, sessions & model usage

Outbound WebSocket

Connected deployments

Workloads run in your infrastructure

Kubernetes · Operator & connectorAgent, tool & MCP workloads

Hosts · Host agentSupported host runtimes & tool execution

ECS · ECS agentSupported ECS tasks & tool execution

Each deployment maintains an authenticated, outbound connection. Commands and results share that channel; the control plane needs no inbound route to the deployment.

Requests pass through the Auth Layer, policy checks, and any required approval before dispatch. Each decision is recorded.

Deployments connect outbound to the control plane to exchange state, commands, and session streams.

Why outbound-only matters

Most production clusters refuse inbound traffic by default. Outbound-only means no new ingress to clear with security and no public load balancer to misconfigure. An Industric Operator cluster needs only egress to your platform host on 443, and can run fully unmanaged with no control-plane connection at all.

Execution and protection surfaces

Managed deployments: Kubernetes operators, host agents, and ECS connectors run supported workloads and connect outbound to the control plane.
Workstations: Agent Sentinel reports inventory and activity and applies supported configured endpoint controls.
Automation: workflows coordinate agents and control steps under a run-as identity.
Model traffic: gateways meter and govern routed requests. Direct provider calls are outside that path.

Protection depends on resource bindings and the execution path. A recorded shell does not imply per-keystroke policy enforcement, inventory does not establish active protection, and Browser Sentinel remains proposed. See Resource policies for enforcement boundaries.

Kubernetes components

Three components (the CRDs, the operator, and the platform) plus a few published images the operator pulls at runtime.

CRDs. The custom resource definitions. Registering them is what lets you author agents and tools as Kubernetes objects. See CRD overview.
Operator. The autonomic-manager, a controller-runtime operator (Deployment + RBAC + admission webhook) that reconciles the CRDs into running pods and, optionally, connects out to the platform. See Deploying the manager.
Platform. The Industric backend with the UI embedded in the same binary, plus PostgreSQL. This is the Platform, the identity layer, the audit store, and the control plane the Industric Operator phones home to.

One installer for all three

exo-install applies all three from manifests embedded in the binary, through your own kubectl. You can also install each piece separately, which helps when the operator and platform live in different clusters.

Topologies

All-in-one. Platform + operator + CRDs in one cluster. The quickstarts and a default exo-install land here.
Hub-and-spoke. One platform cluster; many Industric Operator clusters, each in managed mode connecting back over one outbound WebSocket. Each spoke is its own deployment in the Platform.
Local-only. Operator + CRDs with no platform, fully unmanaged. Agents run but nothing phones home. Good for dev and air-gapped edge.