What changed in Oran 3.6

Each version of Oran has added one thing. Cost attribution in 3.1, budgets that block in 3.2, evaluation in 3.3, optimisation in 3.4, the Agent Hub in 3.5. Individually useful, and until recently still five things a team had to assemble.

3.6 is the release where they stop being assembled and start being assumed.

Multiple integrations

The largest practical change is reach. An agent that can only act inside one system is a demo of a workflow rather than a participant in it, and most real work crosses three or four systems before it is finished.

3.6 broadens what an agent can be connected to, with the same governance applying at every boundary. A connection is not a permission: an agent granted read access to a repository and no write access cannot push, and that is enforced where the action occurs rather than requested in a prompt.

Situation awareness

Earlier versions executed a plan. 3.6 keeps track of what has already happened within a run and what changed underneath it while the run was in progress.

This matters for the unglamorous failure that wastes the most money: an agent that continues executing a plan built on state that has since moved. Repeating a step that already succeeded, or acting on a record someone else has since changed, produces work that has to be undone by a person. Noticing is cheaper than repairing.

Advanced agent management

The consolidation is most visible here. An agent now arrives with ownership, boundaries, budget and evaluation as properties rather than as separate configuration exercises.

In practice this is what changes the ninety-day pattern we keep writing about. The sprawl that shows up in week four is only a problem when attribution and ownership are retrofitted afterwards. When they are the default shape of an agent, thirty agents is an inventory rather than a mystery.

Cost visibility and control, together

3.1 made spend visible. 3.2 made it stoppable. 3.6 puts both in the same place as the evaluation that determines whether a saving was real.

That combination is the point. Cutting cost without evaluation produces cheaper output of unknown quality, which is not a saving but a deferral. The Optimizer proposes model, prompt and tool changes, and every proposal is scored against your own evals before it stands.

What it does not do

It does not merge your code, approve your spend or decide that a failed check is acceptable. Actions with real consequence still pause for a person, and we consider that a design choice rather than a gap to close in 3.7.

It also does not make an ungoverned deployment governed. The version you run matters much less than whether agents have owners, boundaries, budgets and criteria. A team with those four on an older version is in better shape than a team without them on this one.

Upgrading

Existing deployments move without rebuilding agents. Where data cannot leave your infrastructure, 3.6 runs self-hosted, in your own cloud or fully air-gapped, with the same governance.

Next

The versions page lists every version from Keter 1.0 onward and what each added. The Agent Orchestration System pages cover the operating layer this release consolidates.