> ## 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. # System overview > The three layers that make up Compass — off-chain agent, on-chain smart account, and cross-chain settlement — and how they fit together. > Compass has three layers. An off-chain agent generates and evaluates plans, an on-chain smart account enforces them, and Circle Gateway moves USDC between chains. A single audit trail spans all three. This page is the map. Each layer below has its own dedicated page that goes deeper. ## The three layers system overview diagram The solid arrows are the **execution path**: chat → plan → policy check → session key → smart account → (optional) cross-chain settlement. The dashed arrows are the **audit path**: every component writes to a shared trail. ## Layer 1: Off-chain agent The off-chain layer is where decisions are *proposed and evaluated*. Nothing in this layer can move funds directly — it produces plans that the on-chain layer either accepts or rejects. It has four components: * **Chat agent.** The LLM-facing interface. It reads user messages, asks for missing detail, and emits structured plans. It is the only component that touches a language model. See [Chat agent](/architecture/chat-agent). * **Deterministic loop.** A Rust evaluator that ticks on a fixed cadence, re-evaluates every account, and proposes routes when better venues appear. Pure functions, fully reproducible. No LLM in this loop. See [The deterministic loop](/architecture/deterministic-loop). * **Policy engine.** Checks every plan — whether from the chat agent or the deterministic loop — against the rules attached to the user's account. Rejects out-of-policy plans before they reach the on-chain layer. See [Policy engine](/architecture/policy-engine). * **Audit trail.** Records every tick, every plan, every check, every decision. See [Audit trail](/architecture/audit-trail). A useful frame: the chat agent and deterministic loop are two **sources** of plans, the policy engine is the single **gate**, and the audit trail is the **record**. The LLM is in source-1 only. Source-2 runs on every account every tick with zero LLM cost. ## Layer 2: On-chain smart account The on-chain layer is where funds *actually move*. It is per-user — every Compass user has their own smart account, deployed at a deterministic address. It has two components: * **Diamond account.** An ERC-2535 Diamond holding the user's USDC and managing facets for each supported venue. The user is the sole owner. See [Diamond account](/contracts/diamond-account). * **Session key.** A scoped key the agent uses to call whitelisted functions on whitelisted venues. The session key cannot withdraw, cannot upgrade the account, and cannot change the rules. See [Session keys](/contracts/session-keys). The smart account enforces the policy *again*, on-chain, on every call. This is why the trust model is the contract, not the operator — even if the off-chain layer were compromised, calls outside the session key's scope would revert. See [Trust & security model](/overview/trust-security). ## Layer 3: Cross-chain settlement When a route requires moving USDC from one chain to another, the executor uses [Circle Gateway](/cross-chain/circle-gateway). Gateway gives Compass a **unified USDC balance** across supported chains, so cross-chain moves settle in under a second. Two properties of Gateway matter for the architecture: * **`BurnIntent` is a signed message, not a transaction.** The intent can be retried after indexer lag, re-broadcast, or replayed without re-signing. This is why the deterministic loop's retry behavior is safe. * **Same address across chains.** Your Diamond is deployed on Arc when you first set up the account. On every other supported chain, the Diamond is **lazy-deployed** the first time you stake there — at the **same address**, via CREATE2 with a matching deployer salt. USDC that lands on the target chain is always owned by the same address that signed on Arc. See [Four-step pipeline](/cross-chain/four-step-pipeline) for the exact sequence. ## How the layers interact A single route, traced through all three layers: 1. **User → chat agent** (layer 1). User types something like `move 5 USDC to the best lending venue on an L2`. 2. **Chat agent → policy engine** (layer 1). The LLM emits a plan. The policy engine checks it against the user's rules. 3. **Policy engine → session key** (layer 1 → layer 2). Approved plan becomes a session-key-signed call. 4. **Session key → Diamond account** (layer 2). The smart account re-validates the call at the contract level and executes. 5. **Diamond account → Circle Gateway** (layer 2 → layer 3). Cross-chain transfer if needed. 6. **Diamond account on target chain → venue** (layer 2). The deposit call is made from the same address. 7. **Every step → audit trail.** Off-chain reasoning, on-chain tx hashes, and Gateway intent IDs all land in the same record. For the same walkthrough from the user's perspective, see [How it works](/overview/how-it-works). ## What's in each section The rest of the Architecture group covers each piece in detail: What runs on every tick, why it doesn't use an LLM, and how it stays reproducible. How rules become checks, and what happens when a plan fails. The LLM layer, the structured-plan handoff, and the fabrication detector. Every tick recorded as a structured EvaluatorThought. For the on-chain side, see [Smart contracts](/contracts/diamond-account). For the cross-chain side, see [Cross-chain](/cross-chain/circle-gateway).