Skip to content
industricAgents

Core concepts

Overview

Industric has one control plane and governs three kinds of agents. The control plane provides the Platform, API, identity, policies, approvals, orchestration, and audit storage. Every request, from a person or an agent, passes through it.

Users
Console, exo CLI, Slack & Teams, approvers
Your identity provider
SSO, directory sync, SCIM
Events
Webhooks, schedules, API calls
Industric control plane
Managed cloud, or hosted by you
Auth Layer
Sign-in, roles, resource permissions
Policies
Bound, evaluated, distributed
Approvals
Exact action, eligible approver
Orchestration
Runs, workflows, schedules, sessions
Sentinel ingestion
Device inventory and activity
Audit & usage
Decisions, sessions, events, spend
User agents
Agents people run themselves
Employee workstations
Harnesses & IDE agents
Claude Code, Codex, Gemini CLI, Cursor
exo CLI
Tools, chat, and sessions from a terminal
Agent Sentinel
Inventory, activity, network guard, supervised runs
Governed by Agent Sentinel and policy hooks
Managed agents
Agents Industric runs for you
Your deployments: Kubernetes, hosts, ECS, or Agent Cloud
Industric Operator
Starts agents, keeps one outbound connection
Agent containers
Agents and workflow steps
Tools & MCP proxies
Reach your systems with credentials injected
Governed by policies, approvals, and sandbox guardrails
Workload AI
AI inside your own software
Kubernetes, VMs, or serverless
Apps & services
Features that call a model
RAG & batch jobs
Pipelines that call a model
Governed by the LLM gateway
Model calls
From all three, when routed
LLM gateway
Virtual keys, budgets and rate limits, input and output guardrails, usage per person and agent. Runs in a deployment or standalone.
Model providers
Anthropic, OpenAI, Gemini, and private models
One control plane, three kinds of agents. Calls made straight to a provider with a personal key bypass the gateway.
Kind of agentWhere it runsGoverned by
User agentsWorkstations: Claude Code, Codex, Gemini CLI, Cursor, and the exo CLI.Agent Sentinel, policy hooks, and the gateway when routed.
Managed agentsYour deployments on Kubernetes, hosts, ECS, or Agent Cloud: agents and workflow steps.Policies, approvals, and sandbox guardrails, over the operator's connection.
Workload AIYour own apps, services, RAG pipelines, and batch jobs.The LLM gateway, through a gateway key in place of a provider key.

Request flow

Whether a request comes from the Platform, the exo CLI, a chat app like Slack, or an API webhook, it always follows the exact same security path. Before any work begins, Industric establishes who is asking, checks that they are allowed to ask (your role and permissions from the Platform, CLI, and API; the sender and channel allow list from chat), confirms policy permits the action, and logs it.

Nothing runs until Exo knows who is asking, what they may do, and whether policy allows it. Then it writes the record. Model calls count against your budget. Tool calls clear policy first.

Four ways in
Platform
exo CLI
Slack & Teams
API & webhooks
checked before anything runs

Industric

every request, human or agent
Identity
who is asking
Permissions
what they may do
Policy
is this action allowed
Audit
recorded, searchable
work starts

Agents

in your cluster · their traffic returns through the same path
Model calls
usage metered, budgets enforced
Tool calls
checked against policy, written to audit

Three ways an agent connects

Access goes to one agent at a time, never to all of them. Set them up in Tools and MCP servers.

Agent
The worker. Runs in your cluster with a goal, a model, and a short list of things it may reach.
Tool
A database, an API, a host, a cluster. Industric supplies the secret at the moment of use; the agent never sees it.
MCP server
A vendor's set of tools spoken over the Model Context Protocol. Register it once; Industric stores the credential and handles sign-in.
Integration
A workplace app connection. Someone mentions an agent in Slack or Teams, the run starts, and the reply lands back in the same thread.
Three lanes, one rule: access is granted per agent, and every call is recorded.

Who can act

There are four distinct types of identities in Industric:

  • Users: Real people with personal accounts and a specific role.
  • Industric Operator: Uses a single deployment token per cluster.
  • Service endpoints: Use narrow, specific tokens for inbound systems like SCIM.
  • Agents: Operate under their own governed identity without ever logging in.

The Auth model overview has each credential.

Slack Flow

From a Slack message to a merged fix
Slack channel
Someone tags @Industric
A teammate describes a bug in a channel and mentions the bot.
the message reaches Industric
Control plane
Industric checks who's asking
It looks at the sender and the channel and confirms this workspace allows them to run an agent, before anything starts.
an allowed request starts the agent
Customer's own cluster
An agent wakes up and looks into it
A fresh agent starts inside the customer's own Kubernetes cluster and reads the code to find the cause.
the agent reaches for a tool
GitHub tool
The agent writes a fix and opens a pull request
Industric hands the tool a saved GitHub key at the moment it's needed, so the agent can push a branch and open the pull request.
the link travels back to the thread
Same Slack thread
Industric posts the pull request link
A person reads the reply, reviews the change, and merges it themselves.
the whole run is kept
Audit trail
Every step is on record
The run can be replayed from the start, and each tool call the agent made is logged.
One mention, one checked identity, one run that can always be replayed.

Webhook Flow

From a webhook to a completed report
Inbound webhook
An external service requests a run
A service POSTs to the agent's webhook URL with its token and, when configured, a request signature.
Industric checks the request
Control plane
Industric confirms the agent may still run
Industric validates the webhook credentials and confirms that the agent can run in the background.
an allowed request starts the agent
Customer's own cluster
The agent starts a background run
The agent runs in your connected deployment with the webhook payload as its input.
the agent reaches for the data warehouse
Governed tool pod
The query runs in its own pod, not the agent's
The warehouse credential is mounted only into a separate pod, from a Kubernetes Secret you own. The agent runs its query there over a bridged connection and never holds the credential itself.
the summary needs a home
Slack channel
The agent posts the summary itself
The agent sends the report to Slack using its configured permissions.
the run is kept exactly like any other
Session, audit, and usage
The run is recorded
Review the session recording, audit entries, and usage alongside other agent runs.
A webhook starts the run. The same permissions, policies, and audit trail apply.

Sessions vs events

We split our audit trails into two helpful streams to make troubleshooting easier:

  • Sessions: What happened inside a specific agent run. These are fully replayable.
  • Events: What happened on the platform itself, like who signed in or changed settings. These are searchable and exportable.

Need a quick definition? Our Glossary covers every Industric term in a single sentence.