AGENTIC SPEND / HUMAN-DEFINED LIMITS

Autonomous agents.
Deliberate spending.

Your agents spend money while you sleep. Set the limits.

Become a design partnerThe policy layer above x402 / USDC rails.

Your agentsPaid API request

AgentPayPOLICY CHECK

Spend cap

Service allowlist

Approval threshold

Payment railsx402 / USDC

PROPOSED ARCHITECTURE · EVERY PAYMENT CHECKS POLICY FIRST

THE SCENARIO

while (retry) {
  await paidApi.call();
}

A loop shouldn’t set your budget.

CONTROL BEFORE EXECUTION

The next invoice
shouldn’t be a surprise.

An agent calls a paid API. Then it loops. Without a spend policy in the path, a small request can become an expensive surprise. Put limits and approvals where the spending happens, and give every transaction a record.

FOLLOW A POLICY DECISION

Same agent. Different request. Clear outcome.

Explore the intended policy behavior. This is a local illustration: it does not connect a wallet, call paid APIs, or move funds.

POLICY EVALUATIONILLUSTRATIVE PREVIEW

Allow

Within policy

The service is on the allowlist and the request stays within the configured spending policy.

policy.evaluate(request)

Service approved · Budget available

Record the request and its policy decision, then allow the payment to proceed.

Illustration only. No payment is executed.

THREE LAYERS OF CONTROL

Define. Enforce. Reconcile.

Set the policy

Define per-agent spend caps, permitted services, and approval thresholds.

Check before payment

The proposed control layer evaluates spending against policy before execution. Over the limit? Block it or route it for approval.

Reconcile everything

One ledger for who spent what, on which service, against which policy.

Not another wallet. Controls above the rails you already use.

DESIGNED WITH TEAMS THAT SPEND

Real agents.
Real money.
Real constraints.

Built for

AI-agent teams already using paid APIs or services

Startups building on x402 or USDC rails

Founders who need limits on autonomous spending

Not the right fit for

—Agents that never call paid services

—Teams looking for a wallet or payment rail

WHAT THE PILOT IS DESIGNED TO DELIVER

Design the rules around your real constraints.

The design-partner phase is about understanding how your agents spend and where controls must sit.

01 / THE DELIVERABLE

Map the spending path

Identify which agents call paid services and where an authorization decision can be enforced.

02 / THE DELIVERABLE

Define the policy

Agree on spend limits, permitted services, approval ownership, and what happens when a check cannot complete.

03 / THE DELIVERABLE

Inspect the decision trail

Review the proposed record of each request, the applicable policy, and the resulting allow, review, or block decision.

A FEW THINGS TO KNOW

Before we
get started.

Clear expectations make a better pilot.

Is AgentPay a wallet or payment processor?

No. The proposed product is a policy layer above your payment rails. It does not replace custody, wallets, or settlement infrastructure.

Does this page enforce limits on my agents?

No. This is an interactive design preview. Its examples run only in your browser and do not connect to production agents or payment systems.

What happens when a policy check fails?

The design-partner discussion includes fail-closed behavior, escalation, and recovery. Those enforcement details must be agreed and tested before any production use.

Autonomous agents.Deliberate spending.

The next invoiceshouldn’t be a surprise.