The operating system for back-office agents.
A supplier's invoice arrives Monday. Four agents and a controller move the money by Thursday. Six months later the auditor asks who authorized what, on which data, under which rule. WunderOS answers from your own systems: the specification each agent ran under, the runtime that enforced it, and the record of what each one did, kept apart from the agent's own report, so you can replay anything any agent did, step by step, exactly as it happened.
The auditor asks two questions.
First, what was this agent allowed to do? Second, what did it actually do, that is, which model version made last quarter's decision and what data did it see?
A vendor embeds its engineers. The engineers deliver agents that work and then they leave. The agents stay. The policy, rules, and exceptions live in prompts and harness code that only the vendor's engineers understand. You may only discover what you bought when the model changes or the auditor shows up.
The two questions need different evidence. The first is answered from a specification you own. The second can't be answered from any specification, because a specification says what the system was configured to do, not what it did. The second needs a record that replays what each agent did, exactly as it happened, kept apart from every agent and from what the agent says it did. The same holds true for oversight. Agents logged in the vendor's format and watched through the vendor's console are supervised from outside and opaque within. Regulated industries know the difference.
If answering either one means calling the vendor, you bought a dependency, not a capability.
None of this argues against vendors. All of it demands clarity about what transfers.
Three things stay with you.
The specification
Rules you can read and change
Your policy, vocabulary, and constraints, held in a form people can read, amend, and sign off. When a requirement changes, you change it, not the vendor.
The runtime
Authority no agent can rewrite
WunderOS runs inside your VPC. Every read, model call, tool call, and side effect crosses one governed boundary. No agent, yours or a vendor's, can alter the rules it runs under. The models can stay wherever you buy them.
The record
Answers without a vendor dependency
You can replay any agent's work, step by step and exactly as it happened, from a record in your format that no agent and no single party can edit. It holds what each agent did at the boundary, not what it said it did, so the regulator's second question is answered from your own systems.
You need an operating system for the agents you build, inherit, or buy.
What does the owning is WunderOS, the operating system for back-office agents. Models will keep absorbing the harness: planning, tool use, and checking their own work. But models won't absorb the specification, the runtime, or the record, because those exist to hold agents to account, and nothing can be held to account by a layer it can rewrite. What is an agent OS? →
Start where the dependency hurts most.
Partner agents
A partner's agents need your data.
Admit them to an Agentic Data Enclave inside your VPC. They do useful work on your data. You can replay every step they take, and nothing leaves without passing a curation gate you control.
Inherited agents
You inherited agents a vendor built.
Bring them under a runtime you operate and a record you hold, without modifying them.
Your own agents
You are building your own.
Put the parts that outlast the next model, the rules, the authority, and the record, in a layer that no agent or model can absorb or rewrite.