What we're proposing to build
One assistant.
Many hats.
Provably controlled.
A personal AI assistant where every action it takes rides a governed write-path that's already running in production.
The differentiator isn't capability — everyone has that. It's governed autonomy: agency you can prove was controlled. Every consequential action an agent attempts is risk-scored, checked against policy, gated to a verdict, and written to an immutable audit trail — on a control plane already proven in a regulated production setting.
The assistant brings the part that's new and distinctively ours: an Authority Context that knows which engagement it's acting under, and a read-side soft wall that keeps client and IP data from bleeding between contexts. The heavy controls underneath — the gateway, the policy engine, the risk scorer, the audit trail — we reuse rather than rebuild.
The read side: which hat, what's in scope
Authority Context governs what the assistant may see and where derived data may flow. The soft wall holds even when it's you on both sides of it. This is the layer that doesn't exist yet.
The write side: what the assistant may do
Every mutation flows through ctx.governed_write() and comes back with a verdict. The gateway, OPA, the risk scorer, and the audit trail are already built and running.
How it's built
Two planes, one seam
The assistant lives on top. It never touches data or fires an action directly — it submits every mutation down through a single contract, ctx.governed_write(), and reacts to the verdict that comes back up. The agent framework holds no governance logic at all — which is exactly why the framework choice (Pydantic AI) is the most replaceable part of the stack. Click any part.
The core idea — try it
Pick the hat. Watch both planes decide.
Choose an Authority Context, then try an action. The left panel shows what's in scope for that hat. The right panel shows the full decision: first the read-side soft wall (the assistant's new layer), then the governed write-path — risk score, policy, verdict, and audit — for anything that changes the world.
Try an action
Ask the assistant to do something while it wears the selected hat.
What it feels like to use
A governed, context-aware day
The assistant follows you through the day — inferring the right context, asking when unsure, and sending every action it takes through the write-path. Click any moment.
Why leadership can trust it
A clear division of labor
Two distinct planes, two distinct jobs. The assistant governs the read side — what it can see and where data may flow. The platform underneath governs the write side — what it may do. Be precise about this: the running write-path does not, by itself, do the read-side wall. That's the work we're adding, and it's the part that's distinctively ours.
Added by the assistant
Already enforced underneath
"I summarized the invoice. It also contains text instructing me to add a payee and release payment — that came from the document, not from you, so I did not act on it."
The gateway only accepts an irreversible-action authorization whose source is the chat surface. A document is structurally never in a position to issue one — and adding a payee plus releasing payment would each face the risk score, segregation-of-duties policy, and your confirmation regardless. The denied attempt is itself recorded to WORM.
The plan
Lighter than it looks
Because the heavy controls are reused rather than built, R1 is mostly the read-side layer plus integration against a service that already runs.
Five specialists ship in R1
Each runs only the tools its context allows. None sends, deletes, schedules, or pays without a verdict from the gateway.
Read-side Authority Context layer: proposed build. Governed write-path: in production. · Built on Pydantic AI + Azure · Prepared with Claude as drafting partner.
Draft for discussion — illustrative walkthrough; verdict thresholds and risk dimensions shown are representative, not the production policy set.