tracking(assistant): migrate discovery and optimize the Rust Bot #6716

Problem

Target: rust-preview. Initial source baseline: ee7e90605, inspected on 2026-11-09.

The personal-assistant architecture is discussed in #6504, and #6413 inventories capabilities for the Rust transition. The TypeScript experiments in Draft #6633 combine periodic discovery, event intake, shared discovery memory and investigation scheduling; #6510 supplies the source-change intake reference. Both PRs currently target main and are unmerged.

This issue tracks the concrete Rust follow-up: bring useful discovery behavior into the Rust runtime and reduce unnecessary Bot coordination work. Sustained TypeScript use exposed high model consumption, repeated context reconstruction and repeated investigation. Those observations motivate evaluation; they are not Rust performance measurements.

The current Rust Bot already has much of the required foundation. The remaining work needs an implementation checklist and common acceptance criteria rather than another independent orchestration system.

Desired outcome

Users can interact through the Bot while ordinary worker Sessions investigate and execute tasks. Periodic broad discovery and event-triggered investigation cooperate, retain useful knowledge and feedback, and report results through the same Bot path. Coordination stays responsive and affordable without reducing useful discovery merely by doing less work.

This is a proposed delivery tracker, not an approved roadmap. Each item should link its implementation PR and verification results here; evaluate experimental choices before selecting defaults.

Existing foundations to reuse

• Bot delegation through ordinary Session* tools and Code Mode; removal of the separate WorkHub orchestration layer — feat(agent): expand Code Mode nestable tools and remove WorkHub #6688.
• Durable Bot outbox, explicit sleep and worker-completion wake-up — feat(agent): give the Bot a sleep tool that waits for events #6505 and feat(agent): wake the Bot when a worker it created finishes #6540.
• Existing parent/child authority checks for delegated execution and interactions — feat(agent): enforce parent authority for delegated sessions #6618.
• Automatic context compaction, measured-input calibration and preservation of completed summaries — fix(agent): calibrate compaction from measured input #6623 and fix(agent): preserve compaction calibration and completed summaries #6656.
• Worker execution records accessible beside Bot Chat — feat(workbench): reach a Bot's workers from its Chat #6637.
• New native workers persist the Bot's model as their default — fix(assistant): save the Bot model as new workers' default #6703.

A. Discovery migration

• A1 — Inputs and admission. Bring periodic broad discovery and enabled source-change intake into one admission path. Reuse Rust's scheduler, queue and execution ownership. Start from the experimental single-investigation-slot behavior, with pending events merged while an investigation runs. Preserve source authorization, enable/disable controls, event cursors, cooldowns and restart recovery; registering a source must not grant permission to read it.
• A2 — Investigation context and shared records. Support fresh investigation Sessions with bounded continuation material. Retain findings, corrections, user feedback, research checkpoints and prior notification decisions with stable source references. Queries must preserve decision reasons and offer continuation when more material exists. Keep the records needed to resume work without copying all previous investigation history into every request.
• A3 — Settlement, feedback and delivery. Persist investigation outcomes and result identity before acknowledging consumption. Reuse existing lifecycle and cancellation mechanisms, deduplicate recovery, and prevent superseded work from publishing stale results. Connect user feedback to the original reported finding, including quoted replies, so previously dismissed or corrected findings can inform later investigations.
• A4 — Evaluate the investigation shape. Compare a single investigating worker with the existing exploration-then-judgement experiment. Treat a second model stage as a choice to justify through quality and cost measurements. Coalesce continuous activity and coordinate periodic checks so the same changing task is not repeatedly investigated without a useful change.

The migration should preserve useful breadth and depth. A longer investigation can be worthwhile; repeated reconstruction and control-only model calls are the first reduction targets. Some repeated investigation is acceptable. Avoid adding a complex duplicate-prevention framework before measurements justify it.

B. Bot optimization

