> ## 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.
# How it works
> What building an agent involves in KAOP — the two authoring paths, and everything you attach to an agent before it runs.
Building an agent in the Komodor Agentic Operation Platform (KAOP) means deciding what it should do,
what it may reach, and what starts it — then letting the platform run it as a governed worker. This
page orients the Build stage: the difference between an agent and the worker that runs it, the two
paths for getting an agent in the first place, and each thing you attach along the way.
## 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:
```mermaid theme={null}
flowchart TB
A["Agent
instructions · tools · handler"]
A --> C["Connections
built-in integrations or MCP Gateway"]
A --> S["Skills
reusable know-how"]
A --> U["Use cases
typed actions others call"]
A --> K["Knowledge base
documents and past incidents"]
A --> T["Triggers
cron schedules"]
A --> D["Deploy"]
D --> W["Worker
the running process"]
```
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.
| | **Agent** | **Worker** |
| ------------------- | --------------------------------------------- | ------------------------------------------------------- |
| What it is | The governed identity and behavior | The process that runs it |
| Where it lives | The control plane's agent registry | Wherever you run it, or on Komodor's infrastructure |
| What you do with it | Author it, attach capability, grant it access | Start it, watch it register, check whether it is online |
| Cardinality | One agent | One worker per agent |
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](/get-started/architecture) for how the two talk to each other.
## The two paths in
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.
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.
The paths converge immediately after. However an agent arrived, it gets connections, skills,
knowledge, and triggers the same way, and it is managed from the same place.
Start with a catalog agent even if you intend to author your own. It gets you a working run and a
real evidence trail in minutes, which makes the rest of this section concrete rather than abstract.
## 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](/manage-your-agents/build/integrations-overview) explains how to choose.
## Everything in this section
Author an agent with the SDK — instructions, tools, and the handler that does the work.
Browse the catalog and deploy a Komodor-built agent without writing code.
The two connection paths, and which one your case calls for.
The catalog of ready-made connections, and how to connect and test one.
Bundle connections into a named set and attach the set to an agent.
Expose your own tools through an MCP server or an OpenAPI surface.
Store a secret once, bind it to the agents allowed to use it, deliver it without exposing it.
Package your runbooks as reusable know-how any agent can load.
Give agents your documentation and past incidents as a cited source.
Start runs on a recurring cron schedule.
How an agent becomes a running worker, and what first registration looks like.
Enable, disable, edit, archive, and read the activity of a live agent.
## A sensible order
Deploy a catalog agent, or author the smallest possible agent and start its worker. Confirm it
registers and shows as online.
Add the built-in integrations for the systems it must read, or register your own tools through
the MCP Gateway.
Attach the skills that encode your procedures, and point it at the knowledge base.
Add a cron trigger for recurring work, or leave it to be invoked from chat, a workflow step, or
a module.
Open the run and check the evidence trail — what it called, what it concluded, what it cost.
## Next steps
The vocabulary this section assumes.
What happens once an agent is built and something starts it.
## Related topics
- [How it works](/security-and-governance/how-it-works.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)
- [Architecture](/get-started/architecture.md)
- [Orchestration](/manage-your-agents/run/orchestration.md)
- [Grafana Investigator](/manage-your-agents/build/catalog/grafana-investigator.md)