RUN

Run Agent Fleets at Scale, Anywhere

Q: Does our data leave our environment?

That depends on how you deploy. Self-hosted agents keep credentials inside your network and call internal systems directly. Secrets reach a run in memory and are never written into its record. Each run’s evidence (inputs, tool calls, reasoning, output and usage) is sent to the control plane, so organizations that need all data to stay in their environment self-host the control plane as well as the agents. Docs link: Deployment methods

Q: Do we need to open inbound access to our network?

No. Komodor agents only make outbound TLS connections to the control plane. Nothing listens for inbound traffic and no ports need to be opened, so agents work behind NAT and in private networks. To reach internal services, you can run an Outpost: a small, outbound-only, deny-by-default relay inside your network that only allows the destinations you list. Docs link: Network & egress control

Q: Can we use our own models, API keys or LLM gateway?

Yes. Use Komodor-managed models, connect your own provider credentials, or point self-hosted agents at your own gateway. Supported providers include Anthropic, OpenAI, Azure, Amazon Bedrock, Vertex AI and Gemini, and supported gateways include LiteLLM and vLLM. You choose the model per agent and can change it as the market moves without re-platforming. When you route through your own gateway, inference requests don’t pass through Komodor’s model gateway. Docs link: Providers

Q: How are agents triggered?

The way your team already works. Agents can start from an alert or any system that calls a webhook, on a schedule, from a Slack message or chat session, from a step in a workflow, or when another agent delegates to them. You can also run them manually. Every trigger produces the same thing: a run with a full evidence trail. Docs link: How Run works

Q: Can our team work with agents from Slack?

Yes. Connect Slack, and your team can start agents, workflows and incident pipelines from the conversations they’re already having, with results posted back in the thread. Agents are also available through resumable chat sessions in the Komodor console, and programmatically through the API and MCP server. Docs link: Channels

Q: How does agent memory work, and can we review it?

After each run, an agent proposes what to remember, such as a root cause or a fix that worked. A reviewer agent checks every draft and removes duplicates before it’s published. Memory is private to each agent by default, or shared between agents you choose. You can see, edit and archive every memory, so future runs build on what worked instead of starting cold. Docs link: Memory

Q: What is the knowledge graph, and do we have to build it?

The knowledge graph is a live map of your services, owners, dependencies, deploys and data stores. The platform keeps it current from operational activity, so you don’t build it by hand. It sits next to two things you control: the knowledge base, where you upload runbooks and service docs, and agent memory. Together they give every agent the same picture of your environment. Docs link: Knowledge base

Q: Do we need to run Kubernetes to use the platform?

No. Agents on Komodor Cloud need no infrastructure of your own, and self-hosted agents can run on Kubernetes, VMs or containers. Kubernetes is one of many environments the platform’s agents can investigate and operate. It isn’t a requirement for running them. Docs link: Deployment methods

Q: Can we manage agents through an API, MCP or Kubernetes manifests instead of the UI?

Yes. Everything the console does is available through Komodor’s versioned REST API and its MCP server, under the same permissions. You can also declare platform resources as Kubernetes manifests in source control and let an in-cluster operator reconcile them. Changes then go through your normal review process instead of the console. Docs link: Developer tools

Komodor gives SRE, Platform and DevOps teams the control plane to run and manage agents in end-to-end workflows that drive real operational outcomes. Whether self-hosted in the cloud or on-prem, or managed on Komodor Cloud, run one unified fleet, with every agent action orchestrated and recorded.

Book Demo

Run Anywhere

Run the Komodor platform wherever your infrastructure already lives, so you’re never locked into someone else’s data-residency or compliance posture.

Deploy Anywhere

Your cloud, on-prem, or Komodor Cloud.
Bring your own model

Use Komodor’s managed models, or choose the provider and model that fits your organization.
Compliance-friendly by default

Self host to keep your data in your environment.

Full Fleet Management

As agent count grows across teams, it’s hard to keep track of what’s running, what’s stuck, and what it’s costing. With Komodor you get a centralized control plane for every agent running.

