AgentContext is passed to your run and unwind functions. It has session data and all SDK methods.
Session Data
session_id(Python) /sessionId(TypeScript) (number): Unique session identifiersession_wallet_address(Python) /sessionWalletAddress(TypeScript) (string): Wallet address for this sessionexecution_mode(Python) /executionMode(TypeScript) (string):"auto"or"manual"settings(object): Resolved settings (defaults merged with session overrides)
SDK Methods
- Python
- TypeScript
log(): Send messages to users and log locallymemory: Key-value storage (shared=Truefor shared scope, omit for session)platforms: Platform integrations (Polymarket, Hyperliquid)swap: Cross-chain swap operationssign_and_send(): Sign and broadcast transactionssign_message(): Sign messages (EVM only)transactions(): Get transaction historyclear_suggested_transactions(): Clear pending suggestions (manual mode)allocation: The session’s virtual allocation snapshot at invocation start
Basic Usage
Virtual allocation
agent.allocation is a field in both languages and has no success/data wrapper. It remains fixed for the invocation; the next trigger receives a newly constructed context with committed top-ups and transaction effects. See Positions for full details.
Assets whose balance could not be verified
allocation.unreadable_assets (Python) / allocation.unreadableAssets (TypeScript) is normally empty. A key appears there when its contract refused the balance read — most often a token airdropped into the wallet whose balanceOf reverts, which nobody asked for and nobody can read.
Such a key is left out of balances rather than carried at a stale quantity, because a balance that cannot be verified must never sit inside a spend cap. Everything else in the allocation is complete and spendable, so most agents can ignore the list entirely; an operation that names an unreadable key fails closed on its own.
See Also
- SDK Quick Reference - All SDK methods at a glance
- Execution Model - How sessions and the run loop work
- Positions - Full portfolio reference