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. On the Start from catalog card, press Browse catalog — the card itself is not clickable, the button on it is. Browsing opens a grid of cards, one per agent. Each card tells you what you need to know before committing:
Readiness is about your account, not about the agent: the same entry can read Ready to deploy for
one account and Needs setup for another.
The catalog is curated and can differ between accounts, 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. A few entries whose scope is narrower than their name suggests also show a
notice here that you must tick before Next will move — it is your acknowledgement of what
that agent can and cannot see, so read it rather than clicking past it.
3
Choose where it runs
Most entries run on Komodor cloud. Some can also be installed in your own cluster, and a few —
an in-cluster Kubernetes investigator, for instance — only run there. This step appears only
when the entry has more than one option; when it has only one, the wizard skips the step and
uses it.
4
Choose the model
The Model step asks which model the agent runs on and how it authenticates to it: a model
credential already in your account, or one you supply here. Entries whose model is fixed do not
show this step.
5
Supply its integrations
The Integrations step collects the connections this entry declared it needs, plus any
secrets it uses at run time — not the model credential, which you set above. The wizard checks
them before anything is created, so a credential that is missing or a connection that is
inactive is reported here rather than at the first run. Some entries also let you choose MCP
tools on this step.
6
Add triggers
Triggers adds a cron schedule if the agent should run on its own.
7
Activate
Nothing is created until this step. On Komodor cloud, press Deploy to Komodor cloud and it
is usually live within a couple of minutes. For an entry you are installing yourself, this step
generates the worker token and install command instead — see
Self-hosted catalog agents.
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.
There is no Edit, so nothing above is behind one — each lives on its own surface on the agent’s
page. The Delegatable workers card behaves as an allowlist: leave it empty and the orchestrator
may use any agent that is online; select some and anything left out is refused on every run, and
cannot be picked as a specialist in an incident workflow that uses that orchestrator.
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.
Next steps
Agent catalog
Every catalog agent in depth — what it reads, its limits, and where it stops.
Integrations list
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.