Oran in the wild, and what surprised us

A release note describes what a version does. It is less common to describe what happened next, partly because the answer is often mildly embarrassing.

Here are three things we got wrong.

We expected cost attribution to be used for cost

Oran 3.1 attributed spend per agent because teams could not answer what anything cost. That was correct, and the use was not what we expected.

The first thing most teams did with per-agent attribution was not reduce spend. It was find agents nobody knew were running. Attribution turned out to be an inventory tool before it was a financial one, because a cost line with no recognised owner is the clearest possible signal that something has been forgotten.

That reframed how we thought about ownership, and it is a large part of why 3.6 treats ownership as a property of an agent rather than a convention.

We expected budgets to be set generously

We built circuit-breaker budgets in 3.2 assuming teams would set a ceiling well above expected usage, as a safety net against runaway behaviour.

Many set them deliberately tight instead, close to expected usage, and used the block as a signal rather than a protection. When an agent hit its limit, that was information: something changed, look at it.

We had built a guard rail and teams were using it as a smoke detector. It works, and it is not what the feature was for.

We expected evals to be written before deployment

Oran 3.3 assumed criteria would be defined up front, which is what we would recommend and what almost nobody does.

In practice most teams wrote their first eval after an agent produced something wrong, working backwards from the failure. The criteria that resulted were narrower than a designed set and frequently more useful, because they encoded a real failure rather than an imagined one.

We stopped treating this as teams doing it incorrectly. A set that grows from actual failures converges on something good, and it has the advantage of existing.

What did hold

The read-write asymmetry. Teams grant agents broad read access and narrow write access, consistently, across every sector we work in. Building the policy layer around that assumption was right.

The value of a shared catalogue. Duplication across teams was as large as we expected and the Agent Hub addressed it as expected, which is the least surprising item on this list.

Why we publish the misses

Because a platform built only on what its makers expected drifts away from what its users do. The three surprises above each changed something in 3.6, and none of them would have surfaced from a roadmap.

If your deployment is doing something with Oran that we clearly did not design for, we would like to hear about it. That is genuinely the most useful thing we receive.

Next

The versions page covers every version from Keter 1.0 onward. The Open Development Community is free to join, and observations can go to contact@capconsultor.eu.