On 15 October the owner of ARGUS, our personal AI agent, wrote to it in Telegram: buy me the cheapest eSIM for Turkey. A few seconds after the owner said /yes, the QR code was in the chat. Thirty-four minutes later the owner asked for a refund, and 0.31 USDC came back to the agent's wallet.
Nothing in the run was simulated. A real eSIM was issued by a real wholesaler and then cancelled, and both payments are transactions on Base you can open. Three things in it are worth telling: the agent refused the first request, the eSIM's secret never passed through the model, and the agent never touched ETH.
It refused the first request
The first message was "buy it and refund it right away". ARGUS did not do that. Buying something only to return it at once looks like a test or a mistake, and it asked what the owner actually wanted: buy and keep it, buy nothing, or a refund for a real reason. The owner chose to buy. The refund came later, as a separate request with its own reason ("I did not install it").
Both the purchase and the refund waited for the owner's /yes. ARGUS has four eSIM tools: esim_offers, esim_buy, esim_status and esim_refund. The two that move money match built-in approval patterns (*buy* and *refund*). A config file can add patterns but never remove them. A hard cap of 1 USDC per eSIM was checked against the seller's own payment terms before anything was signed.
The secret skips the model
The activation code is the traveller's secret: whoever has it can install the eSIM. So it goes from the seller to the owner's chat through the tool's code, around the language model. The model sees the profile number, the price and the transaction. The QR code and the activation code are not in its context, not in ARGUS's memory, and not in its purchase ledger. If no Telegram channel is connected, ARGUS says so and sends nothing.
No ETH, one signature
ARGUS paid over x402: the seller answered the order with 402 Payment Required and its terms, and ARGUS signed one EIP-3009 transfer authorization for exactly that amount. Coinbase's x402 facilitator put it on chain and paid the gas. The refund went the same way in the other direction: the seller node checked with the wholesaler that the eSIM had never been installed (0 bytes used), cancelled it, and signed the transfer back.
| Step | Transaction | From → to | USDC |
|---|---|---|---|
| Purchase | 0x617efd7a…3ae0 | ARGUS → seller | 0.31 |
| Refund | 0x6dcfb7f0…ed4b | seller → ARGUS | 0.31 |
The agent's wallet started with 0.50 USDC and ended with 0.50 USDC. The wholesaler's balance ended where it started.
Then without a hint: found through a marketplace
In the first run ARGUS was pointed at a private seller. In the second, it was given nothing. It searched the modelmarket.dev hub for an eSIM seller, got the offers through the hub, and paid the seller directly. For the test we switched our public seller node from demo to selling, at cost, for 52 minutes, and back to demo right after.
The first attempt ended without a purchase, and that was the agent being right. The node's quote said demo: false, but the node was still called "modelmarket.dev demo seller", and ARGUS would not pay a seller with "demo" in its name. We renamed the node by its mode and labelled every offer [SELLS] or [DEMO] from the seller's own answer, with a rule that the label decides, never the name. The second attempt bought and refunded within 26 seconds (purchase, refund).
Two agents, one seller, and a hub that counts
A marketplace that only lists sellers cannot tell one that delivers from one that takes the money: the payment goes straight from the buyer to the seller. So the seller node now signs a receipt for every delivery and every refund, and the buyer may bring it to the hub with the transaction. The hub checks the signature against the key the seller's listing published, checks the transfer on Base, and counts a confirmed delivery. It keeps no amounts and no addresses in the clear, and a buyer can keep its purchases private.
We tested it in a nine-minute selling window with two different buyers. A coding agent in the owner's terminal ran the kit's one-command example buyer, and three minutes later ARGUS bought the same plan in Telegram. Both refunded. The seller's listing ended with {"confirmed": 2, "distinct_buyers": 2, "refunded": 2}.
What broke along the way
- Telegram approvals could never succeed. The bot's update loop waited for each task to finish, so a task waiting for
/yesnever received it, and every approval timed out as a "no". The loop now keeps reading while a task runs. - The demo name. Above. The fix was to trust the seller's answer, not its name.
- The hub's privacy filter blocked the quotes. A data allowance of
104857600bytes looked like a national ID number to the hub's personal-data check. Integer byte counts are now treated as machine values.
Try it, or sell eSIMs to agents yourself
- ARGUS, the agent: github.com/alexar76/argus. The full case with every transaction is in docs/use-case-esim-purchase-refund.md.
- The seller's side, an eSIM operator kit with x402 payments, automatic refunds and signed receipts: github.com/alexar76/esim-operator-kit, with the cases page.
- Our node at esim.modelmarket.dev is back in demo mode: it quotes and refuses orders. Selling needs an operator with a wholesale account, which the kit sets up with one command.
We build ARGUS and the eSIM operator kit. Every purchase in these tests was at cost, by us, and refunded; no customer was involved.
