PrymeIntelligence
Sign in Start Free
Home/Ideas/The minimum chain, explained
Ideas · Agent governance · 21 Aug 2026

The minimum chain, explained.

Five bounds apply to every agent action at once. The effective authority is the smallest of them, and being able to name which one was smallest is most of what governance is for.

Here is the whole of it:

effective = min(role scope, certificate, sources, ceiling, guardrails)

It is deliberately arithmetic rather than a rules engine, and the choice is not aesthetic. A policy engine can express anything, which means that when it produces a surprising answer you have to read the policy to find out why. A minimum over five named values can only produce one kind of surprise, and the system always knows which value caused it.

What each link is

Role scope. Declared when the blueprint is published, not when the customer configures it. It names classes of connector — never vendors — as permitted, on request, or never. An accountant role never permits a consumer messaging class, which is a statement about the role, not about the customer’s judgement.

Certificate. The depth this agent has earned for this capability, with an expiry. Lapsed evidence drops it to 1 without anybody intervening.

Sources. What it can currently read. An agent whose pricing source disconnected has genuinely lost a capability, and the honest rendering of that is a lower depth rather than an error at execution.

Ceiling. The customer’s own maximum, set per capability. The only link they control directly, and the only one that can be lowered without evidence.

Guardrails. Everything categorical — amount caps, sector floors, refusals that no depth clears.

Why a minimum

Three properties fall out of it that we have not managed to get any other way.

Every refusal is attributable. Exactly one link is binding at any moment. The agent can say which, and the answer is a different conversation each time: raise a ceiling, wait for a re-certification, connect a source, or accept that the role never permits it.

Nothing can widen by accident. Adding a bound can only narrow the result. A new guardrail cannot raise anyone’s authority, which means the safe operation is also the cheap one.

Degradation is automatic. Because each link is read at execution rather than compiled into a permission set, a lapse anywhere shows up as a narrower agent on the next request rather than as an incident.

When nothing decided, show that nothing decided. Our first build always highlighted a binding link, which quietly invented a constraint on every allowed action.

A bug that turned into a principle

The uneventful case

Most of the time all five links read the same value and nothing binds. That case has to render as plainly as the refusals do — five bounds at depth 3, none highlighted, action allowed — because a governance surface that only lights up for exceptions looks switched off for most of the working day.

What it does not do

The chain decides authority. It does not decide correctness. An agent can be fully permitted and still wrong, which is what evaluation, review and the audit trail are for. Conflating the two is how a governance layer ends up being blamed for a quality problem it was never positioned to see.