Operating systems
The same engine that decides whether the agent may confirm a booking decides whether it may restart a service. What changes is the tool you declare. What does not change is who decides, what gets confirmed first, and what is recorded.
In front of a customer, a governed AI is a comfort. In front of a system it is the price of entry: nobody grants production access to something that makes things up, acts without permission and leaves no trail. That is what the decision engine adds.
The model interprets what you asked and extracts the data. What gets executed is decided by a declared rule you can read in a file. No rule, no action: the model writing it is not enough.
Authorize, execute, verify, record. Anything irreversible asks for an explicit yes first, and the gate cannot be talked out of the way.
What it understood, which rule it decided by, which tool it ran and what your system returned. It is what you will want to have when something breaks at three in the morning.
Handoff is part of how a turn is designed, not a patch: the case goes to whoever has to decide it, with the full context of the conversation.
Restart the payments service.
service: payments · action: restart
restart is irreversible → gate
wants an explicit yes before running it
restart(payments) → ok in 4.2 s
who asked, which rule applied, what came back
Restarting payments cuts off the operations in flight. Do it anyway?
In plain language, from WhatsApp or from wherever you already watch everything else. No dashboard to open, no chart to hunt for.
Is the payments service down?
It answers with the status the platform measures and, if something is degraded, it says so before a customer asks.
How is the server doing?
The health metrics and their trend against previous days, in one sentence, with the detail if you ask for it.
Did any integration fail last night?
Which provider or integration degraded, when, and whether the system carried on another way instead of cutting out.
What happened in the 2:32pm conversation?
That turn’s trace: what it understood, which rule it decided by, which tool it ran and what your system returned.
How much memory is the server using?
CPU, memory and disk from the latest snapshot, with the overall status.
Is any service down?
The status of every service the platform watches, not a "seems fine".
How does that compare to yesterday?
The averages for the last 24 hours and how the statuses were distributed over that window.
Were there alerts last night?
The latest alerts with their time and the values that triggered them.
Is it responding slowly?
The latency for the period, so you answer that question before a customer asks it.
Any errors today?
The errors from the last 24 hours, grouped.
How much have we used this month?
Token usage for the period and the active users.
Today it answers about what the platform measures. For it to answer about your own systems you declare the tool or connect it over MCP: same mechanics, and it is configuration.
Two paths, and they combine: the tools Magnus already ships per industry, and your own through MCP (Model Context Protocol). Whatever your system already exposes over HTTP is declared as a tool and becomes available to the agent, with the same gate and the same trace in front of it. Nothing has to move and nothing that works gets replaced.
The pattern is always the same: what you write, the rule that decides, and what gets recorded.
How is the server doing?
Reads the health metrics, compares them against the previous days’ trend and answers in one sentence, with the detail if you ask for it. Today it reads and advises: it does not make changes.
I have a delivery for 702.
Talks through the building’s phone system and transfers the call to the right apartment. Transferring is a gated action: authorized, executed, verified and recorded. It does not decide to open the door.
Add two more and close it.
Builds the order, reads it back in full and closes it only on an explicit yes, because closing an order is declared irreversible.
Can I see the one downtown on Thursday at 5?
Checks the slots the system returns, offers the ones that exist and books the visit after a confirmation.
The printer in accounting has been down since yesterday.
Detects the urgency, tries the knowledge base first and, when that is not enough, opens the Jira ticket with the context of the conversation.
How many boxes of 4471 are left, and when does order 9912 arrive?
Queries stock, orders, deliveries and invoices on SAP. These are read-only queries today.
So there are no surprises in the first meeting: the infrastructure agent reads and advises today, it does not make changes on the server. The actions that do execute behind a gate live in the other industries — closing an order, booking a visit, opening a ticket, transferring a call on a real phone system. Enabling an infrastructure action means declaring the tool and putting the gate in front of it: configuration on the engine that already runs, not new development. If your case needs it, we build it with you.
You show us the system and what you want to be able to ask it in plain language, and we tell you what the existing pieces already cover and what has to be built. If it cannot be done well, we say so there.
