All docs ▾
Getting started
Using Vex
Boards & Token Radar
Agent-composed market boards, Ask Vex, and the Book rail.
Most of what an agent tells you about a market is prose, and prose is a bad way to look at a chart. Vex has two answers to that. Boards, the surface the app titles Token Radar, are market-analysis cards the agent composes and attaches to a reply. The Book is the right rail that keeps your own position in view the whole time.
Boards, or Token Radar
When a question is really about a market, the agent calls BoardComposeand the reply arrives with a board attached instead of a wall of numbers: pool cards, the agent’s own written analysis, and optionally one annotated price chart. The figures on it are fetched and timestamped by the runtime at compose time rather than recalled by the model, which is why the agent is instructed to compose one proactively instead of typing a table by hand.
A board is a snapshot, not a live ticker. Every figure is read once, when the board is composed, and stamped with the moment it was read. Beside the agent’s prose sits a Safety panel whose rows come from the runtime’s own contract and liquidity checks, not from the model’s writing, and the tool contract forbids the prose from telling you to buy, sell, hold or size a position.
Boards are a presentation surface, not a control surface. BoardCompose is non-mutating: composing one moves nothing and approves nothing, and anything on it that would spend funds still becomes an approval intent like every other mutating action (Approvals). The engine also enforces that it is the only tool call in its batch, so a board is the end of a turn rather than a step inside one.
Each board carries Ask VEX, so you can question what you are looking at without leaving the card. The follow-up is handed to the composer and reaches the agent through exactly the same path as a message you typed yourself, under the same rules.
BoardCompose is session-bound: it is one of the tools Vex deliberately does not export to external coding agents over MCP, because the MCP path has neither the renderer nor the turn loop that a board needs. See Studio approvals & scope.
The Book right rail
The Book is the stack of cards down the right side of the app: your portfolio, as the app knows it, kept current by the background sync workers that decode settlements and refresh balances.
| Card | What it shows |
|---|---|
| Position | The aggregate position across your wallets. |
| Wallets | Every wallet in the install, EVM and Solana. |
| Balances | Per-token balances behind the position number. |
| Activity | What the agent has actually done on-chain, decoded. |
| Session | The state of the session you are in. |
| Trench Express | The merged launchpad card. |
That is the default order, and it is yours to change: the cards are draggable and the order you leave them in is remembered as a display preference in the renderer, never as anything that crosses into the privileged process.
The rail also has an inspect mode. While it is open it replaces the card stack with one tool call in full: which tool ran, whether it is pending, running, done or failed, and its complete arguments and result payloads, rendered whole and scrolled rather than truncated. It is the fastest way to answer “what did that tool actually return?” about a step in the turn.
On Robinhood Chain, balance scans cover a pinned token set. Your own swaps and bridges pin their tokens automatically, but a token that was airdropped or transferred in will not appear in balances or the Book until it is pinned. Ask the agent to use WalletTrackToken. See Wallets & custody.
AgentScan, locally
AgentScanis the agent’s read-only tool for its own recorded history, assembled from your local database: transactions, activity, balances, snapshots, a summary, protocol executions, and a mission baseline inside a mission run. It is how the agent answers “what did I do last week” from records rather than from its own recollection, and it is deliberately distinct from WalletBalances, which reads live chain state. Everything it reads is already on your machine, and the app has its own Agent Scan screen over the same records.
The name is also used for a separate public activity-explorer lane, which reports committed activity rows to a receive-only server. It is structurally limited: the event is built only from a named field list, so wallet addresses, sender addresses, session ids, nonces and free-text failure reasons have no line that reads them and cannot leave. The lane is off entirely when its ingest URL is unset, it is never on the money path, and no handler waits on it. That lane is covered under Privacy; the local views described above send nothing anywhere.
Where boards come from
Boards are produced inside ordinary agent turns, so everything that governs a turn governs a board: the tools the agent found through ToolSearch, the session’s wallet, and the Safety Contract. One exception is written into the tool itself: a board cannot be composed during mission setup, because drafting a mission is not the moment to pull live market data. Read Agent sessions for how a turn is built, and Missions for the unattended version.