Show HN: Reg.run - Decoupling AI "thinking" from API execution
3 comments
The separation between “agent reasoning” and “execution authority” is definitely becoming a real design pattern.
what kinds of actions people are most afraid to let agents execute today. Is it mostly infra mutations, or business-facing actions like refunds/credits too?
Interesting approach. Have you measured cost savings from blocking invalid calls early?
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.
Measuring and exposing those savings explicitly (per action / per policy) is on the near-term roadmap.
Hi HN,
I’ve spent the last few months looking at how we deploy autonomous agents. The current standard is basically: "Put it in a system prompt and hope the LLM doesn't hallucinate a $50k refund."
As someone who has managed organizational authority for a decade (People Ops), this felt like a massive liability gap. Prompt engineering is probabilistic; security needs to be deterministic.
I built Reg.run to move the "Stop Button" out of the prompt and into the execution layer.
How it works technically:
The Sidecar: We use a local WASM-based proxy that sits next to the agent.
The Protocol: It intercepts Model Context Protocol (MCP) or standard API calls in real-time.
Policy-as-Code: Every action is checked against a rigid schema (e.g., MaxSpend: 100) before it’s signed and sent.
Performance: Sub-1ms latency. No data leaves your VPC.
It’s early, but the goal is to provide a physical "human-on-the-loop" gate mandated by the EU AI Act (Article 14) without breaking the autonomy of the agent.
I’m a solo founder and I’m around to answer any questions about the WASM implementation or the permission logic. I'd love your feedback on this.