Product
How the gate works.
Here's what actually happens when any agent in your tenant proposes a tool call. The path, the scoring, how each agent earns its own autonomy one decision at a time, and what a morning looks like when three agents share one audit log.
Why Now
You're about to run more than one agent — or you already are. You need a control plane that scores every tool call, enforces one policy across every agent, and learns what's safe in YOUR systems before the one bad action in a thousand ships real damage.
Progressive Autonomy
From observer to autonomous. Earned, not configured.
Connect any agent to Sansin. The gate starts cautious for that agent, learns from your team's corrections, and graduates it through three modes based on demonstrated competence. Each agent earns its own autonomy, per action class. A DevOps agent trusted to scale pods is not automatically a support agent trusted to issue refunds.
Observe
Alert fires at 3am. Your DevOps agent diagnoses connection pool saturation, proposes scaling pods 3 to 6. Waits for your approval before touching anything.
confidence < 50%Checkpoint
Same alert. The agent auto-scales pods (safe, reversible, 34 prior approvals). But a config change to connection limits? Stops at the checkpoint for your review. Routine work passes through, blast radius waits.
50% – 90%Autonomous
Same alert. The agent scales, adjusts connection pools, and resolves. You review the audit trail over coffee. Novel situations still escalate.
> 90% confidenceDestructive actions never auto-execute, even in Autonomous mode. Safety belt. An agent earns trust through ~50 decisions per action class — not a config file, and not on behalf of its siblings in the fleet.
How It Works
The gate learns what's safe. Here's the mechanism.
Every tool call any agent in your tenant proposes gets scored. Every correction you make teaches the gate. Thompson Sampling turns your team's decisions into calibrated confidence — per tool, per tenant, shared across every agent behind you.
The agent brains are Claude's. The control plane is ours.
Score
Every proposed action gets a risk score before it runs.
An agent wants to scale your pods, open a PR, issue a refund, touch prod. Before anything executes, Thompson Sampling scores the action's risk against this tenant's prior for that tool — a prior shared across every agent in the tenant — and returns a confidence level based on everything the gate has learned so far.
Action: scale_pods(replicas=6) Risk: 0.23 (low — reversible, seen 34x) Conf: ████████████████░░░░ 0.82 Verdict: ALLOW
Learn
Your corrections update the model. Every one counts.
When the gate blocks something that should have been allowed, or allows something you'd rather review, your override feeds directly into Thompson Sampling. The Beta(α, β) distribution updates for that tool in your tenant. Next time any agent in your fleet proposes the same tool, the score is better calibrated.
Override: update_config(pool_size=50) was: BLOCK → corrected to: ALLOW Reason: "verified safe — standard pool tuning" Model: Beta(α=12, β=3) → Beta(α=13, β=3)
After ~50 decisions per action type, the agent outperforms hand-written rules.
This compounds across your fleet. Every override makes the next decision smarter — for every agent in the tenant, not just the one that proposed it. Static runbooks don't improve when you follow them. LLMs don't remember what you corrected last Tuesday. This does.
Compound
Confidence compounds. Each agent graduates.
Each decision makes the model sharper. After enough corrections, an agent moves from Observe to Checkpoint to Autonomous for a given action class, not because you flipped a switch, but because its confidence earned it. Modes are per-agent, per-action: one agent graduating to Autonomous does not promote the others. Novel situations still escalate. Destructive actions always require approval.
Anatomy
One incident. Five moves. You only touch it once.
A real connection-pool saturation. Five steps. You approve one write.
Pager fires 15:24:03
prod-api CPU at 89%, sustained 3 minutes. Sansin is watching the same PagerDuty channel you are.
The agent triages 15:24:05
Sansin pulls logs via its MCP tools, spots the connection pool saturation, drafts a remediation.
tool: update_config args: pool_size=50, restart=true rationale: "pool exhausted, needs larger capacity + clean restart"
The gate scores the write 15:24:05
Before anything touches prod, Sansin scores its own proposal against this tenant's prior. Risky writes park for review.
action: update_config prior: Beta(α=8, β=12) · 34 prior observations risk: 0.58 conf: 0.71 verdict: PENDING (above auto-approve threshold)
You review 15:24:06
You see the pending write in the dashboard. Check the diff. Reject it with a reason in one click.
engineer: sarah@acme.io action: REJECT reason: "Don't restart prod during business hours. Try scale_pods first."
The agent learns 15:24:07
Your reason updates the Beta prior. Sansin reproposes a safer action, scores it, runs it, and the incident resolves.
prior updated: Beta(α=8, β=12) → Beta(α=8, β=13) new proposal: scale_pods(replicas=6) verdict: ALLOW (risk=0.18, conf=0.82) result: EXECUTED ✓
Every rejection makes the next one rarer. After ~50 decisions per action class, Sansin's score beats hand-written rules. You stop reviewing the easy ones.
Fleet view
One morning. Three agents. One audit log.
Same Thursday as the pain mirror above. Same tenant. Same gate. Three agents proposing tool calls against a shared per-tool prior. Five routine passes. One parked write that needed a human. Forty minutes you didn’t spend tab-switching.
DevOps agent 11:14:02
Pager fires on order-service. The agent pulls logs, proposes a scale from 3 to 6, files for approval.
agent: devops_primary tool: kubectl_scale prior: Beta(α=34, β=2) · 34 prior approvals risk: 0.18 · verdict: auto-allow
Coding agent 11:22:10
Opens a PR against auth.ts in a separate tenant service. Touches session middleware. Tests are green.
The gate scores: low risk (0.34) because gh_pr_create + green tests has 18 prior approvals in this tenant. Auto-allowed. You see it in the feed, not as a prompt.
Support agent 11:17:44
Ticket #8821 asks for a refund on a duplicate charge. The agent proposes stripe_refund $840.
agent: support_primary tool: stripe_refund prior: Beta(α=6, β=2) · cold start · amount $840 risk: 0.81 · verdict: park · reason: "amount > $500 in cold-start range"
One human touchpoint. The only thing in your dashboard that needed you was the support refund. Slack ping, one click to park → “cap over $500 needs lead.” That override updates the stripe_refund prior for the whole tenant. The coding agent and the DevOps agent inherit the learning for any tool they share.
You 11:18:11
Open the dashboard. Reject the refund with a reason. Sansin adds max_refund_amount=500 to the tenant prior for stripe_refund.
Next time any agent in this tenant proposes a stripe_refund over $500, the gate parks it without asking you to relitigate the rule. That's one override earning policy for the whole fleet.
Morning closes 12:02:17
Three agents. 47 tool calls. 46 auto-allowed. 1 parked. 1 override. 0 context-switches.
The audit log shows every call, every agent, every verdict, every prior update — on one screen, under one tenant, with one policy surface.
Try It
Watch the gate learn
These are real decisions a Claude agent would propose to Sansin — DevOps tool calls here, because that's the vertical with the most pre-trained priors. Click “Override” on the ones you disagree with. Watch the confidence bar shift as the gate learns your preferences for any agent in the tenant.
No overrides yet. The agent is using heuristic defaults (keyword matching on tool names). Click "Override" above to start teaching it.
Ask for a seat at the gate.
Sansin is onboarding teams one at a time while the gate earns its priors. Drop your email and we'll reach out when it's your turn.