Both roles, inside your own walls.
A single business can be both the shop and the agent frontline. You grant every capability, you hold the pinned root the gate verifies against, and every action lands on a hash-chained record. Same model, same governance, same Control Information Center.
The model has two roles in it. A shop manufactures capability: it takes an order, builds a governed capability pack, signs it under its own authority, deploys the agent, and stays accountable for what it shipped. An agent frontline does the work inside a business, through granted capabilities and nothing else.
Those two roles can sit in two different companies. They do not have to. A single business can hold both. You are the shop that signs, and you are the frontline that runs. Same model, same governance, same Control Information Center. The only thing that changes is who owns which side of the relationship.
Holding both roles means there is nobody to point at. That is the situation you were already in. What changes in-house is that the authority the agent held was granted by you, in advance, on purpose, and the record of what it did with it sits where you put it.
Nothing you did not sign will run
Capability does not arrive as a prompt, and not as a settings file the agent can reach. It arrives as a signed capability pack, verified against a pinned root before anything in it runs. In-house, that root is yours. You pin it, your own shop signs against it, and nothing signed by anything else clears. An agent cannot mint a key the gate will accept, and it cannot widen the gate to accept one, because the gate is not writable by the thing it gates.
Unverified means denied, before execution, rather than flagged in a report the following morning. Prevention, not detection.
Check it yourself
Three packs arrive at the gate. One gets through.
Capabilities ship as signed packs, and before anything runs the gate verifies each pack's signature against the pinned root you control. Verify these three the way the gate does.
Pinned root
a41f...9c2e, pinned by the operator
Incoming capability packs
Pick a pack to run verification against the pinned root.
What you can finally see
You are not short on people. You are short on a defensible answer for the ones you would like to arm.
Every action passes one chokepoint that fails closed. Not granted means denied. Not verified means denied. Errored means denied. What passes is authorized before it runs and recorded after, on a hash-chained record the agent cannot edit.
That makes the record the answer, not a reconstruction assembled after the fact from four dashboards. You can see what an agent was allowed to do, who allowed it, and what it did, because nothing outside that authorization runs.
What you hold, and what you do not
You hold the pinned root, the grants, the intent, and the record. Workflows are written against intents in your own business language: update the CRM record, issue the refund, reconcile the invoice. The model behind an intent is replaceable, and so is the tool.
That is continuity protection. A provider can be taken off the board by forces outside your business. Your workflows do not have to go with it. Your intent and your record are yours, not the platform's. Leaving is a supported operation.
The Control Information Center that will show the fleet in one place is being built in the open. The gate and record underneath it hold today.
Follow the build.
The newsletter carries what breaks, what holds, and what changes as I build this in the open. It is the place to assess the work before you assess the product.