regrun

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!