Building Transfer: autonomy with boundaries

Give the task a boundary

An agent can be useful without having unlimited access. Before it spends, it needs a clear answer to three questions: what funds can it use, how much can it spend, and what happens when a request goes beyond those limits? Transfer starts with those questions rather than treating controls as an extra layer.

One wallet, individual rules

Transfer gives an owner one shared EUR simulation wallet. Each agent has a virtual test card with a monthly limit and a per-purchase limit. The wallet is the source of funds; the card defines the agent’s allowance. An allowance does not move money into a separate pot.

Make the result visible

Connecting an agent is only the beginning. Owners also need to understand what happened afterward. Transaction history, card status, and remaining spending limits belong in the same workflow. Transfer currently runs entirely in simulation, letting people explore that workflow without moving real money.

Work through a concrete scenario

Consider a research agent that needs to evaluate a small paid tool. The owner gives it a €50 monthly allowance and a €10 per-purchase cap, then adds €100 of test money to the shared wallet. A simulated €8 purchase can fit both limits. A €15 request cannot, even though the wallet has enough funds. This is a useful distinction: a balance answers whether money exists, while a limit answers whether this agent has permission to use it. Run both attempts and inspect the outcome. The point of the exercise is to make the boundary understandable before expanding the task.

Separate instructions from enforcement

A prompt can explain what an agent should buy, why the task matters, and which alternatives it should consider. It should not be the only place a spending rule exists. A model may misunderstand an instruction, encounter conflicting content, or choose an unexpected amount. Transfer’s simulation checks card status, limits, and wallet funds when processing a purchase. That gives the workflow a concrete boundary beyond the agent’s own reasoning. Good task instructions still matter, but they serve a different purpose: helping the agent make useful choices inside the permissions it has already been given.

Review before expanding access

After the first few attempts, review the activity rather than immediately increasing the allowance. Did the agent check its wallet first? Did it explain a decline clearly? Did the amount match the task? These observations are more useful than simply counting successful purchases. You can keep the budget small while improving the task description or integration. If the workflow behaves as expected, adjust one control at a time so you can understand the effect. Transfer remains a simulation environment throughout this process: no merchant receives a payment, and no virtual test card can be used at checkout.

Make ownership obvious

A spending workflow works better when someone can explain who chose the limits and why. In Transfer’s current personal workspace model, the owner manages the shared wallet and agent controls. The agent receives scoped access to its own tools. That separation should be visible in how you set up a test: the owner defines the boundary, and the agent works inside it.

Avoid giving a connection a vague purpose such as “do anything useful.” A description tied to a particular task makes its activity easier to review. You can then compare a purchase with the purpose that justified access in the first place. If the purpose changes, revisit the controls instead of assuming yesterday’s allowance still makes sense. This approach does not require a complicated policy document. A short task description and a clear expected outcome are enough to make an early simulation much more understandable.

Measure understanding, not just completion

A useful agent should be able to explain the state it sees. Before a simulated purchase, ask it to describe the wallet funds and the applicable limits. Afterward, ask what changed. If it reports that a merchant was paid or that a real card was issued, the explanation is wrong even when the underlying simulation completed correctly.

This gives you a second dimension for evaluating the integration. One dimension is whether the tool enforced the configured boundary. The other is whether the agent represented the result accurately to the person using it. Both matter for a dependable experience. Keep examples small enough that you can check the numbers yourself, and use the transaction history as evidence. The objective is a workflow that remains understandable when something succeeds, something is declined, or a connection cannot be authenticated.