Two weeks ago, Boris Cherny — head of Claude Code at Anthropic — said something on stage that changed how I think about building infrastructure:

"I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude."

Then Peter Steinberger dropped a post that put a name on it: loop engineering. The idea is simple but the implications are massive. You stop writing prompts. You start designing the systems that prompt agents for you. The agent enters a cycle — reason, act, observe, repeat — and it doesn't stop until the goal is met or the budget is hit.

That immediately raised a question for me: if agents are going to run autonomously in loops, what happens when the "act" step involves money?

I run Spraay — an x402 payment gateway with 170+ endpoints across 16 chains. Agents already call our batch payment, escrow, and payroll endpoints through an MCP server. But every one of those calls was fire-and-forget. The agent sends a request, gets a response, and has no way to know when the payment actually settles unless it polls. Polling burns tokens. Burned tokens cost money. And in a loop, that cost compounds on every cycle.

So we made the gateway loop-native. Here's what that means and how we built it.

The Core Problem: Loops Need Callbacks, Not Polling

A loop-engineered agent doing batch payroll looks like this:

1. Observe: "10 employees need to be paid"
2. Reason: "I should batch these through Spraay"
3. Act: POST /api/v1/payroll/execute
4. Observe: ??? (How does the agent know it settled?)
5. Reason: ??? (Should I retry? Move on? Something failed?)

Without callbacks, step 4 becomes a polling loop inside the main loop. The agent hammers GET /status every few seconds, burning inference tokens while it waits. That's wasteful for one payment. For an agent running continuous operations — processing invoices, releasing escrow milestones, executing weekly payroll — it's unsustainable.

The fix: let agents pass a callback_url on any request. When the operation resolves, the gateway POSTs a signed payload to that URL. The agent's loop receives the event, processes it, and decides its next action. No polling. No wasted tokens.

The Implementation: Three Layers

Layer 1: Webhook Infrastructure

The core system is a Supabase-backed event queue with a background dispatch worker. When an agent includes callback_url in a request body, the gateway:

1. Generates a per-event HMAC signing secret
2. Queues the webhook event in a webhook_events table
3. Returns the normal response plus a webhook object containing the webhook_id and webhook_secret
4. A background worker polls for pending events and delivers them

Here's what an agent sees when it includes callback_url:

POST /api/v1/batch/execute
{
  "token": "USDC",
  "recipients": [
    { "address": "0xAlice", "amount": "1000.00" },
    { "address": "0xBob", "amount": "2500.00" }
  ],
  "sender": "0xEmployer",
  "callback_url": "https://agent.example.com/hooks/spraay"
}

Response:

{
  "success": true,
  "contract": "0x1646452F98E36A3c9Cfc3eDD8868221E207B5eEC",
  "batch": {
    "recipientCount": 2,
    "totalAmount": "3500.00",
    "fee": "10.50",
    "totalWithFee": "3510.50"
  },
  "transaction": { ... },
  "webhook": {
    "webhook_id": "afe9c56e-8074-4f5e-ae22-2eabd8cdcec0",
    "webhook_secret": "whsec_b8559497b5cf43...",
    "subscribed_events": ["batch.created"]
  }
}

When the batch settles, the gateway POSTs to the agent's URL with HMAC-SHA256 signed headers:

POST https://agent.example.com/hooks/spraay
X-Spraay-Signature: sha256=abc123...
X-Spraay-Event: batch.settled
X-Spraay-Delivery-Id: afe9c56e-...
X-Spraay-Timestamp: 2026-06-23T12:00:00.000Z
User-Agent: Spraay-Webhooks/1.0

{
  "id": "afe9c56e-...",
  "event_type": "batch.settled",
  "timestamp": "2026-06-23T12:00:00.000Z",
  "attempt": 1,
  "data": {
    "recipient_count": 2,
    "token": "USDC",
    "total_amount": "3500.00",
    "total_with_fee": "3510.50"
  }
}

The agent verifies the signature with the webhook_secret from the original response, processes the event, and moves to the next step in its loop. If delivery fails, the worker retries with exponential backoff — 30s, 60s, 120s — up to 3 attempts before marking the event as exhausted.

The key design decision: the callback system is entirely optional. Agents that don't pass callback_url see zero changes in the response. Every existing integration keeps working exactly as before.

Layer 2: Safety Guards

This is the part that kept me up the night before shipping. If agents are running autonomous payment loops, what happens when a loop has a bug?

