> ## 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.

# The agent page

> One agent in full — which revision is answering, what the others proved, what it costs, and who changed it.

An agent whose definition you own in the Komodor Agentic Operation Platform (KAOP) is a **line of
revisions**: several versions of its behavior exist at once, one of them answers requests, and the
others are being measured against it or have already been judged. Its page is organized around
that line — what is answering now, what each revision proved, and what the whole thing costs. An
agent adopted from the [marketplace](https://docs.komodor.com/manage-your-agents/build/agent-marketplace.md) carries its
behavior from the published image instead, so the revision surfaces below do not apply to it.

The header states where the line currently stands — its status and when it was last seen, and over
the last 30 days its runs, its latency at p50 and p95, its evaluation score and its spend, plus
the model and inference provider behind it.

## A revision carries a stated hypothesis

Each revision carries a plain-language statement of the change it makes, so the list stays
readable months later — "use a smaller model for evidence summarization without changing the final
diagnosis" says more than a version bump ever will.

Each revision holds three facts:

| Fact | Values | Means |
| - | - | - |
| **Label** | Open · Approved · Discarded | What you concluded about it — and, for Approved, what you did. Approving a revision promotes it: it becomes main and starts answering requests that do not name a revision. There is no separate promote step. An open revision is still being measured; a discarded revision keeps its record and its reason. |
| **Status** | Running · Offline | Whether it is loaded at all. Independent of the label — an approved revision can be offline. |
| **Main** and **Shadow** | On, off, or shadowing another revision | What traffic it gets. |

Exactly one revision is **main**: the revision that answers when a request does not name one.
Requests can name a revision, and everything else lands here. Main follows from approving a
revision; a running revision can also be made main directly, without approving it, from the
revision list.

## Shadowing a revision

Shadowing is available while a revision is still **open** — before it is approved or discarded. A
shadowed revision receives a copy of live traffic while the main revision still answers, and its
output is recorded without reaching anyone, which measures it on real inputs at no risk to the
people sending them.

Shadowing is a reversible toggle: turn it on to start collecting, off to stop. Nothing a shadow
produces reaches a caller, so it can be left running while you gather enough runs to judge, and
turned off without unwinding anything. See [Model
Evaluation](https://docs.komodor.com/manage-your-agents/optimize/model-evaluation.md) for how a shadow is read.

> [!NOTE]
>
> Create a revision with a stated hypothesis, shadow it, read what it did differently, then approve
> it — which promotes it to main — or discard it with the reason attached. Either ends the shadow
> for good.

## Routing traffic between revisions

Which revision answers a given run is decided by **rules**, not by a percentage. A rule matches on
the run's own attributes — its environment, the kind of action, its severity — and serves the
matched traffic to a named revision.

Four things govern how a rule resolves, and all four are stated on the routing panel itself:

* **The first matching rule applies.** Order is meaningful.
* **An empty include matches all traffic**, so a rule with no condition is a catch-all.
* **Exclude wins on overlap.** A run matching both a rule's include and its exclude is not served by
  that rule — which is how you keep writes, or SEV-1s, away from a revision you are still testing.
* **Anything unmatched goes to main.** The main entry is not editable; it is where traffic lands
  when no rule claims it.

Separately, **if main is offline**, its traffic is served from the latest online revision and those
runs are labelled **Fallback**, so a run answered by a stand-in is distinguishable afterwards.

> [!NOTE]
>
> Routing and shadowing answer different questions. A rule decides who answers a request for real; a
> shadow copies requests to a revision whose answers reach nobody. A revision can be excluded from
> production traffic by rule while still being shadowed on it.

## What the audit log records

Every step above is written down: who created a revision and what they said it would change, who
approved or discarded it and why, and every shadow turned on or off. The platform appears in the
log as an actor in its own right, not only the people using it.

"Why does this agent behave differently than last month" is answered by reading the log, in the
words of whoever made each change.

## Where the time and the money go

Observability breaks a run down by the step of the agent's loop that produced it, so a slow or
expensive agent can be localized rather than only observed. Above the detail sit the headline
figures — calls, tokens in and out, cache reuse, cost per run, latency at p50 and p95, and tool
calls per run — and beneath them the question those figures raise: which part of the loop is
responsible?

> [!TIP]
>
> Low cache reuse on an agent whose prompt barely changes between runs often means something
> volatile — a timestamp, a run id, a reordered tool list — sits in front of the stable part of its
> context. Check the start of the prompt before changing the model.

| View | What it isolates |
| - | - |
| **Where a run spends its time** | The split across model calls, MCP tool calls, other tool calls and the agent's own overhead — plus **Not measured**, time no span covers. Overhead is the agent's behaviour and you can act on it; Not measured is instrumentation failing, and you cannot. A run that recorded no spans reads 100% Not measured, not 100% overhead. |
| **Tool calls by tool** | Per tool: calls, failures, unfinished calls, latency at p50 and p95, and the five slowest calls. |

## The agent's other tabs

| Tab | The question it answers |
| - | - |
| **Overview** | What this agent is for, what it is connected to, and which workflows it serves. |
| **Details** | Its declared metadata — category, provider, inference, cluster. |
| **Run history** | What it has actually done, opening into the account-wide [run list](https://docs.komodor.com/manage-your-agents/run/runs-evidence.md) filtered to this agent. |
| **Triggers** | Everything configured on the agent that starts it. See [Triggers](https://docs.komodor.com/manage-your-agents/build/triggers.md). |
| **Datasets & Golden scenarios** | The cases it is tested against, and how it scored on each run. |
| **Budget & Limits** | Three independent ceilings — spend, run duration and rate — each showing its current state and how many policies are in force. |

## What an agent may actually do

The permissions view resolves assigned roles and the policies behind them into **effective
capabilities** — permissions, not the published capabilities a marketplace entry advertises. Each
one names the permission, the specific resource it applies to, how it was granted and which role
it came from. A capability scoped to one integration or one pattern of tool calls reads as exactly
that, rather than as a role name you would have to go and interpret.

Two things that are easy to look for elsewhere live here as well. **Used secrets** lists the
credentials this agent may resolve at run time — see [Credentials &
secrets](https://docs.komodor.com/security-and-governance/identity-and-access/credentials-secrets.md) for how one reaches a
run. And the **worker token**, the credential a deployed worker presents to authenticate as this
agent, is rotated and revoked here, with its creation, last rotation and expiry on the record.

## Disabling an agent

**Disable** stops every trigger from firing, chat included. **Run agent** from the console and a
direct API call are manual invocation and keep working, so a disabled agent can be invoked by hand
and tested while nothing starts it on its own. Disabling is therefore the right response to an
agent behaving badly: archiving it would lose the ability to reproduce the problem.

Disabling is reversible and keeps every record. Archiving retires the agent while keeping its runs
and evidence readable.

Beside those, the header offers **Create revision**, **Check connectivity** and **Run agent** —
see [Proving it works](https://docs.komodor.com/manage-your-agents/build/how-it-works.md#proving-it-works) for what each of
the two checks establishes.

## Next steps

> [card] [Fleet](https://docs.komodor.com/manage-your-agents/fleet/overview.md)
>
> The same picture across every agent at once.

> [card] [Triggers](https://docs.komodor.com/manage-your-agents/build/triggers.md)
>
> The four kinds of trigger.


## Related topics

- [Agent marketplace](https://docs.komodor.com/manage-your-agents/build/agent-marketplace.md)
- [Triggers](https://docs.komodor.com/manage-your-agents/build/triggers.md)
- [How it works](https://docs.komodor.com/manage-your-agents/build/how-it-works.md)
- [Fleet](https://docs.komodor.com/manage-your-agents/fleet/overview.md)
- [Knowledge base](https://docs.komodor.com/manage-your-agents/build/knowledge-base.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.