Economic governor for agents
Stop runaway agents. Enforce cost caps and sane behavior.
ProceedGate is an economic governor for AI agents: a hard gate that blocks expensive steps
unless the agent has a short-lived proceed_token.
It’s built for production teams: predictable integration, auditable decisions, and clear failure modes.
200 or 402- Works with any agent framework (you control the runner/middleware).
- Two outcomes only:
200(go) or402(friction). - Enforcement sits outside the agent loop (and survives prompt failures).
- Micro-proof: Used in early production setups to stop retry storms and runaway tool calls before they burn budget.
POST /v1/governor/check
→ 200 { proceed_token }
→ 402 { decision_id } + x402-* headers
POST /v1/governor/redeem
x402-tx-hash: …
→ 200 { proceed_token }
No token, no step.Problem
If you run agents in production, you’ve seen this:
LLM retry storms
Regeneration loops quietly burn money.
Browser automation loops
Playwright-style sessions stall and rack up runtime.
Paid API spam
External paid APIs get hammered when the agent gets confused.
“Just add guardrails in the prompt” is not enforceable. ProceedGate makes it enforceable.
What ProceedGate does
ProceedGate introduces a mandatory checkpoint before your agent executes a costly step.
If the step is within policy/budget: you get a short-lived token and proceed.
If not: you get friction (402) and the agent cannot continue until friction is resolved.
This is hard gating, not “suggested behavior”.
How it works (simple contract)
Check
Before executing a step, your runner/middleware calls POST /v1/governor/check.
You get either 200 (allowed + token) or 402 (friction + decision id).
Resolve friction
If you receive 402, you decide how to resolve friction.
Payment (x402-style) is one mechanism. Roadmap: budgets, rate limits, manual approval.
Redeem
When friction is resolved: POST /v1/governor/redeem → 200 + token.
Enforce
Your runner verifies the token (JWT + JWKS) and proceeds. No token, no step.
Built for production teams
Developer-first integration, with the operational clarity larger teams need.
Auditable decisions
Every check produces a decision record you can log, trace, and reason about. No “hidden policy in prompts”.
Operable by default
Built-in observability hooks (headers, logs, metrics) so you can debug why a step was blocked—without dumping raw data.
Low-friction rollout
Thin middleware boundary: start by gating the most expensive steps, then expand coverage as confidence grows.
Integrate in 30 minutes
Framework-agnostic: you don’t change model providers or agent frameworks.
Engineering checklist
- Identify costly steps: retries, browser actions, paid APIs.
- Add a gate call before each step:
POST /v1/governor/check. - Enforce:
200→ run step;402→ stop + resolve + redeem. - Verify token via JWKS:
GET /.well-known/jwks.json.
Thin middleware boundary. If you hate it, you can remove it later.
SDK
Use the framework-agnostic Node SDK:
npm i @proceedgate/node
npm run demo:sdk
PROCEEDGATE_TX_HASH=0xstub npm run demo:sdkWhy this works (when “policies” don’t)
External enforcement
Decisions are enforced in the runner/middleware, not in prompt text.
Two-outcome API
Predictable integration: only 200 or 402.
Context binding
Optional canonical context_hash can be bound into the token to prevent reuse.
Short TTL
Tokens expire quickly (default 45s) to reduce replay.
Pricing
Simple, predictable pricing. Start free, upgrade when you need more.
- 2k checks / month
- 1 project
- 3-day log retention
- Preset policies only
- Community support
- 25k checks / month
- 3 projects
- 14-day log retention
- Basic analytics
- Email support
- 1M checks / month
- 5 projects
- 30-day log retention
- Custom policies (up to 10)
- Webhooks + alerts
- Priority support
- 5M checks / month
- 25 projects
- 90-day log retention
- Unlimited custom policies
- SSO + audit logs
- SLA + dedicated support
Annual: Pay yearly and get 2 months free (17% off).
FAQ
Is x402 payment how ProceedGate makes money?
No. Payment is an enforcement primitive (pass-through). ProceedGate is priced as SaaS on policy decisions, auditability, and ops features.
How much do I need to evaluate it?
You can validate the core promise in minutes: 3 allowed attempts followed by a deterministic 402 hard stop. Run npm run demo:storm:block for the proof.
Do I need to change my agent framework or model provider?
No. You add a small enforcement boundary (runner/middleware) that calls ProceedGate before costly steps.
What happens when the governor is unavailable?
Your runner chooses the failure mode: fail-open (proceed) or fail-closed (block). The reference runner supports both.
Docs
Everything you need to integrate and operate ProceedGate.
SPEC.md
Frozen v1 contract: endpoints, headers, semantics.
ContractINTEGRATION.md
Framework-agnostic integration via runner or SDK.
IntegrationOBSERVABILITY.md
Logs, headers, and metrics for decisions and latency.
OpsONE_PAGER.md
Technical summary for review, rollout planning, and internal alignment.
BuyerOpen source reference implementation
This repo ships a working Worker + Runner: Cloudflare Worker (Governor API) + Node runner (enforcement).
npm install
npm run smoke
# deploy governor
npm run deploy:workerIntegrate in 30 minutes
Keep your agent. Add enforceable cost-control.