(no title)
regrun | 1 month ago
> 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!
No comments yet.