The agent page

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 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: 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 for how a shadow is read.

​

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.

​

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?

​

The agent’s other tabs

​

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 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 for what each of the two checks establishes.

​

Next steps