> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usecompassai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How it works
> Follow a single deposit from prompt to position, and see how Compass keeps it routed.
> Compass turns one sentence into a multi-chain USDC route. You write rules and a prompt; the agent plans, checks the plan against your rules, executes via Circle Gateway, and keeps the position monitored.
This page walks through what happens after you type a single instruction into
Compass. The example is intentionally small — five USDC, one venue — so each
step is visible.
## A single route, end to end
You open the Compass app, your smart account already deployed on Arc, and type
something like:
```
move 5 USDC to the best lending venue on an L2
```
Five things happen, in order. Only the first one involves an LLM.
The amber step is the only one that touches an LLM. The green steps are
deterministic code — they're also what runs every time the loop re-evaluates
your position, with no LLM involvement.
### 1. The chat agent compiles your intent into a plan
The LLM reads your message, asks for any missing detail (which venue, if your
request matches more than one whitelisted option), and outputs a **structured
plan** — not a transaction. The plan is data: source chain, target chain,
target protocol, amount, the rules this plan must satisfy.
The LLM never signs anything. It hands the plan to the deterministic layer and
steps out. See [Chat agent](/architecture/chat-agent).
### 2. The policy engine checks the plan against your rules
Before anything moves, the plan is evaluated against the rules attached to
your account:
* Is the **target protocol** on your protocol whitelist?
* Is the **target chain** on your chain whitelist?
* Does the route stay inside your **risk band** (1–10)?
* Is the amount within your **per-route cap** and **daily cap**?
If any check fails, the plan is rejected and you see why. No transaction is
broadcast. See [Policy engine](/architecture/policy-engine).
### 3. The executor moves USDC across chains via Circle Gateway
Once approved, the executor uses [Circle Gateway](/cross-chain/circle-gateway)
to move USDC from Arc to the target chain. Gateway gives Compass a **unified
USDC balance** across supported chains, so the move settles in under a second
without a traditional bridge.
The cross-chain step is signed as a **`BurnIntent`** — an EIP-712 message, not
a transaction. This matters because intents can be retried and re-broadcast if
indexers lag, without re-signing or risking double-spend. See
[Four-step pipeline](/cross-chain/four-step-pipeline).
### 4. The executor opens the position on the target chain
USDC lands on the target chain at the **same address as your Arc account**
(via CREATE2). The executor then calls the
target protocol's deposit function from that address. You now hold a position
on the target chain, owned by your smart account.
Gas on Arc was paid in USDC — no second token, no paymaster. On the target
chain, gas is handled by a chain-appropriate paymaster. See
[Arc-native gas](/cross-chain/arc-native-gas).
### 5. The deterministic loop keeps watching
From this point on, the agent re-evaluates your position whenever something
material changes — a yield-source update, a state change on your account,
an in-flight intent settling. Each evaluation is a **pure function** that
recomputes the best route given current data:
* If rates shift and a better venue appears **inside your rules**, the agent
prepares a new plan and runs steps 2–4 again.
* If anything trips your rules or fails a safety check, the agent **pauses**
rather than reroutes mid-flight.
* Every evaluation writes a structured `EvaluatorThought` to the audit log,
whether or not it produced a transaction.
The LLM is not in this loop. It only re-enters when you ask it something in
chat. See [The deterministic loop](/architecture/deterministic-loop) and
[Audit trail](/architecture/audit-trail).
## What this means in practice
The five steps above show the property that makes Compass different from a
typical "AI yield bot":
* The LLM is the **interface**. It explains intent and answers questions.
* The deterministic loop is the **engine**. It runs every tick, on every
account, with no LLM in the path.
* Your **rules are the boundary**. They live on-chain, on your smart account.
Neither the LLM nor the agent operator can route outside them.
A typical user account spends under 5% of its ticks involving the LLM at all.
The rest is plain, auditable code.
## Next steps
What the agent can do, what it can't, and how your rules are enforced.
Run the example above with your own testnet USDC.
The full architecture — accounts, agent, and cross-chain layer.
Configure your risk band, protocol whitelist, and chain whitelist.