Notes
Start with people, add the agent one step at a time
For operations leads who want the approval chain and the record before they trust an agent with any step, and for the people who will be asked to sign, brief or carry things out by name.
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC.
Most companies do not start with an agent. They start with a flow that already works on paper - a request, a review, two signatures, somebody who goes and does it - and a record that lives in a spreadsheet nobody can audit. The question they ask is not “which step should the AI take first” but “can we put the flow in as it is, and decide later”.
GembaOS answers yes, and it is not a special mode. Every step of a playbook names who does it, with a default: the brief is the AI investigator’s unless a position is named; the proposal is built by GembaOS from the record unless a position fills it in; the signatures are always people’s or a rule the company confirmed; the execution is GembaOS calling the system unless a position carries it out by hand. The AI is one of the actors a step may name.
1. The contract sealing desk, with nobody but people in it
The reference company ships a business that has no model in it. An employee asks for the company seal on a contract. Legal reads the contract register and writes the brief - the same form the AI investigator fills on the claims desk, and GembaOS checks it the same way: the counterparty and the amount legal typed are compared with the register, and a difference is marked, whoever wrote it. The operations lead signs; above one million yen, or when the contract renews by itself, the finance director signs too. Then legal takes the physical seal to the contract, logs the seal register, and reports back with the register number. GembaOS reads the register once more and records what it shows.
The route, as the product draws it from the shipped configuration:
Before the decision: Received (The requester) → Records read (GembaOS) → Brief (A person) → Documents (The requester) → The rule picks the band (GembaOS)
| When | Signs | People |
|---|---|---|
| Contract value ≤ 1000000 and Renews automatically: no | Operations lead | 1 |
| everything else | Operations lead → Finance director | 2 |
After the signatures: Re-read before the change (GembaOS) → Carried out by a person, reported back (A person) → Read back from the system (GembaOS)
Three things keep the by-hand step honest. The operation belongs to a pack that says nobody calls it, declared with its fields and its classification like any other pack, and GembaOS refuses to load a playbook that names a person for an operation a system could also perform. The position is one of the company’s approver roles, and the requester does not carry their own request out. And where no read-back is declared, the playbook check says the record will hold only what the person reported.
2. What the record looks like when a person did it
The signature chain reads as it does on any other desk: who signed, in what order, over which facts. Then, instead of an execution by GembaOS, the chain carries the wait for the named position, the person’s report under their own name with the reference and the evidence, the clearance spent once by that report, and the read-back with its result: the system shows what was approved, or it does not, or it was read and recorded because the playbook expected nothing in particular of it.
A report that says the seal could not be applied does not close anything. The clearance is void, the approval request goes back with the person’s reason, and the case waits for its handler - exactly as when a pre-execution check finds the world changed.
3. The same playbook, one step handed to an agent
When the company is ready to let an agent read the contract and draft the brief, the change is one line in the playbook and one instructions file for the role. The release check compares the two versions and prints, on its own line, that the brief is now written by the AI instead of legal. The bands, the execution by hand and the read-back do not change, and the approval form shows the AI’s brief with the same match / differs marks it showed for legal’s.
That is the whole of the migration path: digitise the flow first, with the people who already run it, and let the record accumulate under their names. Each later step an agent takes is a change a second person approved, on the same file.
Sources
- GembaOS Enterprise Architecture Whitepaper, public overview edition, section 3.3 (every step names who does it).
- The shipped configuration:
config/playbooks/seal_request.yaml,config/capabilities/seal.yaml(a pack nobody calls),config/capabilities/contracts.yaml.
Questions this note answers
Do we have to connect a model to use GembaOS?
No. The contract sealing desk that ships with GembaOS has no model in it: legal writes the brief, the operations lead and the finance director sign, legal applies the seal by hand and reports the seal register number, GembaOS reads the register back. The four gates, the approval form, the route map and the record are the same as on a desk an agent works.
How is an action a person carries out by hand different from an action GembaOS executes?
GembaOS never calls the system. Once the signatures issue the clearance, the work item waits for a holder of the named position. That person does the work in the system under their own login and reports done, with the evidence the playbook names. The report spends the clearance once. Where the playbook names a read, GembaOS reads the system back and records whether it shows what was approved; without one, the record says plainly that it holds only what the person reported.
Can the person who asked for something carry it out and report on it themselves?
Not on an ordinary band. The requester cannot sign their own request, and cannot carry it out and report on it either, unless the band was declared self-sign - the same rule that keeps one name from being two signatures.
As of September 2026 GembaOS holds no certification; the control mappings on this site are self-assessed, not audited. GembaOS is in its design partner stage. Read about the design partner program.
Last updated: · GembaOS v0.2