> ## 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. # Use specialized agents > Deploy a Komodor-built specialized agent from the catalog — validated, ready to run, and live in minutes without writing code. The fastest way to get real work out of the Komodor Agentic Operation Platform (KAOP) is to deploy an agent someone has already built and validated. The catalog holds Komodor-built specialized agents — investigators, remediators, orchestrators, evaluators — that you deploy as-is, supply credentials for, and run. This page covers browsing the catalog, what a deploy actually does, and what you can and cannot change afterwards. ## When to use a catalog agent | Use a catalog agent when | Author your own when | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | The job is a common operations problem — investigate an alert, trace a cost spike, review a PR | The job depends on your systems, your data, or your runbooks | | You want a working evidence trail today | You need behavior no catalog entry has | | You would rather not run the process yourself | You need the agent to run inside your own network | 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: | On the card | What it means | | ------------------------------- | ------------------------------------------------- | | Name, category, and description | What the agent does | | **Integrations** | Which connections and credentials it needs | | **MCP** | Whether it uses gateway tools | | **Ready to deploy** | Your workspace already has everything it needs | | **Needs setup** | Something is missing — the wizard will collect it | The catalog is curated and can differ between workspaces, so treat the entries in your own console as the authoritative list. The [Agent catalog](/manage-your-agents/build/catalog/overview) 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. | Category | What these agents do | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Investigators** | Gather evidence and produce a root-cause conclusion from a specific system — AWS, Azure, Google Cloud, Datadog, Grafana, Kubernetes, GitHub, and combined cluster investigators | | **Remediators** | Take an investigation and propose or carry out a fix, routed for approval | | **Assistants** | Orchestrators that route a problem to the right specialists in your fleet, and run workflow steps across them | | **Code review** | Review a pull request from its diff and report findings by severity, with file and line | | **Cost optimization** | Scan a connected cloud account for waste and attribute spend | | **Quality** and **Evaluators** | Author and run test scenarios, and grade other agents' runs against a rubric | If you are starting from an alert-driven use case, deploy an investigator for whichever observability system you already trust. It is the entry with the shortest path from deploy to a useful run, because the evidence it needs is already in a system you have connected. ## Deploy one 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. On **Agent card**, set the display name and, if you want, labels. The default name is the catalog entry's. 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. 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. Entries that take a model credential offer a **Model** step. **MCP tools** binds an integration group; **Triggers** adds a cron schedule if the agent should run on its own. 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](/manage-your-agents/build/deploy-an-agent). Credentials are validated as configuration, not as working credentials. A well-formed but wrong API key deploys cleanly and fails on the first run — so read that first run rather than assuming a successful deploy means a working 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. | Change | Possible? | | ------------------------------------------------- | ------------------------------------------------- | | Its instructions, prompt, or model behavior | No — sealed to the deployed version | | Its connections' credentials | Yes — rotate in the credential store, no redeploy | | Pointing it at a *different* connection | Redeploy from the catalog | | Its triggers and schedules | Yes | | Its labels | Yes | | Its permissions and bound secrets | Yes | | Which specialists an orchestrator may delegate to | Yes | | Enable, disable, archive, delete | Yes | If you need behavior an entry does not have, author your own agent instead. See [Build from scratch](/manage-your-agents/build/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. Invoke it manually and read the run before you schedule it. Enable, disable, label, archive, and read its activity. ## Next steps Every catalog agent in depth — what it reads, its limits, and where it stops. Connect what a catalog agent needs before you deploy it. Give it a recurring schedule. Bind specialists to workflow steps instead of running them one at a time. When no catalog entry fits. ## Related topics - [Agent catalog](/manage-your-agents/build/catalog/overview.md) - [Datadog Investigator](/manage-your-agents/build/catalog/datadog-investigator.md) - [AWS Infrastructure Investigator](/manage-your-agents/build/catalog/aws-investigator.md) - [Orchestration](/manage-your-agents/run/orchestration.md) - [How it works](/manage-your-agents/build/how-it-works.md)