Full fleet inventory

Shows every registered agent, its health, ownership, labels, and metadata in one place.
Agent versioning history

Tied to optimization experiments, so you can see what changed and why.
Orchestrate agent-to-agent communication

One agent’s output becomes the next one’s input, orchestrated by the control plane.
Manage and approve skills and agents

Updates move through publish-and-approve before they’re live, and any agent can be paused, retired, or reassigned.
Agent chat

Resumable conversations with chat-capable agents about fleet health, incidents, or evidence.
Autoscaling

Ensures agents scale automatically with load.

Memory and Context For Every Agent

Whether pre-built or your own, every agent connects to the same shared memory layer, so institutional knowledge compounds instead of resetting each run.

Operational memory

Past runs, RCAs, and fixes feed every future one – across incident response, cost reduction and maintenance.
Continual learning loop

Approvals and grades from past runs improve the ones that follow.
Shared tribal knowledge

Context carries across users and agents, so nobody starts from scratch.
Live knowledge graph

An automatically maintained map of every service, owner, dependency, deploy, and data store.

Unified Governance for Every Running Agent

Every agent running on Komodor — built, imported, or pulled from the catalog — inherits the same RBAC, credential brokering, and approval gates the moment it goes live.

Learn More

Scoped RBAC

Every agent operates under the same role-based access your human users already have, no separate permission model to configure per agent.
Brokered credentials

Every tool call gets a credential minted for that one call, never a standing key an agent holds and could leak.
Guardrails

Every input, tool call, and model response is checked before it’s acted on — catches get redacted, blocked, or held for a human decision automatically.
Full run evidence

Every trigger, tool call, decision, and cost automatically recorded, so nothing needs reconstructing from scattered logs.
Deny by default

An agent can only do what it’s explicitly been scoped to do; nothing is implicitly trusted just because it’s running.

Agents that Meet You Where You Work

However your team already works, agents on the Komodor platform fit in, triggered by a ticket, a schedule, an alert, or a chat message, and managed through whatever interface you already use.

Explore Documentation

Trigger agents automatically

By alerts, schedules, PRs, other agents, or chat.
Manage agents your way

Manage agents via API, MCP, IaC definitions, CRDs, or the UI.

The Gap Between an Agent and a Reliable Operational Process

An incident response workflow orchestrates agents across multiple steps from trigger to outcome.

Ingest & Produce

Synthesize & Analyze

Signal Agent

Investigate

Agent A VS Agent B

Remediate

Proposer Executor

Verify

No agent needed

Notify

Out-of-the-box agent
Bring-your-own agent
VS Competing agents
Tandem agents

Build

However it got here. Built from scratch, imported, or pulled from the catalog, every agent lands in the same fleet the moment it’s live.

Run

Wherever it runs, every agent in your fleet carries the same permissions and audit trail, visible right in the fleet view.

Optimize

Every run, already graded. What you’re watching here is scored under the same evaluation engine from its first run.

Govern

Every action, already scoped. What’s running is already permissioned under the same RBAC and approval rules your team set.

Where do our agents run: our cloud, on-prem, or Komodor's?

Your choice. With the Komodor Agentic Operations Platform you can run agents on Komodor Cloud with no infrastructure of your own, or self-host them in your cloud or on-prem on Kubernetes, VMs or containers. You can also mix both in one fleet. Agents that need to reach private clusters or internal services usually run self-hosted. The control plane can be self-hosted too, for organizations that need everything inside their own environment.

Docs link: Deployment methods

Does our data leave our environment?

Do we need to open inbound access to our network?

Can we use our own models, API keys or LLM gateway?

How are agents triggered?

Can our team work with agents from Slack?

How does agent memory work, and can we review it?

What is the knowledge graph, and do we have to build it?

Do we need to run Kubernetes to use the platform?

Can we manage agents through an API, MCP or Kubernetes manifests instead of the UI?

Ready to run agentic operations that scale with you?

Book Demo

Run Agent Fleets at Scale, Anywhere