Cambio is an AI swap product. The AI is also kept on a deliberately short leash. This post is the explicit list of what the AI is responsible for, what the AI is not allowed to touch, and the reasoning behind every line on both lists.
The anchor post in this series defined what "AI swap" means at Cambio in broad strokes: a parser plus an explainer, with all decisions made by deterministic code. This post is the explicit list. What is the AI actually responsible for? What is it not allowed to touch? Why those specific boundaries? If you remember one piece from this entire series, the framework below is what to remember.
The "does" list
There are four jobs the AI in Cambio is responsible for. They are all conversational. They are all bounded.
1. Parse natural-language intent into structured fields
When you type "swap 0.3 BNB to USDT on BSC" into the composer, the AI is part of the parser stack that translates that string into a structured request: category=Swap, from=BNB, fromNetwork=BSC, to=USDT, toNetwork=BSC, amount=0.3. Most parses succeed at the regex layer without the AI ever being invoked. The AI handles the cases where the message is phrased oddly, contains typos, mixes natural language with shorthand, or is ambiguous about which field is missing.
2. Ask clarifying questions when fields are missing
If the message parses to "swap 100 USDT to BTC" with no network specified for USDT — which could be on Tron, Ethereum, BSC, or Solana — the AI generates the follow-up question. It does not silently pick a network. It does not assume the most popular one. It asks, in plain language, in the conversation thread.
3. Narrate the quote when it arrives
After the deterministic router produces a quote, the AI generates a one-sentence explanation of what happened. "Cambio's liquidity providers paying out on BSC in ~15 seconds, beats the best aggregator by 47 basis points." The narration is constrained to facts from the structured quote object. It does not embellish, opine on whether you should accept, or invent comparisons.
4. Return canned answers to the Help category
When the user asks a Help-category question — "Why is Cambio cheaper?", "What's the per-swap cap?", "How long does a swap take?" — the AI surfaces a pre-written answer from a curated list. The answers are static. They do not vary by user, by phrasing, by time of day, or by what we feel like saying that hour. The AI matches the question to the right answer; it does not generate the answer.
The "doesn't" list
These are the things the AI is not allowed to do, even when it could plausibly try. Each one is a deliberate choice with a specific reason.
1. Pick the route
The router is a state machine: validate the pair against the launch scope, check partner liquidity, fetch the live mid-market price, apply the chain-aware spread floor, apply the competitor guardrail, return the quote. Every step is deterministic code that runs the same way every time on the same inputs. The AI is given the quote object as a structured input; it cannot influence what the quote contains.
2. Hold keys or sign transactions
Settlement and signing infrastructure runs entirely separately from the AI surface, under hardware-backed key custody. The AI does not have an API to request signatures. It does not have an API to move funds. It does not have access to the seeds, the keys, or the signing service. Every payout is initiated by the deterministic router after the deposit confirmation event fires, never by the model.
3. Fetch prices
The mid-market price for every supported pair is read from an in-memory cache fed by a background price-oracle service. The AI does not call that service. It does not interpret market data. It does not predict where the price is going. If you ask 'what's BTC going to do tomorrow' in the composer, the Help category returns a canned answer that says we don't forecast prices and points to external resources.
4. Set policies
The per-swap cap ($15,000), the supported chains (six), the supported tokens (six), the spread floor (0.30% base, with chain-aware multipliers), the pill threshold (10 basis points) — all of these are configuration values in the deterministic stack. The AI does not consult them, override them, or interpret them. When a quote violates one (e.g., an amount exceeds the cap), the policy code rejects the request before the AI ever sees it.
5. Make safety decisions
If a deposit doesn't confirm in time, the policy code handles the refund. If a payout fails to a malformed destination address, the policy code handles the hold-and-contact flow. If a pair becomes temporarily inactive because partner liquidity is short, the policy code returns a hard reject. The AI is informed of these outcomes (so the explainer can describe them in plain language) but does not make any of the underlying decisions.
Why these specific boundaries
Three reasons. They are the same three reasons every time we tighten an AI scope at Cambio.
Verifiability
A user who wants to verify that a Cambio quote was fair can call the public API at api.cambio.one with the same pair, get the same quote, and reproduce the route. No AI is in the loop. The public API does not invoke a language model. The numbers match. If the AI were in the decision path, that verification would be impossible — a language model produces non-reproducible outputs even on the same input, and a user could not check whether they got a "fair" route or a coincidentally bad one.
Reliability
Language models go down. Frontier models occasionally have prolonged outages — provider incidents, capacity issues, regional rate-limiting, model versions being deprecated. If our router depended on the AI to pick routes, every model outage would be a Cambio outage. By isolating the AI to the conversational surface, we can degrade gracefully: when the model service is slow, the composer falls back to keyword parsing and deterministic templated narration. The trade still goes through. Users on Cambio in the middle of a model provider's incident will not even notice unless they look closely at the composer's response style.
Accountability
When a trade has an unusual outcome — the user gets a different amount than they expected, a pair is rejected when they thought it should be supported, a swap takes longer than estimated — we need to be able to answer the user's 'why' question. With deterministic code, 'why' is always answerable: this rule fired, here is the code path, here is the receipt. With AI in the decision path, 'why' becomes 'because the model said so,' which is not an acceptable answer to a user who lost money or time on a trade.
The gray-area cases
Worth being explicit about the cases where we could have plausibly given the AI more scope and chose not to.
When an amount is ambiguous — say the user types "swap a little BNB to USDT" — we do not let the AI infer "a little." It asks for an amount. We considered defaulting to a small fraction of the user's typical recent swap, but inferring intent on funds is exactly the kind of plausible AI helpfulness that creates accidents.
When a pair is not supported — say the user types "swap 0.1 ETH to MATIC" and Polygon is not in our launch scope — we do not let the AI suggest the 'closest' alternative pair. It returns the deterministic 'not supported' message with the list of supported chains for ETH (BSC, Tron, Solana, etc.) and lets the user choose. The temptation would be to say 'how about BNB instead?' but that crosses from clarification into recommendation, and recommendations on a financial product are a regulatory landmine we will not step on.
When a quote looks unusually wide — for example, when an obscure pair has thin Bestchange data and our spread floor is the only thing setting the rate — the AI does not soften the explanation. The narration is the same shape it always is: route, settlement window, basis-point comparison if applicable. We do not let the AI add 'this rate is wider than usual because the competitor data is thin' unless that exact phrase has been pre-written, reviewed, and approved as a canned explanation.
What this looks like in practice
A worked example. The user types "swap 100 USDT for 0.0001 BTC on Ethereum" into the composer. At current market rates, 100 USDT is worth about 0.0014 BTC — so the user is asking to receive a tenth of fair value.
The parser succeeds: category=Swap, from=USDT, fromNetwork=Ethereum, to=BTC, toNetwork=Bitcoin, amountOut=0.0001, direction=amount-out. The policy code runs: the Execute path computes the implied from-amount needed for this receive amount, which would be about 7 USDT — well below the $1 minimum that the pair requires. The policy returns a hard error: "Amount below minimum for this pair (USDT on Ethereum to BTC has a $20 minimum, you requested ~$7)." The AI is given the error and narrates it: "That receive amount comes out below the pair's $20 minimum. Could you try a larger receive amount or a different pair?"
What the AI did not do: it did not silently round up the amount to clear the minimum, did not assume the user meant 0.001 BTC, did not warn the user that the rate looked off from market. The policy code returned the deterministic answer; the AI translated it into a sentence. The user knows exactly what happened.
Where we would expand AI scope (and where we would resist)
Looking forward, there are places where adding AI capability makes the product better without crossing into territory that violates the rules above.
More sophisticated parsing of ambiguous queries — for example, recognising "convert" and "exchange" as synonyms for "swap," supporting non-English phrasings, parsing slang ("dump my BNB into stables"). All of these are still parsing. They translate user input into structured fields. The router decisions remain deterministic.
Multilingual support — running the same parser/explainer in Spanish, Russian, and Chinese. The router does not care what language the user typed in. The composer does. This is in our roadmap.
Where we will not expand AI scope, even when the temptation grows: route selection, price prediction, policy decisions, safety decisions. These boundaries are permanent. A future post about anything that looks like the AI deciding any of those things would be a betrayal of the trust frontier we set at launch.
Why this discipline matters
AI is a moving target. Models get better every few months. The category of things an AI can plausibly do well in a swap context expands continuously. The pressure to expand the AI scope to keep up with what is technically possible will be relentless.
We will not give in to that pressure for the parts of the system that touch user funds, user safety, or operational policy. The AI does what is on the list above. Everything else is deterministic. That is the contract. We will not surprise users by quietly migrating decision-making into a model and announcing it later.
The next post in the series goes specifically into the model-selection choice — why we chose Gemini 2.5 Flash Lite over GPT-5 or Claude for the parsing and narration jobs, and what would have to change for us to revisit that choice.
