Most teams meet the idea of an agentic operating system the same way. They build one agent, then a second, and somewhere around the third they notice they have rebuilt the same things each time: who the agent is, what it may touch, what it may do there, who checks it, and where the record goes. An operating system is what you get when those things stop being rebuilt per agent and become a layer every agent runs on.

The model is not that layer. A model is the part that reasons and writes. It has no idea whether the person asking is allowed to move this money, whether the source it is reading is one your compliance team approved, or whether the action it is about to take can be undone. Asking the model to hold those limits is asking the most capable and least predictable component in the system to also be its own supervisor.

What the operating system has to do

We count seven jobs. A layer that does fewer is a framework; one that does all seven is an operating system.

• Identity and role. Every agent has a role, and the role sets a ceiling no customer setting can raise. A Sales agent can propose; it cannot move money, whoever asks.
• Capability at a depth. What an agent may do is listed per capability, as a verb against an entity at a depth: reading is depth 1, drafting depth 2, executing depth 3, and anything that moves money is depth 4.
• Certification. Depth is earned against scored cases, certified per agent, and it lapses. An agent that has not been re-certified drops to depth 1 on its own.
• Context. The agent reads only the sources its role and your settings allow, and every answer cites which one.
• Enforcement. At the moment of action, five bounds apply at once and the smallest wins: role scope, certificate, sources, your limits and the guardrails in force.
• Human gates. Anything one depth above the effective depth is held for a named person, with the draft and the reason attached; anything further is refused, with the bound named.
• The record. Every decision is filed, including the refusals, with the bound that produced it.

A worked case

An invoice for $4.2m arrives in the Finance agent’s queue. The agent reads the invoice, matches it to the purchase order and drafts the payment. That is depth 2 work and it is certified for it.

Paying it is a different action. Moving money is depth 4, and $4.2m is far above the working ceiling this customer set, where an agent may only draft. The operating system reads all five bounds, finds the guardrail is the binding one, and refuses the payment to the agent: a person pays it, from the agent’s draft, the match and the policy clause. The ledger records the refusal and names the bound that refused it.

Nothing in that sequence depended on the model behaving well. It depended on the layer around it.

How it maps to Pryme Intelligence

Agent Studio is where agents are built or chosen, inside the roles we publish. Attest is where depth is earned and expires. The Pryme Context Protocol stamps every fact with where it came from, and so what it can authorise. The Workspace is where the agents run and where people answer what is held. The ledger underneath records every verdict. Each is useful alone; together they are what we mean by a governed agentic operating system.

What it costs

An agent on a governed operating system starts narrow. It earns depth over weeks, not on the day it is switched on, and some of what a demo agent does at once ours will hold for a person. We think that is the right trade for any business that has to explain its decisions to a customer, an auditor or a regulator, and the wrong one for a team that only needs a clever prototype.

Signs you need an operating system, not another agent

None of these is a reason on its own. Three or more usually are.

• Each agent has its own permission model. One reads a config file, another a database table, a third a paragraph in its prompt. Nobody can answer what all of them may do without opening each one.
• Refusals are invisible. You can see what your agents did, but not what they declined to do or why. Those are the entries an auditor asks for first.
• Authority never expires. An agent approved in March is still trusted in November on the same evidence, although its sources, your policies and the model underneath have all changed.
• People approve everything or nothing. Either every action waits for a person, and the queue becomes the bottleneck, or nothing does, and the risk team has stopped asking.
• Adding a system means rebuilding an agent. Moving from one accounting package to another, or adding a second payment provider, sends you back to testing the whole agent rather than one connector.

What to ask any vendor

These questions separate an operating system from a framework with a dashboard. Ask for the answer to be shown on a live agent, not described.

• Where is the limit on this action stated, and what reads it at the moment the action happens?
• When the agent refuses, which rule refused, and where is that recorded?
• How does an agent earn the right to do more, and what makes that right lapse?
• If a source the agent relies on is disconnected or changes, what happens to its authority?
• Which actions can no agent take at any level, and who decided that?
• Can a person outside your company, such as an auditor, check the record without your help?

What it is not

An agentic operating system is not a model, a prompt library or a workflow builder, although it works alongside all three. It does not make agents smarter. It makes what they do bounded, attributable and explainable, which is the property a regulated business needs before cleverness matters at all.

Questions people ask