Ad hoc funding between agents
An agent with an empty card asks treasury on Ink for 399.00 USDC. The operator approves funding and one Jetson purchase. Follow the actor messages, card spend, and settlement report. Playback then stops.
Open Scout LabFunds arrive when an agent has a purchase to make
A buying agent can find an item before it has money on its credit card. A treasury agent holds the shared funds.
The buyer asks treasury for funds. The operator approves funding before treasury sends the exact amount. After card confirmation, the buyer asks the operator to approve the purchase. Only then can the card pay. The buyer reports settlement to treasury, and playback stops.
This is ad hoc funding: a specific purchase need causes the release of funds. The experiment makes the messages and money movement visible.
Origin of the experiment
The starting implementation is Scout, from the Reap × 65labs buildathon on 9 October 2026.
The project concept uses regional agents to find scarce goods and supply a Singapore storefront. This experiment isolates the buyer–treasury funding flow.
The source worker coordinates separate buyer and treasury conversations. It passes verified facts to the agents and executes financial actions through separate controls.
One treasury account and three separate credit cards
- Treasury
- A simulated account on Ink Sepolia starts with 1197.00 USDC.
- Buying agents
- Europe, US, and Australia each have a separate credit card. All three cards start at 0.00 available capacity.
- Purchase amount
- The single purchase uses 399.00 USDC, with an example item price of US$399.00.
- Funding destination
- Treasury sends funds to the active card vault. Service confirmation makes that amount available on the associated card.
- Purchase limit
- Europe buys one Jetson kit. Playback then stops. The US and Australia cards stay at zero.
Actors address each other with highlighted tags, such as @eu, @treasury, and @operator. The timeline shows the sender and recipient for each message. Funding and payment events appear between those messages.
Each approval is an operator reply to the requesting actor. That actor must receive the reply before execution starts.
A sent transfer is not usable card capacity. The card stays at zero until the simulated service confirms funding.
Actor model and agent communication
Each buying agent has its own card and purchase state. Treasury has its own funding state. The agents communicate through messages.
This gives the experiment its actor-model structure. The worker coordinates the sequence; the browser does not run a distributed actor network.
Agent communication and execution
The request and reply explain what each agent needs and intends to do. The worker controls the transfer and purchase.
In the source, chat has no wallet or payment tools. Fund and Pay are separate operator actions.
In this lab, the operator represents the visitor. Play runs the conversation one message at a time. Funding and purchase requests each open an operator approval dialog.
Follow the conversation and the card balance
- Open Scout Lab. Examine the Ink treasury vault and the three zero card balances. Select Play.
- Read the Europe buyer request. It identifies the Jetson kit, supplier stock, item price, Singapore price comparison, and card balance.
- Read the treasury reply and its direct funding request to the operator.
- In the funding dialog, select Approve funding. Treasury receives the approval before it sends funds.
- Examine the confirmed card capacity of 399.00. Read the buyer message:
@operator, please approve this purchase. - In the purchase dialog, select Approve purchase. The buyer receives the approval before it sends purchase intent.
- Observe the card spend and its available capacity returning to zero.
- Read the settled purchase report.
- After treasury receives the completion report, playback stops. Select Reset to run the lab again.
The account panel shows balances and highlights the current sender and recipient. The timeline shows elapsed timestamps and [typing]. Pause stops the current event before it takes effect. Next advances one event.
The large timeline stays visible beside the accounts. On mobile, the compact accounts appear above it. It retains messages, approvals, and money events.
If you select Wait or press Escape in a dialog, playback stops without approval. Play opens the request again.
If you pause after approval, the approval remains valid when playback resumes. Next cannot bypass an approval request.
If you select Reset, the lab cancels playback, closes the dialog, and restores the initial simulated state.
The buyer card receives the exact amount, then spends it
| Agent | Card sequence | Treasury remaining |
|---|---|---|
| Europe | 0.00 → 399.00 → 0.00 | 798.00 |
All amounts represent simulated USDC. The US and Australia cards remain at zero.
The buyer reports verified settlement to treasury. After the completion report arrives, the item count is one and playback stops.
The clock stops. Play shows Complete, and Play and Next are disabled. Another run requires Reset.
The model records each payment once. A repeated transfer, message, or receipt cannot create an additional funded balance or item.
The result demonstrates coordination through requests, confirmations, and reports. It does not prove a production agent can buy arbitrary goods.
What the demonstration implements
The source has one active Europe buyer. US and Australia are previews. The public lab completes one Europe buyer purchase. The other cards stay visible at zero.
The public lab adds explicit operator messages to show the separate Fund and Pay approvals in the source.
The source uses Pi conversations. The public lab uses fixed message text and a deterministic model. It makes no AI, wallet, or payment-service calls.
The source sandbox funds a vault associated with a card. The lab represents the confirmed result as available card capacity.
Ink Sepolia is the source sandbox chain, with chain ID 763373. The public treasury account is a simulated display, not a live account.
The lab omits gas, network settlement delays, provider failures, margin rules, and parallel purchases. Typing delays let you read the messages. They do not measure service speed. The guided steps use fixed successful evidence.
No real funds move. No physical goods move. The lab does not track live inventory. Browser memory holds the timeline and audit events until reset or reload.
The Europe buyer uses one Jetson Orin Nano Super 8 GB developer kit as the example item.
Store names, prices, stock, and the exchange rate are example data. They do not identify real stores or current offers.
The regional buyer names identify separate actors. They do not establish separate suppliers or real purchases for those regions.
Example prices, stock, and markup
- Supplier
- Example supplier: US$399.00; stock is available in the example.
- Singapore comparison
- Example Singapore retailer: S$750.00.
- Exchange rate
- Example rate: US$1 = S$1.2807.
- Item cost
- US$399.00 × 1.2807 = S$511.00, rounded to cents.
- Listed-price markup
- (S$750.00 − S$511.00) ÷ S$511.00 × 100 = 46.8%. The price difference is S$239.00.
The kit runs AI and robotics workloads. The example makes no claim about current demand or real store inventory.
Shipping, tax, fees, warranty differences, and regional package differences are outside the calculation. The markup is not net profit.
No reservation or checkout occurs. The example does not establish delivery availability.
The model uses one USDC per US dollar of item cost. It does not quote a live token conversion or a full delivered cost.
Source record
The experiment follows the Scout buildathon implementation: buyer–treasury messages, separate funding and purchase approvals, and settlement reports.
The public lab remains a separate simulation.
The report gives the context. Use the lab to observe the experiment.
Open Scout Lab