Fleet

Fleet lists every agent in a Komodor Agentic Operation Platform (KAOP) account with its presence, its model, its cluster and its last 30 days of runs, spend, errors and latency. Presence is read from when the worker was last seen, so an agent reads as online when its process is reachable, not when its answers are right.

The three summary cards

Three summary cards sit above the list, and they describe the fleet rather than any agent in it.

Card	What it tells you
Where it runs	The split across hosting — your own Kubernetes clusters, a managed provider, Komodor’s cloud. When a whole class of agents goes quiet at once, this is where the shape of the outage shows.
Inference	Which inference providers the fleet’s runs actually reached in the window.
Model breakdown	Which models the fleet used, by share of runs. Read beside spend, this is where the agent still on an expensive model it does not need becomes visible.

Hosting does not determine inference: an agent on Komodor’s cloud can call your own provider, and an agent in your cluster can call Komodor’s. The three are independent, so a shift in one is not explained by the other two.

How presence is determined

The control plane pings each worker over its own outbound connection, and the worker’s answer refreshes its presence; other traffic the worker sends refreshes it too. Online, Offline and Draft follow from that: an agent never yet seen is a draft, one seen inside the presence window is online, and one that stops answering reads as offline. Deploying, Deploy failed and Unhealthy come from the deploy and the worker’s process instead. The list carries how long ago each agent was last seen, so presence always comes with its evidence. The status column is therefore a statement about a reachable process, not about correctness. An agent can be present and answering every run wrongly.

Status	What it means
Online	The worker answered inside the presence window.
Offline	It stopped answering. The agent still exists, its history is intact, and it returns on the next answer.
Draft	It has never been seen. See How it works for how a draft goes live.
Deploying · Deploy failed	A first deploy is in flight, or did not complete.
Unhealthy	The worker’s process is failing to start or stay up. The cell carries the reason the cluster gave — CrashLoopBackOff, ImagePullBackOff — rather than the word “unhealthy”.

Qualifiers sit beside the status because they are independent of presence. Disabled means the agent’s triggers will not fire; see The agent page for what a disabled agent can still do. Archiving and Archived cover retirement. A rollout on an already-live agent keeps the status at Online and shows what is happening in the badge, because the previous revision is still answering.

“Offline” and “unreachable” are different facts. Offline means nothing has been heard from the worker inside the presence window. A worker whose message channel is not reachable can still read as online, because its other traffic refreshes presence too — and the fix for each is different.

What the list adds

Each row answers a question the cards cannot: which agent is the outlier. The columns below are the ones that carry a judgement; the row also shows the agent’s actions.

Column	What it tells you
Model	Which model the agent currently runs on.
Cluster	Where its worker runs. The cell names the host and the cluster, so two agents on the same provider in different regions are distinguishable.
Main revision	Which revision is answering right now. An agent whose definition you own holds several at once, and only one serves requests that do not name a revision; an agent adopted from the marketplace shows the version it was adopted at. See The agent page.
Last run	When it last did anything, and whether that run succeeded, failed or is still running.
Activity (30d)	Runs, spend, error rate and mean latency for the last 30 days, in one cell.

An em dash in an activity cell means not measured, which is not the same as zero. An agent that has only just been created has no measurement yet, and reading one as the other produces the wrong conclusion about a healthy agent.

Narrowing the list

Status and shadow facets are platform-derived. The remaining facet groups come from the labels your own agents declare, so nobody configures them and they differ from account to account. An account that labels its agents fully tends to show facets like these.

Facet	Narrows by
`Category` · `Role`	What kind of work the agent does.
`Cluster`	Which cluster its worker runs in.
`Harness`	Which runtime executes it — the SDK and process shape its worker was built with.
`Inference` · `Provider`	Which model service it reaches, and through whom.
`Lifecycle`	How far along it is, from first draft to retired.
`Owner` · `Team`	Who to talk to when it misbehaves.
`Pipeline`	Which delivery path deployed it, for accounts that deploy agents through more than one.

Owner and Team are derived from what agents declare, so an account where they are thin has agents that do not declare them. The fix is in the agents.

Search is broader than the facets: it matches an agent’s name, id, worker id, description, tools and labels, so a half-remembered tool name finds the agents that use it. Beside the agent list, Fleet carries tabs for fleet-wide Analytics, the account’s Schedules, and Budgets.

Build

Run

Optimize

The three summary cards

How presence is determined

What the list adds

Narrowing the list

Next steps

The agent page

Runs & evidence

​The three summary cards

​How presence is determined

​What the list adds

​Narrowing the list

​Next steps

The agent page

Runs & evidence

The three summary cards

How presence is determined

What the list adds

Narrowing the list

Next steps