FAQ

Yes. The Gap Register records missing procedures or ambiguous boundaries. Agents can draft proposed instructions; a responsible human reviews and approves them before they become operational policy.

A gap never widens an agent's authority. Until the proposal is approved by a person, no agent can cite it, and the work item that hit the gap waits for the owner named on the gap register.

No. Gateway Mode supports bringing your own agents. Route supported tool calls or MCP connections through GembaOS. We look at your tool interfaces and adapter requirements at the demo.

The agent keeps its own orchestration. What changes is that a sensitive tool call no longer reaches the business system directly; it reaches the capability gateway, which decides under policy and, where required, waits for a human signature.

Low-risk reads and operations within configured limits can pass automatically. Only actions that require approval under your policy go to a human, such as above-limit refunds or privileged production changes.

The route is decided by the policy, not by the agent. A refund within the delegated limit passes on the agent stamps; the same refund above the limit becomes an approval request for the finance owner. Both routes are recorded the same way.

Yes. GembaOS runs on-premises or in a private VPC with self-hosted models. Cloud models and external integrations create their own data paths; configure these deliberately, including gateway-level field scrubbing where appropriate.

Each tenant and each playbook can set a ceiling on which class of model provider may see which data, so a self-hosted model and a SaaS model can be mixed by data sensitivity rather than by role.

Our architects work alongside your team. Plan for an IT or DevOps liaison during setup and named business approvers during shadow mode. The exact effort depends on your integrations and is agreed when scoping the pilot.

No. GembaOS is a governance runtime, not an orchestration framework. It decides whether an action may happen and who must approve it, then executes it once under a clearance; the agent framework decides how the agent reasons and plans.

Agents built in LangGraph, Dify or a vendor CRM call GembaOS through the same gateway.

Execution stops. Before calling the business system the host re-reads the real state and compares it with the facts the approver signed. If a compared field has moved, the action is not executed, the clearance is voided, and the work item goes back for a decision with the change recorded.

The same check covers the arguments themselves: every clearance is bound to the hash of the approved arguments (argsHash), so a call with different arguments does not match the clearance and is not executed. Limits are re-read from the system that owns them just before the write, and the clearance is time-limited, so an approval that waited too long authorizes nothing.

No. The clearance is single-use, and the idempotency key for the write is filled by the host from the approval and the work item rather than by the agent, so a retry, a replay or a restart lands as the same write instead of a second one.

While an approved action runs, the record it targets is held against other approved actions, and each adapter declares how its write guards against a concurrent change: a version, a conditional write, or a lease on the record.

External content is treated as data, never as authority. An instruction embedded in an email, a chat message, a log line or a picture cannot grant a capability, because the decision to allow an action is taken by the policy outside the model.

Content that looks like an injection attempt is flagged on the work item as suspicious input, and a flagged action is routed to a person regardless of what the agent proposed. A picture reaches a model only when the playbook allows it.

Any model with a supported adapter, self-hosted or cloud. Policy checks, clearances and audit records sit outside the model, so a model can be replaced without changing the rules; shadow replay and golden tests show what a new model would have done before it goes live.

A single Linux binary with its own data directory, on a server you control. It serves its console over TLS or behind your reverse proxy, and connects to your systems through adapters (REST, file, SQL, a worker over mutual TLS). No external service is required to operate it.

GembaOS governs the action, not the data flow. An MCP gateway or an AI gateway decides which tools and which data a model may reach; GembaOS decides whether an action the agent proposes may happen and who must sign it, then executes it once under a clearance. The two are complementary and can run side by side.

GembaOS also applies per-field read rules and egress ceilings to the data an agent sees, but the record it keeps is the approval: the verified facts, the exact arguments, the signatures and the replayable event chain.

The person holding the request can consult another role (legal reads the contract terms first), transfer it to a role with at least the same authority, or escalate it to their manager; a manager can take over a request waiting on a report. Each action needs a reason and is recorded; none removes a required signature.

Absence cover comes from stand-in rules over the org chart imported from your directory, for example by amount. When someone leaves, their pending requests move to the nearest available manager or wait for assignment, and their delegations end. A manager's Team Desk shows what is waiting on their team, including requests nobody currently holds.

Yes, when the playbook turns it on, and only by kind: a medical record, a receipt, a quote, from a closed list the playbook sets. The customer is told which documents are needed and by when; the agent's reason goes to the person handling the case.

Each request is a document round on the work item with a due date and a limit on rounds. A missed date is recorded and nothing closes by itself. See the note on asking for missing documents and the claims scenario.

Yes. The rounds, the applicant's confirmation and the consults happen on the work item; the approval request is drafted once, when the file is complete, and each person on the route signs it once with a finding.

A signer who comes back to the request sees what changed since they last looked and the one decision left. A finding can also send the request back, for more documents or to the handler, and the same request is resubmitted.