A practical way to set an agent’s first limits

Budget for a task

Start by describing what you expect the agent to do. A research assistant testing a small tool purchase has a different spending pattern from an agent running repeated experiments. Use a narrow task and a modest test budget first, then examine the results before expanding the allowance.

Use both controls

The monthly limit bounds cumulative spending in a UTC calendar month. The per-purchase limit bounds a single request. A €100 monthly limit paired with a €10 per-purchase limit lets you test several small purchases while preventing one request from consuming the whole allowance.

Review rather than guess

Check paid and declined simulation attempts to understand how the limits behave. A decline is useful feedback: the wallet may lack funds, a limit may have been reached, or the card may be frozen. Adjust controls deliberately rather than increasing every limit at once.

Choose an initial test budget

For an early test, list the actions you expect rather than starting with a large round number. If the task includes three simulated purchases near €5 each, a €20 monthly allowance and a €6 per-purchase limit give the exercise a narrow shape. A €7 attempt should fail; three €5 attempts may fit if wallet funds remain available. These numbers are an illustration, not a universal recommendation. The useful practice is to connect each control to the task and write down the expected result before running it. That makes an unexpected result easier to investigate.

Change one variable at a time

When a request is declined, resist changing the monthly cap, purchase cap, and wallet balance together. First identify which condition prevented the purchase. If the amount exceeds the purchase cap, changing the wallet balance will not solve that condition. If the wallet is empty, a larger monthly allowance will not create funds. Make a single change, repeat the scenario, and compare what happened with your expectation. This approach turns simulation into a controlled experiment. It also makes it easier to explain the outcome to someone who did not configure the original agent.

Keep a review habit

Limits deserve another look when the task changes. An agent that once evaluated a single research tool may later be asked to perform a wider set of experiments. Review its transaction history, current purpose, and expected purchase sizes before adjusting access. If you need to pause spending, freezing the card provides a direct control without treating every limit as an emergency switch. When the test ends, review whether the connection key is still needed. Thoughtful limits are part of an ongoing workflow rather than a number chosen once and forgotten after the first successful attempt.

Distinguish a ceiling from a target

An allowance describes the maximum permitted by a control; it does not tell an agent that it should spend up to that number. If the task can be completed without any simulated purchase, that can be a good outcome. Explain the task’s objective separately from the funds available to support it.

For example, “evaluate whether a tool is needed” is different from “spend €20 evaluating tools.” The first leaves room for a no-purchase result. This distinction is useful when reviewing behavior: spending less is not automatically failure, and using the entire allowance is not automatically evidence of useful work. Pair the numerical limits with a description of what success looks like. Then review whether each attempt contributed to that objective rather than treating budget consumption as a measure of progress.

Record the reason for a change

When you raise a limit, write a short note in your own testing record explaining the scenario that motivated the change. Perhaps the expected purchase amount changed, or you want to run more repetitions within the same month. A concrete reason helps you avoid accumulating larger permissions through a sequence of unexplained adjustments.

After changing the setting, inspect the agent’s current limits again before continuing. This catches a mistaken assumption about which agent or card you edited. Repeat a small test that should fit the new boundary, then one that should remain outside it. If the task has ended, consider whether the allowance still serves a purpose. Reviewing controls at natural task boundaries is often easier than trying to reconstruct why an old configuration was chosen weeks after the experiment finished.