How it works

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. An agent is a composition of attachments, each versioned and permissioned on its own, rather than a program you write.

What an agent is made of

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 triggers that start it, and the permissions enforced when it acts. Very little of that is code. Building one is therefore mostly composition. You decide behavior once and attach capability to it, and each attachment is independently versioned, independently permissioned and independently changeable: a skill is published, a credential is rotated, or a revision changes behavior, none of them requiring the others to move. Nothing on the list is mandatory. An agent with instructions and no connections is a valid agent; it cannot see anything outside itself.

Agent versus worker

These are two different things, and the distinction matters the moment something stops working. You build an agent; you deploy a worker. Everything in the console is organized around the agent, and the worker is the thing that reads as online or offline. When an agent will not come up, that table tells you which half to look at. See Architecture for how the two talk to each other.

Where an agent comes from

Add agent opens the agent marketplace. You adopt an entry published against a system you already run, then give it your credentials, your knowledge and your triggers. Agents can also be created through the API or through KAOP’s MCP server, which is what you want when creating an agent is part of your own provisioning rather than something a person does. All three produce an agent the console operates the same way. An agent that already runs on your own infrastructure is connected rather than created — see Import an agent. However it was created, an agent starts as a draft and goes live on its worker’s first contact. There is no separate activation step, which is also why a draft that never leaves draft is a worker problem rather than a configuration one.

Proving it works

Every agent carries two checks on its header without declaring anything, and running them in order localizes a failure instead of describing it. Connectivity failing is deployment, networking, or an agent whose code cannot run at all. Connectivity passing while a real run fails puts the fault in what the check never touches — the model call, the tools, the credentials, or the recording of the run itself. The run’s transcript names which. Three more checks belong before an agent does anything real:

• Its card advertises what you meant to declare. Capabilities, tools, input schema and triggers are what the spec actually declared, which is not always what you intended.
• Its run evidence is complete. Missing spans mean work happening outside the platform’s instrumentation; missing cost means usage is not being reported.
• Its permissions are what you intended, rather than what was convenient while you were developing it.

Next steps