The tap the model cannot make.

An assistant wired into a trading account is two completely different products depending on one detail: whether it can finish an action or only propose one. Everything else — how good the model is, how many tools it has, how nicely it writes — is downstream of that line. This is where amparo draws it, and what it takes to keep it drawn.

The read half is the easy half

Giving a model your account to look at is mostly a plumbing exercise. amparo's assistant has 22 read tools: wallet and exchange balances, open positions and open orders, trade history, profit and loss, the tax ledger, the wallets you follow and their books, market search and live prices, resolution terms, gas, membership status, the log of money runs. Ask it what your worst market is this month and it goes and finds out.

The one design rule that matters here is who supplies the identity. Every tool takes the user and the wallet address from your session token, never from the model. There is no user_id parameter for it to fill in, correctly or otherwise, so "look up account 4471's balances" is not a sentence it can express. Administrative routes aren't merely refused — they are absent from the tool list, so they don't exist as far as the model is concerned.

That gets you an assistant that can answer questions. The moment you want one that can do something, the entire problem changes shape.

What the write half actually is

The assistant has exactly one way to affect the world, and it is not an execution tool. It is a staging tool: it writes a row holding an action kind, its parameters, a random token and a 24-hour expiry, and it returns a link. That is the whole of its write capability.

Nothing is ordered. Nothing is signed. No balance moves. The row is inert — there is no server endpoint anywhere that runs it. Two routes touch it at all: one reads it back, one marks it consumed.

You then open it, and a card shows what would happen. One tap runs it; anything else doesn't.

Why that particular line, and not a stricter one

You could put the boundary higher: no write tools at all, the assistant explains and you go and do it. That is safer in the trivial sense and worse in practice, because it pushes the error-prone part — transcribing a market, a side and an amount across screens — back onto the person, which is exactly the work they wanted help with.

You could put it lower: let it execute, with rules. "Never spend more than $50." "Only these venues." The trouble is that a rules engine sitting between a language model and a key is a thing you have to be right about in advance, forever, for every action kind you ever add. The boundary above needs to be right once.

The strongest version of the argument is what it means for a total compromise. Suppose the model is jailbroken, the prompt is poisoned, and the server is answering with whatever an attacker likes. The worst reachable outcome is a card on your screen that says something misleading, because the last step needs a signature produced in an origin the page cannot script and the server cannot forge. That is a bounded failure, and bounded failures are the only kind worth designing for.

Prompt injection is not an edge case here — it is the input

The assistant reads market titles. Market titles are written by strangers. So are the labels on wallets people follow. Every tool result is, in the security sense, attacker-influenceable text arriving inside the model's context, and the honest way to build is to assume some of it is trying something.

Given that, two more mechanisms fall out — and both are about making the model's output matter less.

The model does not write the numbers

When a bet is staged, the server goes and reads the venue's actual best prices and computes the share count and payout itself, fee-adjusted. Then, when the card opens in your browser, it re-quotes a second time — walking the real ask ladder for your stake, because the first estimate used the price at the touch and an order any bigger than the shares resting there fills down the book at a worse average. If part of it has no seller, the card says so before you approve rather than after you've filled short.

So the model contributes intent — which market, which side, how much — and the numbers you are asked to approve come from somewhere it cannot reach.

The model cannot write a link

The other half of the injection surface is the chat bubble itself: text that looks like a URL, aimed at a page that does something. So any app-looking URL in the model's prose that was not returned by a tool during that turn is deleted before the message is rendered — and the system prompt tells the model this outright, so it does not spend output trying. Every actionable link on the screen came from the tool that staged the thing it points at.

What approval actually runs — which is nothing new

The last piece is the one that is easy to get wrong by being clever. When you approve, the executor does not call some special agent API. It calls the same prepare → sign → submit endpoints that the app's own buttons call, in the same order, with the same signing step in the middle.

That is a deliberate refusal to build a second way to move money. Every server-side check still stands in front of it: whether the venue is reachable where you are, whether your membership carries that part, whether the amount clears the venue's minimum. An assistant path that could quietly skip a minimum would not be a feature — it would be a less-tested second implementation of the most dangerous code in the product.

There are fourteen action kinds in total, and they are unglamorous on purpose: buy or sell an outcome on Polymarket, Azuro or Myriad; the cover leg of a matched bet; a swap; a bridge; open a perp or set its take-profit and stop-loss; start a bank run in or out; move money to or from your betting balance; save a wallet to your follow list. Four of those only start an asynchronous run, so the finish screen says "it's underway" rather than "done" — a distinction worth making when the thing you started takes a few minutes.

Some things have no action kind at all. Fixed-yield Earn and FX hedging have none; the assistant answers from data and opens the screen. Neither does the bookmaker leg of a matched bet, for the simple reason that no software can place that bet for you — it can only price the cover.

The parts that are uncomfortable

A design like this has costs, and a page that only listed the reassuring half wouldn't be worth reading.

• The token is a bearer token. Any authenticated user holding the link can open the card — deliberately, because the account you're logged into on your phone and the account your chat app is linked to are often different logins for the same person. It is argued safe on the grounds that approval always runs under the opener's own wallet and signature, so a bearer can only ever spend their own money. That is a real argument, and it is also a widening; it is the sort of thing that should be re-examined every time a new action kind is added.
• A card can be stale. Twenty-four hours is a long time in a market, which is precisely why a bet re-quotes when it opens rather than trusting what it was priced at. Approving something on Tuesday that was staged on Monday should feel like a fresh decision, because it is one.
• You cannot cancel mid-run. Once the steps start, the escape key is ignored. A multi-step action interrupted between signatures leaves money in an ambiguous place, which is worse than a few more seconds of waiting.
• The model is a third party. amparo's assistant runs on DeepSeek, which processes in China. Nothing at all is sent before you have read that and agreed, the agreement is timestamped and withdrawable on the spot, and it applies to the chat and nothing else in the product. Voice input adds a second processor for the transcription, in the United States, and the text lands in the input box for you to read before it is sent.
• It runs on a budget, and says so. Roughly a dollar of model spend per fortnight per account, enforced by refusing a round it cannot afford rather than cutting off halfway through one. A model that stops mid-sentence because the money ran out is a worse failure than a model that declines to start.

One more, less obvious: an answer that was cut off does not look like an answer that finished. A truncated completion means you saw the front of a reply, not a reply — so the server asks it to continue from exactly where it stopped, twice at most, and if it still isn't done the bubble is marked as cut. A dropped connection used to look identical to a completed one, which is its own small horror.

If you are building one of these

The transferable part isn't the code, it's the shape:

• Give the model a proposal channel, not credentials. It should be structurally unable to complete anything, not merely instructed not to.
• Render the confirmation from re-derived state, never from model output. If the model can write the number a human is checking, the human is checking the model.
• Put the irreversible step behind a secret the model's host does not have. Policy is a promise; a missing key is a fact.
• Treat every tool result as hostile text, and bound what a hostile result can achieve — here, a misleading card and nothing else.
• Write down that auto-approve, a wider token, or a new action kind reopens the whole analysis. Then actually reopen it.