§01 · Start
Core concepts
The pieces, and how they fit. Every term gets one line in the Glossary.
What runs where
Your dashboard holds the rules. Your cluster runs the work.
The control plane is the dashboard, the API and the database. Identity, access rules, audit trail. It never runs an agent.
The Exo Operator sits in your cluster. It starts agents, stops them, and dials out to the control plane. Nothing dials in. Architecture has the network detail.
Agents do the work. Everything else feeds one, fences one in, or keeps the receipt.
Agent
A worker you give a job to
Running on infrastructure you control.
the agent is built from
A model on your own account, plus what you taught it.
Provider·Runtime·Skill·Memory
the agent reaches
Only the systems you connected. Never the credentials.
Tool·MCP server
the agent leaves behind
A session you can replay. An entry you can search.
Run·Session·Event
the agent is checked by
Your rules, applied before it acts, and a spending ceiling.
Policy·LLM gateway
One path for every request
Dashboard, exo CLI, Slack, webhook. Same four checks, every time.
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
Dashboard
exo CLI
Slack & Teams
API & webhooks
checked before anything runs
One request path
every request, human or agentIdentity
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 pathModel 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.
→ one connection · credential injected at call time
Tool
A database, an API, a host, a cluster. Exo supplies the secret at the moment of use; the agent never sees it.
→ one registration · a catalog of tools
MCP server
A vendor's set of tools spoken over the Model Context Protocol. Register it once; Exo stores the credential and handles sign-in.
→ a way in · Exo holds the keys
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.
Who can act
Four identities. Each one separate.
- Users: People. One account, one role.
- Exo Operator: One token per cluster.
- Service endpoints: One narrow token each. SCIM, for instance.
- Agents: Their own identity. They never sign in.
The Auth model overview has each credential.
A fix requested from chat
Same run. Started in Slack.
From a Slack message to a merged fix
Slack channel
Someone tags @Exo
A teammate describes a bug in a channel and mentions the bot.
the message reaches Exo
Control plane
Exo 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
Exo 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
Exo 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.
A report on a schedule
A schedule fires it. Nobody is watching, so the recording is your only view.
A weekly report with nobody watching
Schedule or webhook
A cron time or an inbound call wakes the agent
Nobody clicks Run. A weekly cron fire and a webhook call dispatch through the same path as the dashboard's Run button.
Exo checks the fire is still allowed
Control plane
Exo confirms the agent may still run
The decision comes from Exo's own record of the agent, not the cluster's copy. Pausing or deleting the agent blocks the fire, and a fire with no answer is skipped rather than queued.
an allowed fire starts the agent
Customer's own cluster
The agent starts with nobody watching
No person opens a session or approves a step. It is the same run pod as any other launch, just started by the clock instead of a click.
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
It calls Exo's chat notify endpoint with its own agent permissions, and Exo relays the message to Slack. Teams has no equivalent yet: today it can only reply inside a conversation a Teams message already started, and a scheduled run has no such conversation to reply into.
the run is kept exactly like any other
Session, audit, and usage
Monday's run sits next to every other run
Same session recording, same audit entries, same usage metering. Running on a timer doesn't exempt it from any of them.
Sessions vs events
Two trails. Inside a run, that is a session. On the platform, who signed in and who changed a setting, that is an event.