Governed operations for AI agents
Put AI agents to work on real operations — without handing them the keys
cloud-itonami is where an organization adopts and governs business procedures written in Kotoba. Facts and audit trails persist in Kotobase; model inference is delegated to Murakumo. An agent can propose anything — it cannot change the world without passing a typed capability and a governor.
One product, three foundations
These are not four products side by side. cloud-itonami is the surface a customer touches; Kotoba, Kotobase and Murakumo each hold one clearly separated responsibility underneath it.
Kotoba — safe execution
Describes and runs what an agent is allowed to do, in a language with no ambient authority.
Source of truth for policy, capability and effect.
Kotobase — durable state
Persists operational facts, artifacts and audit trails, content-addressed.
Source of truth for storage and provenance.
Murakumo — AI inference
Runs model inference and compute on the fleet. It holds no authority to approve anything.
The compute plane.
cloud-itonami — governed operations
Turns tenant, identity, workflow, human approval, governor and UI into one operational experience.
The first-party application for Kotoba.
Where this actually stands
Everything above is what this is for. Below is how far it has actually got: industries and occupations lead, and government functions (COFOG) have no implementations yet.
The catalogue lists 800 implementations (798 with a working demo). Public business blueprints at deploy time: 21. The current figure, including self-registrations, lives at /api/open-business. The catalogue and the procedures are read from /marketplace.json · /licenses.json at deploy time — none of these numbers is typed by hand.
Why it is built this way
It implements the procedures themselves
This is not "a platform for any workflow". Procedures are implemented and published one at a time, per industry (ISIC), per occupation (ISCO), per government procedure.
Each implementation has its own repository and a working demo. The full list is under Solutions.
Designed from the language up to survive attack
Implementations are written in .kotoba. Its application layer has no eval, no dynamic loading, no reflection, and no ambient access to the network, the filesystem or credentials.
Three guarantees: memory safety, effect soundness, capability confinement. Anything that reaches the outside world does so as a typed capability that passes policy. There is no ambient way around it.
Model output is never trusted
An AI agent can only propose. Until schema validation and a governor accept it, not one outbound operation happens. Models are handed no credentials and no unrestricted clients.
However far automation goes, anything that actually changes the world passes a human or a governor.
No central approval to get in
You create your own tenant. Self-issued CACAO / did:key — no review queue, no shared token.
There is structurally no step where you wait for someone's permission.
Open source, and forkable
AGPL-3.0-or-later. Implementations and registries are public; if you dislike how this is run, fork it and run it yourself.
The point is that infrastructure handling government procedure is not held by a single company.
It holds "unknown" as a value
Values that get revised — fees, form versions — carry their own unverified flag and the method to confirm them.
Administrative values are never displayed as settled facts. Fabricate nothing.
How it runs
Every event in the business rides the same four stages. A person presses approve — but what happened is kept, all of it.
- 1activity
An inbound message, a request, an event. People and agents enter through the same door.
- 2decision
A course of action is chosen. The options and the reasoning are kept.
- 3effect
The outbound operation — sending, billing, filing. This is the only stage that changes the world.
- 4audit
An append-only ledger. Who let what through stays traceable afterwards.
Who this is for
Organizations that want their operations on one thread
Sales through billing and legal, not scattered across separate SaaS but handled on one log. This site is itself one tenant running that way.
People who want to build and run their own industry's implementation
Fork an existing implementation and operate it. Once it is in the registry, the demand side can find it.