On September 28, Manus shipped Manus 2.0 and a separate app called Cue. Each agent you create in Cue gets its own email address, phone number, computer, and wallet. According to the launch post, an agent can "send messages, pay within the budget you set, and see a task through on its own machine." Cue is in early access and free with an invite code.

It isn't the only recent launch that puts money in front of an AI agent. In late August, MoonPay put its PayBox wallet inside Grok, where "Grok prepares the transaction. The user approves it with a passkey," as Fortune reported. Cue takes a different approach, giving each personal agent its own wallet and a spending cap. These launches show two quite different ways of authorizing agent payments.

Manus hasn't said what kind of wallet Cue uses, whether it holds crypto, or what its detailed approval rules are. Nothing here suggests Cue supports crypto trading or integrates with LeverUp. But the design question is worth asking before anyone points any budgeted agent at a trading venue: is a spending budget the right control for an agent that trades with leverage?

For most agent tasks, yes. For leveraged trading, it covers one variable out of several.

What a Budget Actually Measures

A budget limits outflow, meaning how much money can leave the wallet. That is the right control for the things Cue is built around: booking a table, paying an invoice, renewing a subscription. In those tasks, the amount spent is most of the financial risk. If the agent pays $80 for a dinner reservation, the direct spend is $80.

Leveraged trading splits that relationship in two. The margin an agent posts is what leaves the wallet. The notional exposure it opens is margin multiplied by leverage:

Margin posted Leverage Notional exposure Simplified margin-exhaustion move
$200 5x $1,000 ~20%
$200 50x $10,000 ~2%
$200 500x $100,000 ~0.2%

The last column is simple arithmetic (margin ÷ notional). It ignores fees, funding, and maintenance margin, so it is not a liquidation threshold. Still, a "$200 budget" means very different things in those three rows. Under typical isolated-margin rules, the loss on one position is largely bounded by the margin posted plus fees, subject to each venue's rules. But the budget says nothing about how fast that margin can be consumed, or how many times the agent can post it again. It also doesn't say how much market exposure you are carrying at any moment. (Liquidation usually triggers before margin hits exactly zero; How Liquidations Work on LeverUp covers the mechanics.)

A human who loses $200 in one wick usually stops to think. An agent with a refilling budget and an instruction to "keep trading the breakout" may not.

Four Things a Spending Budget Doesn't Cap

1. Leverage. The budget caps the input, and leverage decides the output. A spending-only constraint does not restrict leverage by itself, so the agent could pick very high leverage wherever the venue allows it.

2. Loss rate. A per-transaction cap doesn't limit aggregate spending. Ten $200 positions liquidated in an afternoon all fit inside "$200 per trade." A daily cap does limit total outflow, but it still doesn't measure open exposure or unrealized losses on positions already running.

3. Market scope. Paying a merchant has one counterparty. A trading agent can reach many markets, and some are thinner or more volatile than others. For example, LeverUp's MAG7 stock perps trade during U.S. market hours, and positions above 10x are closed at the market close. A budget has no idea which market the agent is using.

4. What else the wallet can do. A payment wallet is designed to send money. Whether a given agent wallet can also make arbitrary transfers depends on its design, and Cue's rules here are undisclosed. For a trading key, though, the goal is clear. AI Trading Agents Need Scoped Permissions covers this in detail. In short, a trading agent's key should be able to open and close positions and structurally unable to move tokens anywhere else.

Agentic Wallets vs Trading Keys: Three Approval Models

Model Example Who approves each action Good fit for
Per-transaction human approval MoonPay PayBox in Grok (passkey) The human, every time Occasional purchases, onboarding
Budgeted agentic wallet Manus Cue Payments within a user-set budget (detailed rules undisclosed) Recurring payments, errands, bookings
Scoped delegated trading key LeverUp 1CT Hosted Agent Nobody, inside the granted permissions Autonomous trading strategies

These models aren't competing, because each one answers a different risk question. Per-transaction approval keeps a human in the loop, which may not suit strategies that need to run unattended. A budgeted wallet fits spending. For trading, the more useful control is a key whose permissions are limited, not just its balance.

LeverUp's 1CT (One-Click Trading) system supports a Hosted Agent mode documented for "trading bots, copy-trading services, and managed strategies." The owner authorizes a separate signing key once onchain, optionally restricted to specific actions. That key signs trading intents with EIP-712. Supported intents are relayed onchain, so the agent doesn't need its own gas balance for them. The developer docs put it plainly: authorization "grants permission to trade, not to move tokens." Permissions are granted per action, so you can also leave out actions a strategy doesn't need, such as removing margin from open positions. The owner can revoke it with a separate onchain transaction that doesn't need the agent's cooperation. How to Build a Grok Bot Trading Agent on LeverUp walks through the setup.

That handles the fourth gap above. The first three still need explicit limits.

Where the Other Limits Should Live

Leverage caps, notional caps, market allowlists, and a daily loss stop all belong in code that sits between the model and the signing key, not in the prompt. A prompt is an instruction the model usually follows. An independently enforced signing policy can reject a noncompliant intent, as long as the model can't reach the key directly or edit the policy.

A minimal version looks like this:

  • Max leverage per market, checked before an intent is signed
  • Max total notional across open positions, not just per trade
  • Market allowlist, so the agent only trades what you've reviewed
  • Rolling loss stop, so once losses over 24 hours (realized plus unrealized, including fees and funding) pass a threshold, the wrapper refuses to sign anything that opens or increases exposure, still allows closes, and pings you
  • Log every intent and status response somewhere you actually read

AI Trading Agents Need a Decision Layer sketches this as a separate layer in the agent stack: models make decisions, and deterministic code enforces the rules.

Some limits also sit below the agent entirely. LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement, and risk management are handled at the protocol layer. Position limits, funding, and liquidation logic apply to the agent's trades the same way they apply to anyone else's, whatever the agent was prompted with. Those protocol limits don't substitute for user-specific risk controls, though. Your own risk tolerance is still yours to encode.

What This Means If You're Setting Up an Agent Now

Cue, Grok, and whatever ships next month are making it easier to give an agent money. For routine errands, a budget plus sensible permissions does most of the work. For leverage, use three layers:

  1. A scoped key that can trade but can't move tokens, limited to the actions your strategy needs, and that you can revoke from outside the agent
  2. A pre-submit rule layer that caps leverage, notional, markets, and daily loss
  3. Small size first, with logs you actually read, until the agent's behavior is boring

None of this makes the strategy profitable. These controls help constrain exposure and repeated losses from a bad strategy or a misread prompt, though they can't guarantee a maximum realized loss.

Trade on LeverUp: app.leverup.xyz