When to use a catalog agent
The two are not exclusive. A common shape is a catalog investigator doing the reading and an agent
you wrote doing the part that is specific to you.
Browse the catalog
Add agent opens the starting-point picker. Choose Start from catalog and Browse catalog. Each entry’s card tells you what you need to know before committing:The catalog is curated and can differ between workspaces, so treat the entries in your own console as
the authoritative list. The Agent catalog reference
documents each agent in depth — what it reads, what to connect, its model and time budget, and where
it stops.
What the catalog covers
The catalog is organized by what an agent is for.Deploy one
1
Pick the entry
Selecting a card opens the wizard on that agent, with a shorter step list than authoring your own
— the agent’s instructions and behavior are already decided.
2
Name it
On Agent card, set the display name and, if you want, labels. The default name is the
catalog entry’s.
3
Choose where it runs
Most entries deploy to Komodor cloud. Some also offer a self-hosted deploy, and a few — an
in-cluster Kubernetes investigator, for instance — only make sense in your own cluster. An entry
with only one possible home does not ask.
4
Supply its integrations and credentials
The Integrations step collects exactly what this agent declared it needs, and the wizard
checks them before anything is created. A credential that is missing or a connection that is
inactive is reported here rather than at the first run.
5
Choose the model, if the entry lets you
Entries that take a model credential offer a Model step.
6
Add tools and triggers
MCP tools binds an integration group; Triggers adds a cron schedule if the agent should
run on its own.
7
Deploy
Press Deploy to Komodor cloud. Komodor provisions and runs the agent — usually live within a
couple of minutes.
What “deploy to Komodor cloud” means
Komodor runs the process for you. There is nothing to install, no cluster to prepare, and no worker to keep alive. KAOP provisions the agent, brings it up, and manages its replicas. The agent shows as deploying while it comes up, then online once it reports in. If provisioning fails you get deploy failed with the reason, rather than an agent that silently never appears.Secrets are not baked into the deployment. The values live in the encrypted credential store and are
delivered to each run — which is why rotating a credential takes effect without redeploying the
agent.
Self-hosted catalog agents
Some entries publish a public image you can run yourself. Choosing self-hosted mints a worker token — shown once — and hands you the command and values to install it. From there it behaves like any agent you run: see Deploy an agent.What you can change afterwards
This is the real trade for the convenience, and it is worth understanding before you deploy. A catalog agent’s behavior is sealed to the version you deployed. Its instructions and its reasoning are part of the validated image, so there is no Edit for them and no revert — the console does not offer either on a catalog agent. What you get in exchange is an agent whose behavior does not drift and whose runs are comparable over time.
If you need behavior an entry does not have, author your own agent instead. See
Build from scratch.
After it is live
A catalog agent is an agent like any other from here on: it appears in Fleet, produces runs with full evidence, is governed by the same permissions and guardrails, and shows up in spend and quality.Run it once
Invoke it manually and read the run before you schedule it.
Manage it
Enable, disable, label, archive, and read its activity.
Next steps
Agent catalog
Every catalog agent in depth — what it reads, its limits, and where it stops.
Built-in integrations
Connect what a catalog agent needs before you deploy it.
Triggers & schedules
Give it a recurring schedule.
Modules & workflows
Bind specialists to workflow steps instead of running them one at a time.
Build from scratch
When no catalog entry fits.