> ## 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. # Fleet > Read the whole agent fleet at a glance — what it is made of, where it runs, and which agents are the outliers. **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](https://docs.komodor.com/manage-your-agents/build/how-it-works.md) 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](https://docs.komodor.com/manage-your-agents/fleet/agent-page.md#disabling-an-agent) 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. > [!NOTE] > > "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](https://docs.komodor.com/manage-your-agents/fleet/agent-page.md). | | **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. | > [!WARNING] > > 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. | > [!TIP] > > `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**. ## Next steps > [card] [The agent page](https://docs.komodor.com/manage-your-agents/fleet/agent-page.md) > > One agent in full — its revisions, its costs, and what changed. > [card] [Runs & evidence](https://docs.komodor.com/manage-your-agents/run/runs-evidence.md) > > What a single run records, and how to read it. ## Related topics - [The agent page](https://docs.komodor.com/manage-your-agents/fleet/agent-page.md) - [Insights](https://docs.komodor.com/manage-your-agents/optimize/insights.md) - [Optimize — how it works](https://docs.komodor.com/manage-your-agents/optimize/how-it-works.md) - [Troubleshooting](https://docs.komodor.com/reference/troubleshooting.md) - [How Run works](https://docs.komodor.com/manage-your-agents/run/how-it-works.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.