The governed agentic operating system
Your agent is one convincing sentence away from something you cannot undo.
It will refund the wrong order, email the wrong list or change the wrong record, and it will be certain while it does it. That fear is what kills agent projects in security review, and it is the right fear. What decides the outcome is not how clever the model is. It is what stands between the moment it decides and the moment the money leaves.
Six things stand there. This page follows one ordinary request through all six — the kind your support desk sends a hundred times a week — and then shows you what the system wrote down about it.
Five multiple-choice questions. A person replies within one business hour.
What stands in the gap
- 01LiveKiraSo nobody has to learn prompt engineering to get work done. You brief it; it shows you the plan first.
- 02LiveMotherboardSo the answer to “what stops it” is one place, not six. Tiers, ceilings, approvals, the ledger.
- 03PreviewAtlasSo “completed” means the work was checked, not that the process exited.
- 04PreviewMorphSo the person who must decide gets one screen, on your brand, and ninety seconds is enough.
- 05LiveMnemeSo what the business knows informs every decision — and a planted note unlocks nothing.
- 06LiveHydraSo the model your regulator rules out is off the list, and the vendor stays a choice.
One sentence, and then we will stop naming things: you ask Kira, Motherboard decides what is allowed, Atlas does the work and proves it finished, Morph puts it in front of whoever must act on it, Mneme remembers it without ever getting a vote, and Hydra is the one door through which every model and every tool is reached.
One request, end to end
Ten things happen between the sentence and the refund.
Someone on your support desk types refund this order and tell the customer what happened. On most platforms that is one instruction and one hopeful outcome. Here it is four actions at three risk tiers, and most of the ten steps below exist to decide what is not going to happen. That work is invisible in a demo, which is why it is written out.
- 01Kira
The request arrives
The sentence lands in Kira, which treats it as a request rather than an instruction: read it, split it into the actions it actually contains, show the plan. Nothing has run, and no model has been called yet.
- 02Motherboard
Identity resolves before intent
Before a model is involved at all, the runtime settles who is asking, which workspace they are in, which agent has been asked to act and what that agent’s own identity is allowed to do. An agent with no resolved policy does not get a reduced set of powers. It gets none.
- 03Motherboard
Policy resolves, and the ceiling comes with it
The resolved policy carries the tier map for every action in reach, this workspace’s approval rules, and the ceiling. If the run is unattended, that ceiling sits below anything irreversible and no wording in the request moves it: an agent widening its own limits is itself a top-tier action, which is a polite way of saying it is refused.
- 04Motherboard · Hydra
The tool list is cut to fit
Now the model is brought in, and it is handed only the tools the policy allows. The filtering happens before the model sees the list, which is the entire point. A tool that was never offered cannot be called, however persuasive the text in the ticket, the email or the web page the agent has just read.
- 05Mneme
Memory is read as advice
Kira recalls what the business knows about this customer and this workspace. Each recalled fact arrives with its source and its authority class, and none of them can grant a permission. That is why a planted memory is a nuisance here rather than an exploit: there is nothing for it to unlock.
- 06Atlas · Hydra
The work runs, in the open
Atlas takes the goal, plans it and executes step by step, calling models through Hydra, which uses the family your workspace chose and fails over when a provider is unavailable. Progress streams while it happens. You can watch, pause, redirect or stop the run mid-flight, and nobody needs to know what a prompt is to do it.
- 07Motherboard
Each action meets its tier
Reading the order is T0 and runs. Drafting the message is T1 and runs. Updating the record is T2, reversible, and runs with the before and after stored. Issuing the refund is T3, because money is leaving the business. The agent prepares it in full, with amount, reason and evidence, and then stops. This is the part buyers do not believe until they watch it: the agent got all the way to the end and did not press the button.
- 08Atlas
The result is checked by something that did not write it
On supported runs the work is verified by a different model family from the one that produced it, and the run does not close until the evidence is attached and both the builder’s integrator and an independent reviewer approve. That is live today for governed software delivery and being productised for business work. Every run also publishes what it did not prove, which is the sentence most verification stories leave out.
- 09Motherboard · Morph
A named person approves what cannot be undone
The prepared refund goes in front of a person with everything needed to decide on one screen: what the agent did, what it is asking for, which policy version applied, and what it was refused. A model cannot forge that approval, and a spoken yes to the assistant is not a signature. Operator approvals run today; the inbox your own staff will use, on mobile, email and chat, is in preview.
- 10Motherboard
All of it is written down, including the no
Every step above writes an event under one correlation id, and there is an event for each way a step can end: completed, failed, denied, or waiting on a person. The refusals are records too. That is what makes the trail worth reading — you can show an auditor what the agent did and, more usefully, what it was stopped from doing.
- 14:02:11T0policy.resolveexecuted
agent identity, tier map and ceiling bound to the run
- 14:02:12T0order.readexecuted
read only · scoped to one workspace
- 14:02:14T1message.draftexecuted
draft and its sources kept
- 14:02:16T2record.updateexecuted
reversible · before and after stored
- 14:02:18T3refund.issueheld for approval
prepared in full, then stopped · waiting on a named person
- 14:02:18T5policy.ceiling.raiserefused
an agent may not widen its own limits
Nothing in that sequence depends on the model behaving well. The tiers are resolved before the model is called, the tools are filtered before it is asked, and the refund is held whether the model is confident, hesitant or wrong.
The tier table behind these rows, and a demo where you try to talk an agent past it, live on governed autonomy.
The six pillars
Now the same walk, slowly, with every line’s status attached.
Each pillar opens on the problem it exists for, then gives you the mechanism, line by line, with a badge on each line. We badge lines rather than products because “available” at the product level is how vendors hide the half of a feature that is not built.
Pillar 01
Kira
Nobody on your team is going to learn prompt engineering, and they should not have to. You brief Kira the way you brief a person, and one identity puts on whichever specialist role the job needs — strategist, researcher, writer, builder, reviewer, operator — then shows you the plan before it runs it.
In the walkthrough: step 01
The mechanism, line by line
- Live
Chat is the door that is open today. Ask in words. Kira reads the work, shows you the plan it intends to run, and asks before anything that matters rather than after.
- Preview
Voice runs on the same rails, through the same gateway and under the same limits, so a spoken “yes” is never a signature and never clears an approval. Voice is in preview; we will tell you on the call exactly which channels are switched on for your workspace rather than letting you find out in week three.
- Preview
Roles are how one Kira becomes a team. A researcher and a reviewer are two different policies and two different tool sets, not two different products. We configure roles with you during a build; tenant-editable role objects are being packaged.
- Live
The plan is the artefact. Kira prepares work rather than narrating it, so what you approve is a concrete action with its evidence attached, not a paragraph of intent.
Kira. One accountable human. A whole governed team.
Pillar 02
Motherboard
Agent projects die in security review because nobody can answer one question: what stops it. This is the answer, and it is one place rather than six — risk tiers, ceilings, approvals, budgets, tenant isolation, agent identity and the audit trail, all resolved before an action runs.
The mechanism, line by line
- Live
Every action carries a risk tier, and the tier decides what happens next — not the agent’s confidence, and not how the request was phrased. This is enforced on the governed action path your workflows run on; the security pack states the coverage across the rest of the surface.
- Live
Unattended agents have a ceiling that is not a setting. An agent running without a person present cannot reach the tiers that publish, pay, deploy or delete, whatever it is told and however it is told.
- Live
Irreversible actions wait for a named person, and an agent cannot approve itself. Approvals are recorded with the approver, the evidence and the policy version that applied at the time.
- Preview
The approval inbox your own staff will use — mobile, email and chat, with delegation and a two-person rule for the top tier — is in preview. Approvals run in the operator console today, which works and is not yet the experience a claims supervisor deserves.
- Live
Agents see only the tools their policy allows. The list is filtered before the model receives it, so prompt injection has nothing to reach for: an unoffered tool is not a tool the model can be talked into using.
- Preview
Every agent has its own scoped, audited identity, so the trail says which agent acted rather than which service account was borrowed. Per-agent identities for customer workspaces, with rotation, are being packaged.
- Preview
You set the spending ceiling per workspace, per agent and per run. Per-run step and cost caps, loop detection and provider breakers are in place today; workspace-wide budget control is handled with you during delivery and is being productised, and at a ceiling the default is stop, not bill.
- Preview
Your data is fenced by the database, not by application code remembering to filter. Coverage across the whole surface, and the cross-tenant negative-test report that evidences it, are covered in the security pack on request.
- Preview
Change the rules yourself, with a preview of the blast radius — what a policy change would affect, before you commit it. The customer-grade editor is in preview; today we configure policy with you and hand over the run-book.
- Live
Everything leaves a trail, including the refusals. Each action writes an event for every way it can end — completed, failed, denied, or waiting on a person — under one correlation id.
- Design partner
Download the evidence for a run: who asked, which agent and policy version, which tools were offered and which were used, the approvals, the checks and the votes. The export surface is specified and not yet built, so today we produce that bundle with you.
Motherboard. Permission first. Action second.
Pillar 03
Atlas
“Completed” is the most expensive word in agent software, because it usually means the process finished rather than the work is right. Atlas takes a goal instead of a prompt, streams every step while you watch, keeps the artefacts, and will not close a run on its own word.
The mechanism, line by line
- Preview
A goal, not a prompt. Atlas decomposes the goal, runs the steps, streams progress and keeps every artefact it produced. This is live for governed software delivery; the general executor for business work is in preview and is the next thing we turn on for a customer.
- Live
Watch, pause, redirect or stop any run mid-flight. Not a kill-switch bolted on afterwards: a run is an object with a state you can change while it is in motion.
- Preview
Verified completion. On supported runs the output is checked by a different model family from the one that produced it, and the run closes only when the evidence is attached and two approvals — the builder’s integrator and an independent reviewer — are on record. Live today for governed software delivery, being productised as a control on general business work.
- Live
Every run states what it did not prove. A verification result with no stated scope is a mood, and we would rather hand you the boundary than let you assume a wider one.
- Preview
Agent definitions are versioned and pinned, so an edit made this morning cannot change the behaviour of a run already in flight. Draft, publish, diff and rollback for your own definitions is in preview.
- Preview
New agents start in shadow, measured against your real traffic before they speak to anybody, and you see the scorecard before the go or no-go. That is how we deliver every build today; a shadow-mode switch you operate yourself is being productised.
Atlas. No model grades its own work.
Pillar 04
Morph
The supervisor who has to approve that refund is on a phone, between two other jobs, with about ninety seconds. Handing her a chat window is how approvals turn into rubber stamps. Morph shapes the work into the surface that fits the person doing it, under your own brand and on your own domain.
In the walkthrough: step 09
The mechanism, line by line
- Preview
Workspaces assemble around the job. An approval queue, a console, a form and a conversation are different shapes of the same governed work, and the person doing the job should get the shape that fits it.
- Preview
Your brand, your domain, our governed backend. The front end belongs to you and looks like you; authority never leaves the backend, so a client-facing app cannot grant itself powers the policy did not give it. Running for one deployment today, which is why this line is marked preview and not live.
- Preview
Install a system or a module rather than commissioning one. Modules are registered objects that reconcile on boot; the self-serve gallery that browses them is being packaged.
Morph. Your brand on the front. Our governance behind it.
Pillar 05
Mneme
An agent that forgets is useless, and an agent that remembers whatever it is told is worse. Mneme shares memory across sessions, people and channels under the one rule that makes that safe to have: a remembered fact can inform any decision and can authorise none.
In the walkthrough: step 05
The mechanism, line by line
- Live
Every recalled fact carries its source and its authority class. You can see where a belief came from, which is the difference between memory and folklore.
- Live
Memory advises and never authorises. No remembered fact can grant a permission, raise a ceiling or stand in for an approval. This is a property of the runtime rather than a convention the agents observe, which matters because memory is the softest thing in any agent system to poison.
- Live
Recall is scoped to your workspace. Scoping is enforced by the system rather than by the agent’s good manners, and broader coverage of the scope gate is being completed.
- Preview
The shared-graph layer on top — relationships between what the business knows, rather than facts on their own — is in preview and is being made durable.
Mneme. Memory that advises. Humans who authorise.
Pillar 06
Hydra
A model you cannot swap is a dependency you did not price, and a model your regulator will not accept is a project you cannot start. Every model and every connector is reached through one gateway, so the policy is written once and the vendor stays a choice.
The mechanism, line by line
- Live
Any model, behind one gateway, with failover. The major commercial families and open-weight models are reached the same way, so the model becomes configuration. You choose which families are allowed, which matters when a regulator or a procurement policy rules one out.
- Preview
Choose per workspace; bring your own keys. Per-workspace model configuration runs today and the customer-facing key surface is in preview, so during a build we wire your contracted access with you.
- Live
Model diversity is a safety property here, not a procurement one. It is what makes an independent checker possible on supported runs: the verifier is never drawn from the same family as the builder.
- Live
Open by standard. Any MCP-speaking agent or server shares the same governed context and the same action surface, which is also the fastest route to a tool we have not built an adapter for yet. Published developer docs are on the build plan.
- Preview
Connect your channels and business tools. About twenty adapters run today and the business-tool set is being extended one at a time. We would rather hand you the adapter list, including what is missing, than a marketplace page of cards with nothing behind them.
- Preview
Cost is recorded per agent, per workspace and per provider, including the checker’s. The customer-facing dashboard is in preview; today those numbers reach you in the monthly governance report.
- Preview
Private deployment and self-hosting. The platform is componentised and runs on our own cluster; a packaged customer install path is built with the first customer who requires it.
Hydra. No lock-in. One rulebook.
The seventh thing, which is not a pillar
The ceiling you would be buying is the one our own agents work under.
New capability in VertixOS is written by the platform’s own agents, under the same tiers, the same tool filtering and the same verification you would get. Between 28 June and 18 September 2026, 214 machine-built changes were promoted through our own worker, across three model vendors. A vendor whose own engineers quietly work outside the controls they sell you has told you what the controls are worth.
The limits of that number matter as much as the number. It is an internal engineering workload on our own repository, run by one operator. It is not a customer benchmark, and running this on your codebase is a separate conversation with its own gates.
It also means this page changes month to month. The preview lines above are being packaged rather than imagined, and the design-partner ones are waiting for the customer they get built with.
How we build software this way · The rules the agents run under
The technical objections
The questions an architect asks in the second meeting.
None of this matters until it is your own action list.
So start there. You end up with every action in your business split by risk tier: what an agent may do unattended, what waits for a named person, and what should stay entirely human. That list is yours to keep whether or not you buy anything else.
Five multiple-choice questions. A person replies within one business hour.
Autonomy where it is safe. A human where it is not.
