Agents that book flights, provision cloud resources, or subscribe to APIs need spending authority. Tilde Pay addresses the plumbing gap between agent reasoning and actual fund movement by provisioning isolated bank accounts with transaction-level controls. The infrastructure challenge is not just issuing a card. It is building authorization primitives, reconciliation flows, and compliance boundaries that survive agent hallucinations, API retries, and multi-vendor billing cycles.
The Problem: Agents Need Money, Not Just API Keys
Most agent frameworks assume payment happens outside the loop. A human approves a purchase, then the agent executes. That breaks down when:
- An agent needs to spin up compute instances across AWS, GCP, and Azure in response to load spikes.
- A research agent subscribes to 15 different data APIs with varying billing models (per-call, monthly, usage tiers).
- A travel agent books flights and hotels that require immediate payment confirmation.
Passing a corporate card to an LLM is a compliance nightmare. Hardcoding spending limits in code does not scale across vendors. You need account-level isolation, transaction-level authorization, and a reconciliation layer that survives partial failures.
Tilde Pay’s Architecture: Isolation and Authorization Primitives
Tilde Pay provisions a dedicated bank account per agent or per task. The key primitives:
Account Provisioning
Each agent gets a virtual account with its own routing and account number. This is not a shared wallet with sub-ledgers. It is actual account isolation at the banking layer, which means:
- Transactions appear as separate line items in bank reconciliation.
- Compliance audits can trace spending to a specific agent instance.
- Account closure terminates all payment authority immediately.
Authorization Flow
Tilde Pay separates agent intent from fund transfer using a three-stage gate:
- Pre-approval limits: Set maximum transaction size, daily spend cap, and allowed merchant categories at account creation.
- Transaction request: Agent calls a payment API with vendor, amount, and justification metadata.
- Execution gate: Tilde Pay checks limits, validates merchant category, and optionally triggers human confirmation before releasing funds.
This is not a post-hoc audit trail. The authorization happens before the payment clears.
Reconciliation and Retry Handling
Agents do not get instant confirmation. Payment networks have latency, retries, and partial failures. Tilde Pay exposes:
- Transaction state: Pending, authorized, settled, failed, or reversed.
- Idempotency keys: Agents can retry payment requests without double-charging.
- Webhook callbacks: Async notification when a payment state changes, so the agent can proceed or roll back.
This matters when an agent books a flight that requires payment within 10 minutes but the bank takes 45 seconds to authorize.
Security Boundary: Where Agent Reasoning Stops
The critical design choice is where to place the trust boundary. Tilde Pay assumes:
- Agents are untrusted: They can hallucinate vendor names, misinterpret pricing, or retry failed transactions indefinitely.
- Pre-approval rules are code: Spending limits, merchant whitelists, and transaction caps are enforced in Tilde Pay’s infrastructure, not in the agent’s prompt.
- Human-in-the-loop is optional: For low-risk transactions (under $10, known vendors), the agent proceeds automatically. For high-risk (new vendor, large amount), a human approves via webhook.
The agent never sees raw account credentials. It calls a payment API with a scoped token that only works for its assigned account.
Implementation: Payment API and State Management
Here is the flow for an agent provisioning a cloud instance:
# Agent reasoning layer
def provision_compute(region: str, instance_type: str):
cost_estimate = estimate_cost(instance_type, hours=24)
# Request payment authorization
payment = tildepay.authorize(
amount=cost_estimate,
vendor="aws.amazon.com",
category="cloud_compute",
metadata={"region": region, "instance": instance_type},
idempotency_key=f"compute-{region}-{timestamp}"
)
if payment.status == "authorized":
# Proceed with provisioning
instance_id = aws.create_instance(instance_type, region)
# Confirm payment after successful provisioning
tildepay.confirm(payment.id, resource_id=instance_id)
elif payment.status == "pending_approval":
# Wait for human confirmation
wait_for_webhook(payment.id, timeout=300)
else:
raise PaymentDenied(payment.rejection_reason)The agent does not handle retries, settlement delays, or refund logic. Tilde Pay’s SDK manages state transitions and exposes a simple status enum.
Trade-offs: Compliance vs. Autonomy
| Dimension | High Autonomy | High Compliance |
|---|---|---|
| Authorization | Pre-approved limits, auto-execute | Human confirmation per transaction |
| Account scope | One account per agent fleet | One account per agent instance |
| Reconciliation | Async webhooks, eventual consistency | Synchronous confirmation, block until settled |
| Failure mode | Agent retries indefinitely, risk of duplicate charges | Agent blocks on payment, task timeout |
| Audit trail | Transaction metadata in logs | Full justification required, stored immutably |
Most deployments start with high compliance (human approval, narrow limits) and gradually expand autonomy as trust builds.
Failure Modes and Observability
Agents fail in ways traditional payment systems do not expect:
- Hallucinated vendors: Agent tries to pay “OpenAI API v2” instead of “api.openai.com”. Merchant whitelist catches this.
- Retry storms: Agent retries a failed payment 50 times in 10 seconds. Rate limiting and idempotency keys prevent duplicate charges.
- Partial task completion: Agent provisions 3 of 5 cloud instances, then payment fails on the 4th. Reconciliation layer tracks which resources were created and triggers cleanup.
Tilde Pay exposes:
- Transaction logs: Every authorization attempt, approval decision, and state transition.
- Spending dashboards: Real-time view of agent spend by category, vendor, and time window.
- Anomaly alerts: Spike in transaction volume, new vendor, or spending pattern deviation.
The observability layer is not optional. Without it, you cannot debug why an agent burned through its budget in 10 minutes.
Deployment Shape: Hosted Service vs. Self-Hosted
Tilde Pay runs as a hosted service with API access. The alternative is self-hosting the payment orchestration layer, which requires:
- Banking partner integration (Stripe Issuing, Marqeta, or direct bank API).
- PCI compliance for storing account credentials.
- Transaction state machine with idempotency and retry logic.
- Webhook infrastructure for async payment confirmations.
Most teams start with the hosted service and migrate to self-hosted only if they need custom authorization logic or operate in a regulated industry with data residency requirements.
Technical Verdict
Use Tilde Pay when:
- You have agents that need to pay for third-party services (APIs, cloud resources, SaaS subscriptions) without human intervention.
- You need account-level isolation for compliance or cost tracking.
- You want transaction-level authorization controls that survive agent hallucinations.
Avoid it when:
- Your agents only interact with internal systems (no external payments).
- You already have a corporate card program with sufficient controls.
- Payment latency is unacceptable (real-time authorization adds 1-3 seconds per transaction).
The infrastructure cost is not just the Tilde Pay fee. It is the operational overhead of monitoring agent spending, tuning authorization rules, and handling reconciliation failures. If your agents spend less than $1,000/month, the complexity may not justify the control.