> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Architecture
> How the control plane, your agents, and the evidence trail fit together — and where the boundaries are.
The Komodor Agentic Operation Platform (KAOP) has two moving parts that matter: a **control plane**
that owns state and decides what happens, and **agents** that run as worker processes and do the
work. This page explains how they fit, how work reaches an agent, and which boundaries are
guaranteed — enough to reason about deployment, security, and debugging.
## The shape of it
```mermaid theme={null}
flowchart LR
Human["Person / browser"] --> Console["Web console"]
Alerting["Alerting, SCM,
schedules, Slack"] --> CP
Console <-->|REST + streaming| CP["Control plane"]
CP <-->|reads / writes| DB[("Durable storage")]
Worker["Worker process
agent code + SDK"] -->|registration, evidence, results| CP
CP -->|delivers work| Worker
Worker --> Tools["Datadog, GitHub, AWS,
Kubernetes, LLMs, MCP tools"]
```
## The control plane
The control plane is the boundary for everything durable. It owns:
* **The agent registry** — which agents exist, which are online, and what each advertises.
* **Run lifecycle** — starting runs, tracking them, and streaming progress.
* **How work starts** — schedules, inbound endpoints, channel routing, chat, workflows, and
modules.
* **Evidence ingestion** — the spans, logs, messages, artifacts, output, and token usage that
arrive from agents during a run.
* **Identity, authorization, and audit** — who and what may act, and the record of what they did.
* **Durable storage** — it is the only component that talks to the database.
## Agents and workers
An **agent** is the governed identity and behavior. A **worker** is the process that runs it, built
with the Python or Go SDK. One worker runs one agent.
A worker does two things continuously, independent of any run:
* **Registers and stays present.** It reports in periodically; the first report registers the
agent, and if reports stop, the agent shows as offline.
* **Ships evidence.** During a run it streams spans, logs, messages, output updates, and token
usage back to the control plane in batches.
Everything you later see about a run arrived this way. Nothing is reconstructed after the fact.
## How work reaches an agent
Two transports, chosen by what the network allows rather than by the caller:
The worker holds an outbound connection open to the control plane, and work is pushed down it.
Nothing needs to reach *into* the worker — which is what lets agents run behind NAT, inside a
private cluster, or with outbound-only egress.
The control plane calls the worker's registered endpoint directly. This requires the worker to
be reachable from the control plane.
When a worker holds a live outbound connection, that path is preferred; otherwise the control
plane dials the worker.
The practical consequence: an agent needs **outbound** access to the control plane, and nothing
more. You do not have to expose an inbound endpoint to run agents in a private network.
## What can start a run
| Path | Typical source |
| ----------------- | ------------------------------------------------------- |
| Manual invocation | Someone runs an agent from the console or the API |
| Schedule | A recurring cron trigger |
| Inbound endpoint | An external system posting to an endpoint you created |
| Channel | A Slack message matching a routing rule |
| Chat | A conversation with a chat-capable agent |
| Workflow step | A step delivering a task to one or more agents |
| Module | A module's workflow reacting to something in its domain |
| Another agent | An agent invoking an agent through the control plane |
See [Run — how it works](/manage-your-agents/run/how-it-works).
## Workspace isolation
Every agent, run, integration, credential, and record belongs to exactly one **workspace**, and
that boundary is enforced on every read and write. An agent in one workspace cannot see or reach
another's data.
Agents themselves are governed principals: an agent's permissions are checked at the moment it
acts, not just when someone starts it. See
[Agent identity](/security-and-governance/identity-and-access/agent-identity) and
[Agent isolation & tenancy](/security-and-governance/architecture-considerations/agent-isolation-tenancy).
## Boundaries you can rely on
* Only the control plane talks to the database. Agents never need database access.
* The console talks only to the control plane.
* Agents need outbound access to the control plane; inbound access to an agent is optional.
* Secrets are delivered to a run in memory and never exposed to you or written to its evidence.
* When nothing is running, presence traffic is the only continuous agent-to-control-plane activity.
## Next steps
Which parts run on Komodor's infrastructure and which run on yours.
What the evidence trail contains and how to read it.
Every surface that talks to the control plane.
How access and actions are governed.
## Related topics
- [Data flow](/get-started/architecture/data-flow.md)
- [Control plane](/get-started/architecture/control-plane.md)
- [Agent isolation & tenancy](/security-and-governance/architecture-considerations/agent-isolation-tenancy.md)
- [Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction.md)
- [Network & egress control](/security-and-governance/architecture-considerations/network-egress-control.md)