What “building an agent” means here
An agent is not a script you deploy and forget. In KAOP an agent is a governed identity and behavior: its instructions, the tools it may call, the credentials it may resolve, the knowledge it may read, the schedules that start it, and the permissions enforced when it acts. Building one is therefore mostly composition. You define behavior once, then attach capability to it: Nothing on that list is mandatory. An agent with instructions and no connections is a valid agent — it just cannot see anything outside itself.Agent versus worker
These are two different things, and the distinction matters as soon as you start debugging.
You build an agent. You deploy a worker. Everything in the console — runs, evidence, spend,
permissions — is organized around the agent; the worker is the thing that shows as online or
offline. See Architecture for how the two talk to each other.
The two paths in
Author your own
You write the instructions, the tools, and the handler with the SDK. Use this when the work is
specific to your systems and your runbooks.
Use one of ours
Deploy a Komodor-built specialized agent from the catalog as-is. Use this when the work is a
common operations problem someone has already solved.
Two ways to reach anything external
This is the single most useful thing to internalize before you connect anything: an agent reaches an external system either through a built-in integration from the catalog, or through the MCP Gateway for your own tools. There is no third path, and both use the same credential store underneath. Integrations overview explains how to choose.Everything in this section
Build from scratch
Author an agent with the SDK — instructions, tools, and the handler that does the work.
Use specialized agents
Browse the catalog and deploy a Komodor-built agent without writing code.
Integrations overview
The two connection paths, and which one your case calls for.
Built-in integrations
The catalog of ready-made connections, and how to connect and test one.
Integration groups
Bundle connections into a named set and attach the set to an agent.
MCP Gateway
Expose your own tools through an MCP server or an OpenAPI surface.
Credentials & secrets
Store a secret once, bind it to the agents allowed to use it, deliver it without exposing it.
Skills
Package your runbooks as reusable know-how any agent can load.
Knowledge base
Give agents your documentation and past incidents as a cited source.
Triggers & schedules
Start runs on a recurring cron schedule.
Deploy an agent
How an agent becomes a running worker, and what first registration looks like.
Manage a deployed agent
Enable, disable, edit, archive, and read the activity of a live agent.
A sensible order
1
Get one agent running
Deploy a catalog agent, or author the smallest possible agent and start its worker. Confirm it
registers and shows as online.
2
Connect what it needs to see
Add the built-in integrations for the systems it must read, or register your own tools through
the MCP Gateway.
3
Give it your knowledge
Attach the skills that encode your procedures, and point it at the knowledge base.
4
Decide what starts it
Add a cron trigger for recurring work, or leave it to be invoked from chat, a workflow step, or
a module.
5
Read a run
Open the run and check the evidence trail — what it called, what it concluded, what it cost.
Next steps
Concepts & glossary
The vocabulary this section assumes.
Run — how it works
What happens once an agent is built and something starts it.