ProceedGate DFaaS v1

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.

Integrate in 30 minutes Run a demo
Two outcomes
200 or 402
Hard enforcement
No token, no step
Thin boundary
Runner / middleware
  • Works with any agent framework (you control the runner/middleware).
  • Two outcomes only: 200 (go) or 402 (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.
Contract hard gate 
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)

1

Check

Before executing a step, your runner/middleware calls POST /v1/governor/check.

You get either 200 (allowed + token) or 402 (friction + decision id).

2

Resolve friction

If you receive 402, you decide how to resolve friction.

Payment (x402-style) is one mechanism. Roadmap: budgets, rate limits, manual approval.

3

Redeem

When friction is resolved: POST /v1/governor/redeem → 200 + token.

4

Enforce

Your runner verifies the token (JWT + JWKS) and proceeds. No token, no step.

Design principle
ProceedGate lives outside the agent loop. It’s enforceable because the runner won’t execute a costly step without a valid token.

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.

Good for technical buyers
Clear contract. Clear enforcement point. Clear failure mode. That’s what makes it deployable across teams.

Integrate in 30 minutes

Framework-agnostic: you don’t change model providers or agent frameworks.

Engineering checklist

  1. Identify costly steps: retries, browser actions, paid APIs.
  2. Add a gate call before each step: POST /v1/governor/check.
  3. Enforce: 200 → run step; 402 → stop + resolve + redeem.
  4. 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:sdk
Integration guide Spec

Why 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.

Docs

Everything you need to integrate and operate ProceedGate.

SPEC.md

Frozen v1 contract: endpoints, headers, semantics.

Contract

INTEGRATION.md

Framework-agnostic integration via runner or SDK.

Integration

OBSERVABILITY.md

Logs, headers, and metrics for decisions and latency.

Ops

ONE_PAGER.md

Technical summary for review, rollout planning, and internal alignment.

Buyer

Open 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:worker
GitHub repo

Integrate in 30 minutes

Keep your agent. Add enforceable cost-control.

Read integration guide View repo