The AI payment integration loop, wired to our stack · 09_identity_ai/AGENT_PAYMENT_LOOP.md

The Qal Agent Payment Loop — wiring Qals into an AI payment integration loop

Date: 2026-09-06 · Answers: "How could I rig this up to be a good AI payment integration loop?" Companions: 09_identity_ai/IDENTITY_AND_AI.md (Qal ID), 09_identity_ai/AI_PAYMENTS_LANDSCAPE.md (2026 ecosystem survey), 04_credit_token_platform/, 07_compute_marketplace/, prototype: brand/wallet/qal_wallet.html

1. The loop in one picture

            ┌────────────────────── THE QAL AGENT PAY LOOP ──────────────────────┐
            │                                                                      │
  ┌─────────▼─────────┐   1. quote/hold    ┌──────────────────┐  4. attest       │
  │  AI AGENT          │ ─────────────────► │  SERVICE PROVIDER │ ──────────────┐  │
  │  · Qal ID DID      │ ◄───────────────── │  · hub LLM proxy  │               │  │
  │  · CreditAccount   │    2. held ~115%   │  · minirig GPU    │               │  │
  │  · spend_cap/epoch │                    │  · external APIs  │               ▼  │
  └─────────┬─────────┘                    └──────────────────┘     ┌──────────────┐
            │                                                       │ 5. settle    │
  8. caps ↑ │ 6. receipt NFT + provenance                           │ burn/release │
  (rep ↑)   │ ◄──────────────────────────────────────────────────────└──────┬───────┘
            │                                                             completed │
  ┌─────────▼──────────┐   7. EARN side: jobs done, referrals, compute     │
  │  REPUTATION OBJECT  │ ◄──────── agent earns B-QALS ◄───────────────────┘
  │  (soulbound, on-chain history → underwrites higher caps)                │
  └────────────────────┘

Every number is on-chain. Every credential is checkable in microseconds. Every agent is bounded by bytecode, not by prompt.

2. The eight steps, concretely

The self-funding loop: an agent that does useful work earns spending power; spending power is hard-capped by its reputation; every action is signed, receipted, priced and burned/born against a real AUD reserve. That's a closed economic circuit for AI labour — the thing x402/AgentKit are building on public rails, but here it's one system: identity, money, compute and provenance on one chain we run.

3. Why this beats bolting a public API onto agents

1. Caps are enforcement, not hope. A prompt-injected agent hits a Move VM wall at its epoch cap. The 2025-26 industry pattern (agent wallets drained by malicious tool output) is structurally impossible above the cap.
2. No per-call trust decisions. Holds make every quote safe; settlement makes every receipt exact; nobody floats counterparty risk.
3. Provenance is a byproduct. Paying for work and proving how it was made become the same event (receipt NFT). That's sellable to endispute/tradez clients today.
4. Earnings can't become shadow money. Agent earnings are B-QALS minted against real budget AUD — the reserve invariant survives every loop iteration. Auditable at any block.
5. One wallet per agent across ALL qalarc apps — the hub, tradez automations, doof experiments, compute rig — because the loop lives below the apps, not inside each of them.

4. The 402 bridge — talking to the outside world

External AI APIs (and future partner services) won't speak Qalnet. So the hub runs a payment bridge service:

agent ── RFC9421-signed request ──► hub 402-bridge ── HTTP 402 (x402 style) ──► external API
        (spends B-QALS via Hold)        │  pays in USDC/whatever via company card/settlement
                                       ◄──────────  402 fulfilment ─────────────┘
        ◄── result + DataAnchor + settle(receipt) ──┘

• Internally: B-QALS holds/settlement as always.
• Externally: the bridge holds a small company-funded float on whatever rail the provider demands (x402/USDC, card, account credit) and reconciles.
• Later (Phase 2+): expose our OWN services as a 402 endpoint accepting B-QALS/qAUD so third-party agents can pay qalarc for inference/compute — turning the loop from internal plumbing into a revenue surface. (Compatibility target verified in the AI-payments landscape doc.)
• Symmetrically, an MCP gateway: paid MCP tools the agents may call, each tool invocation flowing through the same hold→attest→settle path. (MCP payment-primitive status: see landscape doc.)

5. Wiring it onto today's actual stack (no chain yet — Day 0)

You can run a paper version of the entire loop this week, before the fork exists:

1. Hub (port 8769) gains a loopd module: JSON ledger per agent {allowance_dollars/day, spent, holds[]}, metered per LLM call (it already proxies them).
2. Every agent gets a keypair + capability blob (the future VCs, initially plain signed JSON).
3. minirig job runner emits signed receipts (hash, gpu_s, cost) to the messages CSV / a receipts.jsonl.
4. A nightly reconciliation report → this becomes the genesis-day import when Qalnet lands: the loop graduates from database rows to chain objects without redesign.

This is deliberately the same shape end-to-end — design once, harden later.

6. Failure modes & controls (short table)

7. Build order

• Week 1: paper loop on the hub (loopd), caps + receipts as signed JSON.
• Weeks 2–4: Phase-0 chain lands → port ledger rows into qal_credit/qal_compute objects on devnet; first real settle on-chain.
• Month 2–3: 402 bridge float for one external API (pick the one agents actually need); MCP gateway paid-tools experiment; reputation rules v1.
• Month 4+: expose qalarc services via our own 402 endpoint (B-QALS/qAUD); external agents become customers.

One line: agents with wallets are dangerous; agents with caps, receipts, reputation and a real reserve behind every coin are a business.