Search for "AI expense management" and you will find a hundred products that use AI to help humans track their receipts and categorize their transactions. That is not what this post is about. This post goes deeper: the architecture of agent expense management, the specific workflows that make it operational, and the patterns that emerge when you run agents with real spending authority at scale. ## Why Agent Expense Management Is a Different Problem Human expense management has decades of established tooling and process. Expensify, Brex, Ramp — the category is mature. But every tool in this category assumes the same basic model: a human made a purchase, the human has context about why, and the expense management system captures that context through receipts, categorization, and approval workflows. AI agent spending breaks this model in five specific ways: ### 1. No human made the purchasing decision When an agent buys a $7 dataset to complete a research task, no human selected that dataset or approved that specific purchase. The agent made an autonomous spending decision within its delegated authority. The expense record cannot include a human's explanation of "why" — it needs to capture the task context, the agent's decision parameters, and enough information to reconstruct the reasoning after the fact. ### 2. Transaction velocity is machine-speed A human employee might submit 5-20 expense reports per month. An AI agent running autonomously can generate dozens of transactions per day. A fleet of agents across a team can produce hundreds. The expense management system needs to handle this volume without requiring per-transaction human review — the review has to be pattern-based and exception-based, not per-item. ### 3. Attribution goes to tasks, not people Human expense systems attribute spend to employees and departments. Agent expense systems need to attribute spend to tasks, workflows, and agent identities. "Marketing spent $5,000 this month" becomes "the content research workflow spent $340 across 47 tasks, averaging $7.23 per task, with three tasks spending more than 2x the average." The granularity of attribution is fundamentally different. ### 4. Non-deterministic spending patterns A human buying the same thing twice will spend roughly the same amount. An AI agent running the same task twice might spend different amounts depending on which data sources it accesses, which APIs it calls, and what prices those services charge at the time. Agent expense baselines are statistical, not deterministic — you need to track distributions, not fixed amounts. ### 5. Proactive controls, not reactive review Human expense management is largely reactive: the purchase happens, the receipt is submitted, a manager approves or rejects it. Agent expense management must be proactive: spend limits are set before the task runs, the card balance enforces the ceiling in real time, and anomalies trigger alerts before the budget is exhausted. By the time you are "reviewing" agent expenses, the money is already spent. The controls have to be in place before the agent starts. ## The Foundation: Per-Task Card Isolation Everything in agent expense management flows from one architectural decision: issuing one card per task. When every task gets its own card, you get automatic isolation. All transactions on card X belong to task Y. There is no ambiguity about attribution, no shared spending to untangle, and no risk of one task's spending affecting another task's budget. The card is the boundary, and the card's balance is the ceiling. With AgentCard, this looks like: ``` agent-cards cards create --amount 10.00 ``` The command returns a card ID. You record that card ID against the task ID in your system. Every subsequent transaction on that card is automatically attributed to that task. When the task completes, you close the card. The card's transaction history is a complete, isolated audit trail for that task's spending. ## Transaction Data: What Gets Captured When an AI agent makes a purchase with an AgentCard virtual card, the following data is captured for each transaction: - **Card ID:** The unique identifier for the card, which maps to your task ID. - **Merchant name:** The name of the merchant as reported by the card network. - **Transaction amount:** The exact amount charged, in the transaction currency. - **Currency:** The currency of the transaction. - **Timestamp:** When the transaction was authorized. - **Authorization status:** Whether the transaction was approved or declined. - **Merchant category code (MCC):** The merchant's category classification in the card network. ## Webhook-Based Transaction Logging For production expense management, real-time MCP queries are not sufficient. You need a persistent transaction log that captures every event and stores it with full task context. This is where webhooks come in. AgentCard sends webhook events for card lifecycle and transaction events. The pattern for building an expense management system on top of webhooks is: 1. **Receive the webhook event.** Each event includes the card ID, event type, and event-specific data (transaction amount, merchant name, etc.). 2. **Verify the signature.** The webhook includes an HMAC-SHA256 signature in the `X-Agent-Cards-Signature` header. Verify it before processing. 3. **Enrich with task context.** Look up the card ID in your card-to-task mapping and attach the task ID, agent ID, workflow label, and any other context you recorded at issuance time. 4. **Store in your logging system.** Write the enriched event to your expense logging datastore — a database table, a log aggregator, or whatever your team uses for operational data. 5. **Evaluate alert conditions.** Check whether the transaction triggers any alert conditions: spend exceeding a threshold, declined transaction, unexpected merchant category, velocity anomaly. The result is a persistent, enriched transaction log where every entry includes both the financial details (what was spent, where, when) and the operational context (which task, which agent, what workflow). ## Attribution Reports: Understanding Where Money Goes Once you have a transaction log with task context, you can build attribution reports that answer the questions agent expense management actually needs to answer. ### Per-task spend reports The most basic report: for each task, show the total spend, the number of transactions, and the list of merchants. Compare actual spend to the authorized budget (the card's load amount). This report tells you whether tasks are spending within their budgets and identifies outliers. ### Per-workflow aggregate reports Group tasks by workflow type and compute aggregate statistics: average spend per task, median spend, standard deviation, total spend for the period. This tells you whether workflow budgets are calibrated correctly and reveals trends over time. ### Per-merchant spend analysis Group transactions by merchant to understand where agent money goes. This reveals patterns that are not visible at the task level. ## Anomaly Detection Patterns Automated anomaly detection is essential for agent expense management at scale. Here are the patterns that matter: ### Budget ceiling proximity Alert when a task spends more than 90% of its budget. ### Declined transaction alerts Every declined transaction means the agent tried to spend more than it was authorized to. ### Spend velocity anomalies Monitor the rate of spending across all agent cards. A sudden spike might indicate a bug in an agent loop, a misconfigured workflow, or (in the worst case) a compromised agent. ### New merchant detection Flag transactions at merchants that agents have not previously used. ### Per-task transaction count outliers If a typical task makes 2-3 transactions and a new task makes 15, something is different. ## Dashboard Review Patterns During initial deployment, establish a weekly review cadence. The review should take 15-20 minutes. ## Building Reports for Finance Teams At some point, someone from finance will ask for a report on agent spending. They will not be familiar with task IDs, MCP tools, or card-per-task architecture.