From a new workspace to your first agent

Fund the test wallet

A new Transfer workspace begins with zero funds. Start by adding test money during onboarding. The balance belongs to the shared wallet, and it remains simulation money throughout the workflow. Choose an amount that makes the scenarios you want to test easy to follow.

Create an agent with a purpose

Give the agent a recognizable name and choose monthly and per-purchase limits. Its virtual test card belongs to that agent and uses the workspace’s wallet. Keep the initial task narrow enough that you can tell whether the spending behavior makes sense.

Connect and inspect

Generate a private connection key and configure your MCP client using the documented instructions. Ask the agent to inspect its wallet before trying a simulated purchase. Review the resulting transaction and try an over-limit request to see the boundaries working.

Prepare a small, repeatable task

Before creating the connection, choose a simple scenario that you can explain in one sentence. For example, ask a research agent to inspect its allowance and simulate an €8 tool purchase. Give it a per-purchase cap above that amount and enough monthly allowance to run a few tests. Keep the starting wallet balance visible so the expected balance after a successful simulation is obvious. The example is a testing exercise, not a real merchant purchase. A narrow task makes it easier to check the integration without wondering whether a complicated prompt changed the agent’s interpretation.

Check the connection before spending

After generating a private key, add it to the intended client’s private configuration and verify that the connection can inspect the agent’s wallet. Confirm that the returned identity and limits match the agent you created. This read step catches configuration mistakes before you test a mutation. If the client reports an authentication problem, check the key’s status and the endpoint origin rather than creating a second wallet or changing spending limits. Use placeholders when sharing the configuration with someone else. The real key should remain private even if the surrounding example is public.

Close the loop after the first attempt

Once the simulated purchase completes, inspect the transaction and compare the wallet balance with your expected result. Then test a request that should be declined so you can see both paths. Ask the agent to explain what happened in plain language, including that the purchase was simulated. If the integration was only an experiment, revoke the key when you finish. If you plan to keep using it, retain a clear record of the agent’s purpose and current limits. The first useful result is a repeatable, understandable workflow, not simply a green success message.

Try a second agent deliberately

Once one connection behaves as expected, a second agent can help you understand the shared-wallet model. Give it a different name and limits so you can recognize its activity. Inspect both agents before and after a simulated purchase, and observe how the wallet balance changes for the whole workspace.

This exercise makes overlapping allowances concrete. One agent’s remaining monthly allowance does not reserve money against another agent’s activity. Each purchase still depends on current shared funds and the card’s own rules. Keep the amounts small enough that you can calculate the expected outcome without tools. If the result is surprising, review the initial setup before increasing access. The goal of a second connection is to clarify the model, not to make the first test more complicated than necessary.

Turn the experiment into a repeatable walkthrough

After the first successful exercise, write a short walkthrough using placeholders instead of the real key. Include how to inspect the wallet, what limits you chose, which simulated request should pass, and which should be declined. Record the expected balance change so another reader can verify the outcome.

Keep the walkthrough tied to the current product. Do not describe future live-payment capabilities as steps someone can perform today, and do not include real merchant checkout instructions for a simulation card. If you share screenshots, label the money as test funds and remove credentials. A repeatable walkthrough is more useful than a one-time demonstration because it gives you a baseline for checking future changes. You can return to the same small scenario when an integration or client configuration changes.