Are any of you building AI agents that need to pay outside providers?
I’m building Timbro around a question I haven’t validated yet: when an AI agent buys data or work from an unfamiliar provider, what happens if the delivery is wrong or never arrives?
I built a browser sandbox where you can play both sides of a $250 dataset purchase. You can fund the deal, deliver the dataset, approve it, or dispute it. Every dollar is simulated—there’s no account or real payment involved.
I’d especially like to hear from people building agents that already purchase data, API access, or services:
How do you handle payment approval and failed delivery today? Would a flow like this be useful in your project, or is the problem still too far ahead of actual usage?
You can try the sandbox here: https://timbro.tech/sandbox/
Candid feedback is welcome, including reasons you wouldn’t use it.
I’d separate spending approval from delivery acceptance. In my own agent workflows, the agent can prepare the purchase, but a human or a budget policy approves the spend; after that I only close the job when a provider receipt, webhook, or verified output matches the order. If delivery is silent or ambiguous, I keep it in submitted/unresolved instead of letting the agent mark it done.
That separation makes a lot of sense. Preparing a purchase, authorizing the spend, and accepting delivery should be distinct steps. I also like your point about keeping ambiguous delivery unresolved.
In your workflows, what evidence would you trust enough to release payment automatically—if any? Or would you always want a human to approve that final step?
The problem is closer than it looks on the consumer side. Meta Muse already runs purchases and errands from a per-user cloud VM, and Amazon blocking its shopping agent this week shows merchants are reacting before any dispute layer exists. What I've seen in community builds is people hand-rolling exactly your split: agent drafts the order, human taps approve, agent checks the confirmation email before marking it done. Examples are collected at shipwithmuse.live/categories/errands-and-personal-agent (I maintain shipwithmuse.live). The gap is the "delivery never arrived" branch; nobody automates that yet.
Thanks for sharing this. The distinction between an order confirmation and actual fulfillment is exactly what I’m trying to understand.
Do you have one concrete example from those builds where the order was accepted but delivery failed? What did the human have to do to resolve it?
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?
Thanks! I’d spend more time understanding how builders handle purchase approval and failed delivery before building out the full flow. The feedback here is already helping with that.
Which part reminded you of a decision you made with Xstream4K?
Have conversations with agent builders revealed actual recurring purchases from unfamiliar providers, or is the payment-and-dispute problem still mostly a future workflow?
I haven’t established recurring purchases from unfamiliar providers yet. That’s one of the main assumptions I’m trying to test with this post.
The feedback so far has surfaced workflows around human spend approval and checking delivery, but that doesn’t yet establish a need for a separate payment-and-dispute layer.
Are you seeing this happen in actual agent workflows today, or does it still feel premature?
I’d be cautious about calling that workflow established yet—the recurring purchase piece is the part I’d want to see. Could be useful to compare notes off-thread sometime, if you’re open to it.
Agreed, the recurring purchase piece is still unproven, and I want to keep that distinction clear. Happy to compare notes off-thread. What’s the easiest way to message you?
Email works best on my side — happy to continue there. Drop your address here and I’ll pick it up there.
Sounds good! rodriguezmj1720@gmail.com
Delivery acceptance is the part I’d make explicit: payment authorization and completion should be separate state transitions, with a timeout and an evidence requirement for each. That gives the agent a safe way to retry or escalate without silently treating an unverified response as a successful purchase.
That’s helpful, especially making the timeout and evidence requirements explicit for each step. I’d also want retries to avoid creating a duplicate purchase when the original outcome is unknown.
Have you encountered that ambiguity in a real workflow? What did you have to do to resolve it?