Architecture

The Komodor Agentic Operation Platform (KAOP) has three parts: a control plane that holds every agent, run, credential and policy; the SDK you author an agent with; and the workers that execute agents wherever you run them. A worker connects outward to the control plane and receives its work over that connection, so agents run behind NAT, inside a private cluster, or with egress-only networking, and no inbound path is ever needed.

​

System overview

​

The control plane

The control plane is the boundary for everything durable. It owns:

• Your agents: which exist, which are online, and what each one can do.
• Runs: starting them, tracking them, and streaming their progress to you.
• What starts work: schedules, inbound endpoints, Slack routing, chat, workflows, and modules.
• Evidence: everything an agent reports while it runs: the tools it called, its reasoning, its output, its logs, and what it cost.
• Who may do what: identity, permissions, approvals, and the audit log.

​

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.
• Reports as it works. During a run it streams tool calls, reasoning, output, logs, and usage back to the control plane. What you see in a run is exactly what the worker reported while it ran.

​

Follow one run, end to end

One alert-driven run, end to end, from inbound request to recorded evidence. An alert posts to an endpoint you created; the control plane records the run and answers 202 Accepted, meaning the run was accepted for background processing, not that the investigation succeeded. The job travels to the worker over the worker’s own outbound connection, carrying the prompt, the input, correlation IDs, and the run-scoped credentials it needs. The worker’s tool calls go through the MCP Gateway, which adds scoped credentials the agent never sees; spans, usage and output stream back as the run’s evidence. Where an action is gated, the run waits for the approval decision and records it. Rotating a stored credential takes effect on the next run without redeploying the agent.

​

Account isolation

Every agent, run, integration, credential, and record belongs to exactly one account, and that boundary is enforced on every read and write. An agent in one account 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 and Agent isolation & tenancy.

​

Boundaries you can rely on

• Agents never touch the platform’s database; only the control plane does.
• The console talks only to the control plane.
• Agents need outbound HTTPS to the control plane; inbound access to an agent is never required.
• No inbound firewall rule, public endpoint, or VPN is needed to run agents in a private network.
• Secrets are delivered to a run in memory and never exposed to you or written to its evidence.
• When nothing is running, the only traffic between an agent and the control plane is a periodic “still here”.

​

Next steps