Agent sessions

An agent session is a conversation that can act. You type; Vex chains real tool calls inside the turn (balances, research, quotes, swaps, bridges) and streams the result back into the transcript. In a restricted session, which is the default, every mutating call stops and waits for your approval before it runs. See Approvals & the Safety Contract.

Sessions come in two kinds. Agent mode is the one-shot conversational mode described on this page: it may chain many tool calls in a turn, but it does not loop on its own; when your request is satisfied it returns a final reply. Missionmode is the autonomous one: a frozen contract the agent pursues unattended, inside a time-box and a set of stop conditions you accepted first. If the work is “keep doing this until X”, you want Missions instead.

Working with sessions

The sessions list is the left rail of the app. From it you can create a session, pin the ones you keep returning to, rename them, branch one, export the transcript to a Markdown file, and delete it. Branching creates a new session seeded with a copy of the transcript up to and including the message you branched from, so you can try a different line; the source session is never rewritten.

Two settings are per-session rather than global, so different work can run under different conditions:

The model itself is not a per-session choice. Vex runs one model for every session, taken from the provider and model id configured during setup, and the chat header reads that back so you can see which one is active.

How the agent finds tools

Vex ships 11protocol integrations. None of their tools sit in the model’s context by default, because a prompt carrying every schema would be mostly noise. The protocols reference breaks the surface down namespace by namespace.

Instead there is exactly one door: ToolSearch, the only entry point to the protocol surface. It carries three modes.

• Search. A short intent phrase in plain English, ranked against the catalog. Five rows by default, up to twenty when you raise the limit.
• Select. Makes tools the agent already knows by name callable again, up to forty names per call.
• Namespace listing. One protocol, every tool, as one-line rows carrying their required parameter keys. A listing changes nothing until something is selected from it.

Ranking is a vector search over locally computed embeddings, with lexical scoring as the fallback when the embedding service or its index cannot answer. Whichever mode ran, the tools it returns are appended to the next request as real function schemas, so they are callable from the agent’s next message rather than the one that searched. A protocol tool that was never returned this way is not callable at all.

Alongside that surface sits a curated set of internal tools the agent always sees, grouped in its prompt by what they do: live state reads (WalletBalances, ChainRead, AgentScan), token resolution (TokenFind), exact unit and fee math (UnitsConvert), read-only swap and bridge previews (SwapQuote, BridgeQuote, TokenCheck, BridgeStatus) and their execution counterparts (SwapExecute, BridgeExecute), research (WebResearch, TwitterAccount), session and long-term memory, context compaction, the wallet prepare/confirm pairs, and the mission, waiting, plan and board tools.

Quick actions and plan mode

An empty conversation shows starter chips under the composer: hunt trending memecoins, scout Pendle yields, explore the Trench Express launchpad. Tapping one seeds the composer with a full written prompt you can edit before sending, so nothing runs until you send it. The chips disappear once the transcript has messages, and they are not shown in mission mode.

Plan mode is the opposite end, and it is a per-session toggle. With it on, the agent writes an action plan with PlanWrite (objective and boundaries, effort tier, research findings, the exact tools it will and will not use, sub-tasks, stop conditions, success criteria) and you read and correct it. Until you accept that plan, side-effecting tools are refused by the dispatcher rather than merely discouraged in the prompt, and any later edit sends it back for acceptance again.

The agent can also compose a board (BoardCompose): market analysis presented as pool cards, its own written analysis, and optionally one annotated price chart attached to its reply, instead of a wall of prose. A board is a snapshot, stamped with the moment each figure was read, not a live ticker. See Boards & Token Radar.

The Book

The Book is the right rail: a stack of cards showing the state the agent is reasoning about, so you can check its claims against the same numbers it sees. Its Portfolio tab holds Position, Wallets, Balances, Activity, Session and Trench Express cards, which you can drag into whatever order suits you, and a second Board tab holds the boards the agent composed. An inspect mode overlays a single tool call when you want to drill into one entry.

Around it, the session surface also carries the approvals region (with a global approvals view), compaction markers where long transcripts were summarised, and the memory panel covering session memory, long-term memory and privacy. Memory is advisory: only your own messages and the system prompt carry authority, so a stored lesson can never widen permission or waive an approval. See Memory.