three.ws Autopilot

Edit a pending proposal's params before executing it — tune a threshold, swap a briefing cadence, correct a transfer amount/recipient. The new params are validated SERVER-SIDE against the proposal kind and shape: create_alert → { asset:"three"|<mint>, condition:"price_above"|"price_below"|"graduation"|"whale_buy", threshold_usd?|threshold_sol? }; briefing → { summary, cadence:"once"|"daily"|"weekly", topic }; wallet_transfer → { recipient:<solana addr>, amount_sol:number, reason? }. An invalid edit is rejected with the reason and nothing changes. Only a pending proposal can be adjusted. WRITE but idempotent (no action taken; re-applying the same params is a no-op). For alerts the only coin is $THREE (asset:"three"); wallet_transfer sends SOL only and never sells or sends $THREE. Returns the updated proposal.

The agent's earned trust level, computed from its REAL autopilot history. Returns level (sandbox → trusted → autonomous), a 0+ score (net kept executions weighted by reliability), the underlying stats (executed / undone / dismissed / pending counts + reliability %), and what it takes to reach the next level. Trust rises as the owner keeps the agent's actions and falls when they undo or dismiss them — it is not configurable, only earned. Read-only.

Dismiss a pending proposal the agent decided not to act on. Marks it dismissed and records a feedback memory ("don't propose this again") so future generate_proposals steers away from it — this is how the agent learns the owner's boundaries. WRITE. Only a pending proposal can be dismissed (executed/undone/dismissed ones are rejected). Returns the updated proposal and trust.

Preview exactly what executing a proposal WOULD do, without taking any action. Returns the kind, a plain-language "willDo" sentence, and a checklist of guard checks (scope granted? params valid? within the daily SOL cap? wallet balance covers a transfer?) plus a `blocked` flag if any check fails. Always dry-run an irreversible wallet_transfer before executing it. Performs a live balance read but no write and no spend — safe to call freely. Read-only.

EXECUTE a proposal for real, within the owner-granted scope. ⚠️ This is the funds-touching action: a `wallet_transfer` proposal sends REAL SOL on Solana mainnet and is IRREVERSIBLE — you MUST pass confirm:true for it (unless the owner durably pre-authorized that scope), and it is capped by the daily SOL budget. It sends native SOL only — never $THREE. `create_alert` and `briefing` are real writes but reversible via undo_action. Always dryrun_proposal first. Scope, confirmation, and spend caps are enforced SERVER-SIDE; this tool cannot override them — an out-of-scope, over-budget, or unconfirmed call is denied (no action taken). Returns the updated proposal, a human receipt, the signed action-log id, and updated trust.

Run the agent's mind: read its high-salience memories and pending reflections and synthesize real, concrete autopilot proposals — each citing the exact memories that justify it. New proposals are persisted to the queue (see list_proposals). WRITE: any reversible proposal the owner has scoped for auto-execution may run immediately and is reported under `autoRan`; irreversible SOL transfers never auto-run — they stay pending for explicit execute_proposal. Returns the created proposals, the autoRan receipts, the generation `source` (reflection | memory | heuristic), what was `scanned`, and updated trust. Deduped server-side, so calling it repeatedly will not enqueue duplicates.

Read the agent's autopilot permission model: whether autopilot is enabled, which capability scopes the owner granted (create_alert, briefing, wallet_transfer), which reversible scopes may auto-execute, the daily SOL spend ceiling (in SOL; 0 = no spending), and whether irreversible actions require explicit confirmation. Also returns the live trust level (sandbox → trusted → autonomous) computed from real action history. Nothing the agent can do exists outside these owner-granted scopes — read this before proposing or executing. Read-only.

Read the append-only log of every autonomous action the agent has taken, newest first — the real agent_actions trail. Each receipt carries the kind (alert created / briefing authored / wallet transfer), its rationale, the outcome (created rule id / notification id / on-chain signature), the source memories it was grounded in, and the cryptographic signature + signer address when the action was signed by the agent's wallet. Use it to audit what the agent did and why. Omit agentId to aggregate across every agent the credential owns. Paginate with the returned next_cursor. Read-only.

List the agent's autopilot proposals — candidate actions it generated, each grounded in cited memories (provenance hydrated). Each proposal carries its id (needed for dryrun/execute/dismiss/undo/adjust), kind (create_alert | briefing | wallet_transfer), title, plain-language rationale (the receipt), params, confidence, requiresConfirmation, status, result, and the source memories. Filter by status to find what is actionable. Also returns the current config + trust for context. Read-only.

Update the agent's autopilot guardrails. A partial patch — only the fields you pass change; the rest are preserved. Set `enabled` to arm/disarm autopilot, `scopes` to grant/revoke each capability (create_alert, briefing, wallet_transfer), `autoExecute` to let reversible scopes run without review, `dailySpendSol` for the daily SOL outflow ceiling (in SOL; 0 disables spending), and `requireConfirm` to force explicit confirmation on irreversible actions. WRITE but idempotent: it changes only the boundaries, takes no action, and re-applying the same values is a no-op. Returns the full updated config. Scopes are enforced server-side at execution time — granting one here is what makes a later execute_proposal possible.

Reverse a reversible executed proposal: deletes the real artifact the execution created — the alert rule (create_alert) or the briefing notification (briefing) — and records a feedback memory so the agent learns to be more conservative next time. WRITE. NOTE: an irreversible SOL wallet_transfer is on-chain and cannot be undone — the server rejects that with `irreversible`; to send value back you would have to execute a new transfer. Returns the updated proposal (status → undone) and trust.