Deployment
What deploying a blueprint looks like.
A blueprint arrives finished: the job is named, the permitted outcomes are a schema, the tools are typed and the checks it must pass ship beside it. Deploying one is not a build project. It is an inspection, a set of bindings and a decision about authority.
The artifact
What a blueprint contains.
manifest
One versioned file names the job: the business line, the function, the instructions the agent runs on and a model alias the deployment resolves at install. The whole agent is legible before it runs.
contract
The outcomes the agent may return, written as a schema, and the single tool that commits one. A result outside the contract fails the run instead of becoming a decision.
tools
Every call the agent can make, named and typed, each bound to a connector. The agent reaches systems only through this seam, and the seam is where policy can act.
evals
Cases with graders, the adversarial ones included. The blueprint has to pass them before a change ships and again after it does.
gates
The decisions the blueprint refers out: fields named as prohibited are redacted at the seam, listed actions require approval, and a human owner takes the referral.
The institution’s side
What an institution supplies.
Systems
The blueprint's tools bind to connectors. The recorded examples run on representative connectors built for the library; a deployment binds the same seams to the institution's systems of record.
Policies
Thresholds, prohibited fields, approval rules. They arrive as an overlay on the versioned base, so the institution's rules sit beside the artifact rather than inside a fork of it.
Decision owners
Named people with the authority to decide. Every gate has an owner before anything runs; the agent prepares and refers, the owner decides and stays accountable.
The rollout
How a rollout proceeds.
Inspect the blueprint.
Read the manifest, the contract, the tool list and the evaluation cases. Everything the agent can do is written down before it does anything, so review starts as reading rather than reverse engineering.
Run it against supplied cases.
Replay the shipped evaluation cases first, then cases the institution supplies. Graders mark every outcome against the contract, and a failed check stops the rollout at that step.
Wire the institution's checks.
Bind the connectors to the institution's systems, apply the policy overlay and add the institution's own cases to the evaluation gate, so the blueprint is tested on the work it will see.
Go live under the institution's authority.
The institution turns the agent on inside its own controls, with an owner named on every gate and each decision recorded as it is taken. Authority stays with the people who answer for the outcome.
Where governance sits
One seam, every action.
Every tool call crosses the same seam. A policy engine there can act on the call before a system sees it, and what it does lands in the run record beside the step it touched. The record is hash-chained, so a later edit shows.
allowredactflagmodifyblock
The recorded examples on this site ran under this runtime. Paired captures show the same case with and without a policy acting.
See a policy change the outcome