> ## 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. # Agent marketplace > Adopt a published agent built against a system you already run — what each does, what starts it, and what it produces. **Add agent** in the Komodor Agentic Operation Platform (KAOP) opens a catalog of agents published against products you already operate — PagerDuty, Datadog, GitHub, AWS and others. An entry arrives with its behavior sealed to a validated version, and takes your credentials, triggers and permissions. What each Komodor-built entry reads, its limits and where it stops are documented in the [Agent catalog](https://docs.komodor.com/manage-your-agents/build/catalog/overview). ## Every entry publishes named capabilities A marketplace entry belongs to a product and knows that product's objects, its API and its failure modes. Each entry publishes **named capabilities** rather than a description of what it might do. A capability is a specific nameable job: investigation, alert dedup, support intake, an ops report, change correlation. An entry commonly publishes several, and the list is the full statement of its scope — if the job you want is not on it, that entry does not do it. Capability is also how two entries are compared across vendors. Two agents that both publish *investigation* do the same kind of work against different systems, which turns the choice into a question you can answer: which system holds the evidence for the problems you get? ## What a card tells you Every card carries the same four sections, so comparing two entries means reading the same fields twice rather than interpreting two different write-ups. | Section | What it answers | | - | - | | **Overview** | What this agent is, in a paragraph. | | **What it does** | The work itself — what it reads, and what it reasons about. | | **Trigger** | What starts it. Often the fastest way to tell whether it fits your operation at all. | | **Outcome** | What you get when it finishes — a conclusion, a ticket, a report, a proposed change. | Each entry carries a release badge — **Ready**, **Beta** or **Design partner** — which describes the entry, not your account. Whether your account has what the entry needs is settled in the deploy wizard, one credential at a time. ## The catalog is organized by problem Entries are grouped by the operational problem they solve rather than by the vendor that published them, so several products offering the same job against different systems appear together. | Category | What these agents are for | | - | - | | **Incident triage** · **Incident grouping** | Deciding what an alert is, and which alerts are the same problem. | | **Investigation & RCA** | Gathering evidence and producing a cause. | | **Post mortem** | Turning a closed incident into a written record. | | **Ticket management** · **Support intake** | Moving work between the tools people actually track it in. | | **Release & CI/CD** | Watching what a deploy did. | | **Ops reporting** | Producing the recurring summary somebody writes by hand today. | | **Kubernetes operations** | Cluster-level work. | | **Cloud cost** · **FinOps** | Finding waste, and attributing spend. | > [!TIP] > > For an alert-driven use case, adopt an investigator for whichever observability system you already > trust. The evidence it needs is already in a system you have connected, so it reaches a useful run > without further setup. ## What stays yours after adoption A published agent arrives with its **behavior validated at the version you adopted** — its instructions and its reasoning come from the published image rather than from you. Moving to a newer published version is an adoption rather than an edit, so an entry behaves the same in your account as in the vendor's. What remains yours is everything around the behavior: the credentials behind its connections, its triggers, its labels, its permissions and the secrets it may resolve at run time, and — for an orchestrator — which specialists it may delegate to. A delegation list behaves as an allowlist: left empty, the orchestrator may use any agent that is online; once you select some, anything left out is refused on every run. > [!WARNING] > > Credentials are validated as configuration, not as working credentials. A well-formed but wrong > API key adopts cleanly and fails on the first run, so read that first run rather than treating a > successful adoption as a working agent. If you need behavior no entry has, an agent you run yourself can be connected to KAOP and governed the same way — see [Import an agent](https://docs.komodor.com/manage-your-agents/build/import-an-agent.md). The two mix: a published investigator does the reading, and an agent of yours does the part specific to your systems. An entry you host yourself moves to a newer published version through its Helm release — see [Upgrade a self-hosted agent](https://docs.komodor.com/manage-your-agents/build/upgrade-a-self-hosted-agent.md). An entry running on Komodor cloud is replaced by adopting the newer version, because its behavior is sealed to the one you adopted. ## Next steps > [card] [Connections](https://docs.komodor.com/manage-your-agents/build/connections) > > Connect what an entry needs before you adopt it. > [card] [The agent page](https://docs.komodor.com/manage-your-agents/fleet/agent-page.md) > > Where an adopted agent is operated from. ## Related topics - [Agent catalog](https://docs.komodor.com/manage-your-agents/build/catalog/overview.md) - [How it works](https://docs.komodor.com/manage-your-agents/build/how-it-works.md) - [Upgrade a self-hosted agent](https://docs.komodor.com/manage-your-agents/build/upgrade-a-self-hosted-agent.md) - [Alert Intelligence](https://docs.komodor.com/modules-and-workflows/sre/alert-hygiene.md) - [Incident management & troubleshooting](https://docs.komodor.com/modules-and-workflows/sre/incidents.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.