• B1 — Explicit completion and final publication. Follow Bot: a Turn that answers in plain text without SendUser or sleep leaves the answer out of Chat #6711 for required tool choice where supported and an explicit fallback where unsupported. Follow Bot: allow a final reply and Turn completion in one model step #6715 for publishing a final reply and completing the Turn in one model step. Preserve intermediate sends, silent completion, durable outbox deduplication, and new-message/steering handling.
• B2 — Notify the Bot when a worker needs input. The current completion watcher waits for an ended invocation; the UI exposes waiting workers, but this wake path does not notify the Bot of pending questions or approvals. Deliver each actionable interaction once, recheck whether it is still pending, and reuse SessionPendingInteractions, SessionInteraction and SessionRespond. Existing parent authority and human-only escalation rules remain authoritative.
• B3 — Carry usable results with completion notifications. Include the exact worker/invocation identity, outcome, and an appropriately sized view of the worker's already-recorded final output, with a read reference for the rest. Avoid an extra summarizer merely to construct the notification. Preserve the distinction between a worker's claim and verified task completion.
• B4 — Make history lookup cheaper to consume. Evaluate a compact first-pass result view, followed by on-demand context expansion through the existing Recall facilities. Retain complete source access, explicit result budgets and continuation; do not introduce silent truncation. Account for existing tool-result archiving when measuring the benefit.
• B5 — Tune context management for the Bot's role. Reuse existing compaction and checkpoints. Evaluate lower Bot working-context thresholds and summaries that retain user constraints, unfinished tasks, exact worker IDs, pending decisions, prior notifications and recovery references. Compare total cost and follow-up correctness, including summary generation, changed cache reuse and additional retrieval.
• B6 — Coalesce completion events and preserve routing identity. Evaluate handling several already-ready worker completions in one Bot Turn. Keep individual event identities and consumption records, and avoid delaying user input or actionable blockers to form a batch. Preserve the result-to-worker links in Chat and carry explicit quoted-result identity into follow-up routing; recheck worker ownership and permissions before dispatch.
• B7 — Profile and narrow watcher work. Measure idle and active behavior with many retained workers. If warranted, replace repeated scans of unchanged watches with targeted checks, while retaining startup recovery and reconciliation. Measure local CPU/database work separately from model calls; polling itself is not an LLM request.

C. Validation and completion

• Use the same seeded tasks and source events for before/after comparisons. Cover ordinary chat, concurrent completions, pending questions/approvals, related follow-ups after an unrelated task, long-history retrieval, and sustained source activity.
• Cover interruption and recovery around event admission, result persistence, outbox publication and Turn completion. Confirm no input is lost or falsely consumed, retries do not duplicate publication, and paused/superseded investigations cannot publish stale results.
• Report useful discoveries, missed seeded findings, repeated notifications/investigations, and follow-up routing errors together with model calls, cached/uncached input, output, estimated cost and latency. Build on test(assistant): evaluate discovery for missed discoveries as well as repeats #6360; distinguish estimates from provider invoices and missing usage from zero usage.
• Record the tested Rust SHA, environment, enabled sources, model selection and permissions. Link implementation PRs and results to this checklist. Validate platforms as each slice lands; do not carry TypeScript test results over as proof of Rust behavior.

Suggested order: B1–B3 first; then a minimal A1–A3 discovery slice; measure A4/B4/B5; evaluate B6 and profile B7. Validation accompanies each slice.

Alternatives or workarounds

Draft #6633 remains a runnable experimental reference while Rust implementation is developed. Its observations and regression scenarios can be reused, but its controllers, databases and migration logic do not need to be copied wholesale.

The Rust Bot can already delegate work, read history and arrange approved scheduled tasks. Those capabilities are the implementation foundation, while native discovery coordination and the optimizations above remain work to evaluate and track.

Architecture discussion stays in #6504, the wider capability inventory stays in #6413, and existing issues such as #6711/#6715 retain their own implementation discussions. This tracker links those efforts rather than replacing them.

AI assistance: OpenAI Codex assisted with source inspection and drafting.