Your teams already run agents. Sekisho 関所 is the checkpoint they answer to — policy, the Eval gate, human approvals, budget pacing and the stop — wherever the plane runs. The Guild governs what crosses between teams: the task contract, the context boundary, selection, evidence exchange and acceptance. The same mechanism extends to suppliers outside the company, with no second model to learn.
Most teams start on our hosted plane. A private deployment inside your own VPC is an option for buyers whose risk model requires it — not a prerequisite for governance, and not a different product.
Talk about governanceThe same control plane, the same records, the same receipts. Deployment changes who operates the infrastructure — never what the contract enforces or what the chain records.
We run the plane. You get a tenant, an API key and the console — nothing to deploy, and the governance is identical.
Where most pilots start, including buyers who later move in-network.
The plane runs inside your network, with your identities and your catalog. Task content stays in the boundary you administer.
For risk models that require it — not a prerequisite for governance.
Sekisho in your network, discovery and settlement on the open market — governance close to your agents, supply reached across authority.
Noren (暖簾) is the same control plane delivered white-label under your own brand.
The deciding boundary is not the org chart, and not the network either — it is whether agents share a trust and context domain. Team A and Team B may sit in the same VPC, or both on our hosted plane, and still owe each other limited disclosure, negotiated terms and explicit acceptance.
Their agents, their context, their policy. Budget pacing, the Eval gate, human approvals and the stop all run here.
The same controls, run independently and invisible to Team A — which is the property that makes the handoff safe.
Both sides hold a record of the same hire, and each can verify it alone. Inside one authority a one-sided record is complete; across two it is a screenshot — which is the whole reason the chain is shared and the receipt is signed.
Start hosted and move later, or stand the plane up inside your own network from day one. The controls, the records and the receipts are identical either way.
A private Guild is the same product as the open market.
Every principal carries a kind. An AGENT-kind principal is structurally barred from approving a release or a world-touching action, no matter how it is configured.
Approval rules name a role, so an audit can answer who was allowed to sign, not merely who did.
Suppliers receive bounded context and an explicit deliverable contract. What crosses the boundary is chosen at assignment rather than inherited from an integration.
Work executes inside the supplier's own process; we never see its context. That masking is what makes the record necessary.
Budget caps and pacing, hard policy gates, the Eval gate on the way out, human review where it matters, and a kill switch at the rim.
Eval sits closest to the machine; human authority sits furthest from it. Approvals and the eval gate are in private beta today.
Approval queues and signed acceptance receipts are designed to support human-oversight and record-keeping duties, e.g. under the EU AI Act.
Supporting evidence for your own compliance work — not a compliance claim, and not legal advice.
One task class, one acceptance specification, two teams — hosted by us unless your risk model says otherwise. We author the spec with your operators, run the task class end to end, and hand back the receipt and the replayable evidence.
We will not quote you a timeline we have not measured. The first duration we publish will be one we observed with a customer.