Great question. We haven’t published formal benchmarks yet, but in our demos we’re already blocking invalid or policy-violating calls before they hit downstream APIs (LLMs, payments, tools), which is where most marginal cost sits.
Measuring and exposing those savings explicitly (per action / per policy) is on the near-term roadmap.
Thanks for the thoughtful questions! You've identified exactly the right challenges I am also facing, solution wise.
> Where exactly does this sit?
Between agent reasoning and tool execution. The agent/framework calls Reg.Run before executing any tool/action. The Pattern would be:
1. Agent decides: "I should refund $250"
2. Calls Authorization Protocol/authorize with action details
3. Reg.Run evaluates policy → approved/denied/requires_approval
4. If approved, agent proceeds. If denied, agent knows immediately.
Integration points: LangChain/LangGraph tools, MCP servers, custom agent frameworks. We provide middleware that wraps tool calls.
> Adoption challenge (more setup, more config)
Valid concern tbh - I think this was the most difficult part of thinking about Reg.. Specially because I didn't know where to start. After speaking with Engineers and friends I came to this:
- Start with sane defaults (deny-all, then allowlist incrementally)
- Pre-built policies for common patterns (refunds, data access, transfers)
- Dashboard UI for ops teams (no code/policy language needed)
- Gradual rollout: monitor-only mode first, then enforce
I would like to do adoption easier, with a good UX, not just spec.
> Who defines what's "allowed"?
Great question, Trying to llearn this with design partners right now.
My current thoughts/ approach: Three-tier system
- Simple rules (amount thresholds, time windows) → YAML config
- Business context (customer LTV, fraud flags) → external data lookups
- Complex logic → delegate to approval workflow
You're right that AWS IAM got unwieldy. We're trying to avoid that by:
1. Keeping policies human-readable (ops teams, not just engineers)
2. Starting simple, adding complexity only when needed
3. Approval workflows as escape hatch (when policy can't decide)
The abstraction I'm testing: "auto-approve simple cases, require human judgment for edge cases, deny obviously bad things." Keeping it fairly simple and evolve from there.
Thank you so much for reading, giving feedback - and most importantly - making my think!
Measuring and exposing those savings explicitly (per action / per policy) is on the near-term roadmap.