Between your agents and your business systems, in the path of every action. Agents and their models sit on one side; ledgers, core systems, CRMs and other systems of record sit on the other. Every proposed action passes through it to be checked and filed before it goes through. How you place that checkpoint is a design choice with trade-offs.
What sits on each side?
Above the operating system: the models, the agents built on them, any orchestration that sequences their work, and the channels that bring work in, such as queues, inboxes and chat. Below it: the systems that hold your records and carry out actions, usually reached through APIs or an API gateway.
Alongside it sit two things it relies on. Your identity provider, which issues identities to agents and people. And your data sources, which feed facts to agents, each stamped with where it came from. That stamping is covered in how an agentic operating system knows where a fact came from.
What are the ways to place it?
| Placement | How it works | Trade-offs |
|---|---|---|
| Inline proxy | Agents' tool calls go to the operating system, which forwards allowed calls to systems | Strongest guarantee that nothing bypasses it; adds a network hop; must be highly available |
| Runtime hook | The agent runtime calls the operating system for a verdict before each tool call, then calls the system itself | Less latency; relies on every runtime calling the hook, so credentials must be held so that unchecked calls fail |
| Gateway integration | The API gateway in front of your systems asks the operating system for a verdict on agent traffic | Reuses existing infrastructure; the gateway must pass enough context for a business decision |
| Combination | Inline for actions that write; hooks for reads | Balances cost and assurance; more to configure |
Whatever the placement, one rule holds: an agent must not be able to reach a system of record without a verdict. The simplest way to guarantee that is for the operating system, not the agent, to hold the credentials the systems accept.
The operating system is not a replacement for your systems of record, which stay authoritative. It is not an AI gateway, which manages model traffic rather than business actions. It is not an orchestration layer, which sequences work but does not decide whether each step is allowed. Keeping those roles distinct is what keeps the architecture clear.
What does this look like in practice?
Take an insurer with a policy administration system, a claims system and a payments platform, all behind an API gateway. It runs claims agents on two agent platforms and uses a model provider through an AI gateway.
The insurer places the operating system inline for every agent call that writes to the claims or payments systems, and uses a runtime hook for read-only lookups. The operating system holds the credentials the API gateway accepts for agent traffic, so an agent that tries to call the claims system directly is rejected at the gateway. Every write produces a verdict filed in the record; how an agentic operating system records decisions describes what each contains. Held items appear in the claims handlers' existing work queue.
The AI gateway, the agent platforms and the systems of record are all unchanged.
What stays with people in the architecture?
People sit at defined points: approving held actions, owning each agent's role, setting limits, and approving new connections. The architecture should make those points explicit, so it is clear who is answerable for each.
How do you check the placement is right?
Run three tests. Try to perform an agent action without passing the operating system; it should fail. Take the operating system offline; agents should stop acting rather than act unchecked. Pick any action from last month and reconstruct it from the record alone. The agentic operating system requirements checklist includes these and more.
Where Pryme fits
Pryme Intelligence is the layer between AI models and a business. It sits in the path of agent actions, applies the minimum chain of five bounds at the moment of action, and files every verdict in an append-only record. Your systems, gateways and agent platforms stay where they are. The full design is in the governed agentic operating system guide.
Questions people ask
Does the operating system need to see model traffic?
No. It governs actions, not prompts. It can work alongside an AI gateway that handles model traffic.
Can it sit in the cloud while our systems are on premises?
It can, with secure connectivity, but latency and data location matter. Many businesses place the enforcement point close to their systems for both reasons.
What happens to agents that were built before it existed?
Their tool calls are rerouted through it and their credentials replaced with ones only the operating system holds. They are then certified like any new agent.