Skip to content
All writing
Governance27 May 20267 min

Autonomy is a dial, not a switch

The question is never whether to let software decide. It is which classes of decision, under what evidence, with what recourse when it is wrong.

David SakCo-founder

Every conversation about autonomous operations eventually arrives at the same badly-framed question: do you trust the system to decide? Framed that way it has no good answer. Nobody trusts a system in general. People trust a system to do specific things, within bounds, with a way to catch it when it fails.

Decision classes, not decision volume

The useful unit is the decision class. Approving a purchase order under a threshold from an approved supplier with a matching receipt is a class. Approving an exception to a payment term is a different class, with different evidence and different consequences for being wrong. Lumping them together as 'procurement decisions' guarantees you will either over-delegate or under-delegate, and usually both at once.

Once decisions are classified, autonomy becomes a per-class setting rather than an organisational posture. Most companies end up with a long tail of classes running fully autonomously and a short head of consequential ones that always see a human. That distribution is healthy. It is also invisible if you never did the classification.

Start closed

The deployment pattern that works: gate everything, then open selectively. For the first weeks Cortexia proposes and a human disposes. Every proposal is logged with its evidence and the policy it applied. What you are building in that period is not training data but an evidence base about the system's judgment, in your context, on your decisions.

After a few hundred decisions in a class, the question stops being philosophical. You can see the disagreement rate. You can read the cases where the human overrode it and ask whether the override was right. Releasing autonomy on that basis is an operational decision with numbers behind it.

Recourse matters more than accuracy

A system that is right 99% of the time with no way to catch the 1% is worse than one that is right 95% of the time with fast, complete rollback. This is not intuitive to people who come at it from a model-evaluation background, where accuracy is the whole game.

In operations, the cost of an error is dominated by how long it takes to notice and how hard it is to unwind. That is why every action carries a reversal path, and why the audit trail is immutable rather than merely thorough. You are not trying to eliminate error. You are trying to make error cheap.

The gate is a feature

There is a temptation to treat approval gates as friction to be engineered away. They are not. A gate is the mechanism by which a company retains the ability to say no, and the moment it becomes a rubber stamp is the moment the whole structure is decorative. Gates should be few, real, and slow enough that someone actually reads them.

Get started

Give your company something to think with

Connect a few systems, watch it reason for a fortnight, and decide for yourself what it should be trusted to run.