Picture this: an agent receives a batch.settled callback, and its loop logic says "great, now pay the next batch." It fires another payment. Gets another callback. Fires again. The loop has no exit condition, and the wallet drains in minutes.

That's not a Spraay bug — it's an agent design bug. But users will blame the gateway. So we built three safety layers that protect wallets regardless of how the agent is designed:

Per-key rate limiting on payment endpoints. Every API key gets a budget of 10 payment-moving calls per minute. A legitimate batch operation (even 200 recipients) is a single API call. You'd need to fire 10 completely separate operations within 60 seconds to hit the limit. A runaway loop hits it in seconds. Responses include X-RateLimit-Remaining headers so well-built agents can self-regulate.

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests to /api/v1/batch/execute. Limit: 10 per 60s.",
  "hint": "If this is a loop-engineered agent, ensure your loop has proper termination conditions."
}

Duplicate payment detection. If the same API key sends an identical payload (same recipients, amounts, token) within 60 seconds, the gateway returns a 409 instead of processing a duplicate payment. The response tells the agent how to override this if the duplicate is intentional (add a unique idempotency_key field).

Webhook delivery cooldown. No callback URL receives deliveries faster than every 5 seconds. This caps the maximum possible loop cycle speed. A legitimate agent processing results never needs sub-5-second callbacks. A runaway loop would.

All three guards are per-API-key, so a large company with heavy legitimate usage gets their own rate budget. And all three are additive — they sit in the middleware chain without touching any existing endpoint logic.

Layer 3: Wiring Endpoints

Making an endpoint callback-aware takes about 8 lines of code. The webhook middleware attaches a webhookCallback helper to every request that includes callback_url. Endpoint handlers just check if it's there:

// Existing handler code builds the response...

// Add webhook callback (only fires if agent passed callback_url)
if (req.webhookCallback) {
  response.webhook = await req.webhookCallback('batch.created', {
    recipient_count: recipients.length,
    token: token.symbol,
    chain: 'base',
    total_amount: totalAmount,
  });
}

return res.json(response);

We wired up 6 handlers across 3 endpoint families:

• Batch payments — batch.created on execute
• Escrow — escrow.created, escrow.funded, escrow.released, escrow.disputed across all state transitions
• Payroll — batch.created with type: 'payroll' in the payload

Escrow is the most interesting case because it's inherently a state machine. An agent loop managing a freelance contract can now receive callbacks at every stage: escrow created → funded → work completed → released. Each callback gives the agent the information it needs to decide its next action without polling.

What This Enables

With loop-native callbacks, an agent can now do things like:

Automated payroll processing: Observe invoice queue → batch employees → receive settlement callback → update books → repeat next pay period.

Escrow milestone management: Create escrow → fund on approval → receive work → release on delivery → handle disputes. All event-driven, no polling.

Multi-chain treasury operations: Monitor balances across chains → batch rebalancing payments → confirm settlements → repeat.

The x402 per-call pricing model actually works in our favor here. Loop-engineered agents make more calls per task (that's the nature of the cycle), which means more microtransactions flowing through the gateway. Making the integration smoother via callbacks means agents are more likely to use Spraay as their payment layer — which means more volume, not less.

What We Didn't Build (and Why)

We deliberately chose not to build a loop orchestration framework. The agent ecosystem already has plenty of those — Claude Code, OpenClaw, LangGraph, CrewAI. What it doesn't have is payment infrastructure designed for autonomous agent loops.

Spraay's position is the settlement layer. We don't tell agents what to do or how to loop. We make sure that when the "act" step in any loop involves moving money, the infrastructure is fast, secure, signed, and event-driven.

Try It

Spraay's loop-native webhooks are live today across batch, escrow, and payroll endpoints. Add callback_url to any request body and you'll get signed callbacks when the operation resolves.

• Gateway: gateway.spraay.app
• Docs: docs.spraay.app
• MCP Server: smithery.ai/servers/Plagtech/Spraay-x402-mcp
• BPA Spec: docs.spraay.app/bpa/1.0/

If you're building loop-engineered agents that handle money, I'd love to hear how you're thinking about the payment layer. What safety guarantees matter most to you? What event types would you want callbacks for?

Spraay is an x402 payment gateway — 170+ endpoints, 16 chains, batch payments as the primary differentiator. Built by a solo founder in public.

Follow the build: @lostpoet on X, @plag on Farcaster.