> For the complete documentation index, see [llms.txt](https://surf-2.gitbook.io/surfliquid-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://surf-2.gitbook.io/surfliquid-docs/infra-and-intelligence/ai-planning-vs-execution-separation.md).
# AI Planning vs Execution Separation
Why Surf treats AI as an analyst, not a custodian or operator
Most AI systems in DeFi blur two very different jobs:
* Planning what should happen
* Executing what actually happens on-chain
When those are combined, you get a dangerous outcome: \
**An intelligent system that can move real money without hard boundaries.**
Surf separates these roles by design.
Surf can plan. Surf cannot execute freely.
Execution only happens if deterministic rules allow it.
This is the standard Surf introduces for how AI should touch real capital.
***
#### The Two Roles
#### **1. Planning**
Planning is off-chain intelligence.
Surf continuously analyses:
* Yield rates (lending, incentives, fees)
* Utilisation and liquidity depth
* Slippage and exit conditions
* Protocol risk signals
* Historical behaviour patterns
* Cross-chain opportunity sets (as enabled)
The output of planning is always the same kind of artefact:
**A proposed action plan**, for example:
* Withdraw from Venue A
* Redeploy into Venue B
* Adjust vault exposure percentages
* Shift liquidity ranges
* Pause activity due to risk triggers
Planning can be sophisticated.\
It can be wrong.\
It can change every minute.
But planning alone cannot move funds.
***
#### 2. Execution
Execution is an on-chain action.
Execution means:
* funds are withdrawn
* funds are deployed
* liquidity ranges are adjusted
* positions are closed
* capital is bridged
This is the part that can cause losses if mishandled. So Surf does not allow AI to execute freely.
Execution is only possible when all safety gates pass.
***
#### The Safety Gate Between Planning and Execution
Every proposed action from Surf must pass through the Surf control stack:
**Guardian Layer enforcement**
The Guardian Layer is the rule engine that decides what is allowed.
It enforces constraints such as:
* Protocol allowlists only
* Maximum exposure per venue
* Concentration limits
* Slippage bounds
* Liquidity exit depth requirements
* Rebalance thresholds after costs
* Circuit breakers on anomalies
* Route validation and invariant checks
If a single rule fails:
**Nothing moves.**
The action is rejected and logged.
***
#### Why This Separation Matters
**AI will be wrong sometimes**
That is normal.
The real question is:
When AI is wrong, does it become a suggestion or a loss?
In most systems, wrong actions still execute. **In Surf, wrong actions get blocked.**
That is the difference between automation and trust.
***
#### What Users Get From This Design
**Non-custodial automation**
Users keep custody through user-owned vaults.
Surf cannot:
* withdraw to an external wallet
* move funds outside the vault scope
* bypass constraints
* override user withdrawal rights
**Transparent and auditable behaviour**
Every action has:
* a reason
* a path
* a rule set
* an outcome
* an on-chain record
Users and institutions can verify how decisions are made.
***
#### A Simple Mental Model
Think of Surf like this:
* Surf is the analyst
* Guardian Layer is the risk committee
* User-owned vault is the custody account
* On-chain execution is the settlement system
The analyst can recommend.\
The risk committee can approve or reject.\
Custody stays with the user.\
Settlement only happens when rules pass.
***
#### Why This Is Foundational for Surf
Surf is not trying to be an “AI trading bot”.
It is building a category:
**AI-run on-chain savings and treasury automation that can scale because safety is enforced by architecture, not by trust.**
AI planning is flexible.\
Execution is deterministic.
**That separation is the difference between a demo and a financial system.**