Kelos

The deciding trait is that agents stop being special. A task becomes an object your existing tooling already inspects, keeps in version control and reviews before it runs, so the answer to how you monitor an agent is whatever you already do for everything else. That is a boring solution, and boring is the point.

The obvious cost is the prerequisite. If you do not run a cluster, none of this is available at any price, and standing one up for this reason alone is a decision you will regret. Pick it if the cluster exists. Pick a desktop orchestrator if it does not.

The failure mode is idle compute nobody owns. An interactive session is a running workload by design, and the design does not describe a timeout, an idle reaper or a maximum lifetime. A developer closes a laptop on Friday afternoon and the workload keeps existing until somebody reads the invoice.

That is a cost failure rather than a correctness one, which is why it survives review: nothing is broken, the number is merely larger than expected. What it does right is isolation. Every agent runs in its own workload rather than on a developer's machine, so a bad run damages something disposable.

1. This is the measurement design most harnesses omit. Recording what a run produced on the run's own object means a question such as how many attempts produced a merged change becomes answerable by query rather than by memory, across every task the system has executed since it was installed.

2. Token usage in the same record is the part that matters most, since it lets cost be attributed to an outcome instead of to a month. 3. No benchmark accompanies any of it and none is claimed, which is appropriate: the contribution is bookkeeping, and bookkeeping is verified by reading the schema.

The distribution problem is specific here. Whoever adopts this is a platform team, and platform teams buy from vendors already inside their cluster, which means the competitor is not another project like this one but a feature added to something they renew every year without thinking about it.

Moat: none structurally, though being an ordinary set of cluster objects makes it unusually cheap to try and equally cheap to abandon. Likely acquirer is a delivery-platform vendor that wants agents in its console. Position: adopt at team level, and avoid making it the interface everything else depends on.

This is the shape I keep asking vendors for. There is no new identity system, because access is whatever the cluster already enforces, and no separate audit trail, because the record is the one my team already collects. Sixty engineers cost nothing in licences and the compute is a line I forecast anyway.

The prerequisites are real and manageable: a recent cluster version and a certificate manager, both of which we run. It also executes unattended from a webhook or a schedule, so it becomes a measured delivery step rather than a desktop habit. Approved with conditions: one namespace, quotas set, pilot team owning the budget.

The custom image is the line that decides this for me. Whatever the supported agents happen to be today, the interface takes an image I build, so the thing running in the pod is mine down to the base layer. That is a different kind of extensibility from a plugin API, and a much harder one to take away.

Above that, one configuration object carries instructions, skills, plugins and MCP servers into every run, so servers I already operate arrive with the agent instead of being wired up per task. The licence is permissive and a fork survives whoever wrote it.