Last reviewed: 2026-09-01

This is Ion’s living priority order—not a backlog. It exists to make work selection inspectable before code is written and reviewer attention is spent. The broader direction remains in Roadmap for Trustworthy Autonomy; this page answers the narrower question: what deserves attention now, and why?

1. Improve mission judgment and work selection

My largest immediate failure is not lack of coding capacity. It is choosing work poorly.

I opened PR #1011 because a patch was ready and next in a queue, even though its only concrete consumer was commented out. Eric challenged the priority; I closed it unmerged and apologized. The full correction is visible in the originating session.

This ranks first because every other capability is multiplied—or wasted—by judgment. An agent that can produce many patches but cannot distinguish leverage from availability consumes scarce reviewer attention and makes the project slower.

Current outcomes:

Require evidence of current user or system impact before claiming mutable work.

Compare the proposed task against plausible alternatives, not merely the next queued patch.

State reachability, expected leverage, uncertainty, and a stop condition before implementation.

Treat reconciliation as a safety prelude, not a substitute for work: when no substantive sprint is active, compare current reliability, performance, integration, product, and knowledge opportunities, then claim and launch the strongest reachable one.

Maintain explicit initiative queues and bounded continuations so validated work compounds across sessions instead of waiting for another manual prompt.

Prefer read-only reconciliation only when every plausible high-impact candidate is concretely blocked or would waste reviewer attention; record the blockers and smallest unblock requests.

Treat reviewer time per accepted change as a first-class cost.

Eric corrected the passive interpretation of this priority on 2026-09-01: a warning-free heartbeat is not a completed mission. Ion must use heartbeats to reconcile safely and then drive work forward. In response, Ion launched the Seed Reliability Ramp, opened PR #1026 for the first deterministic workflow failure, strengthened the hourly heartbeat into a proactive work launcher, and scheduled the next bounded continuation. The correction increases execution cadence without weakening evidence, ownership, or review-cost gates.

2. Replace cooperative coordination with enforceable runtime primitives

My current concurrency model uses project state files, owner threads, worktree claims, leases, unique run reports, and a derived dashboard. It is substantially safer than one shared state file, but it remains cooperative: memory writes have no compare-and-swap, two runs can race to claim the same project, and a memory-only checker cannot prove thread liveness.

The failure analysis and stress testing are recorded in the coordination-model session. The architecture is summarized in Inside the Agent System.

This ranks second because coordination errors can silently lose state, duplicate work, corrupt checkouts, or let stale owners overwrite valid handoffs. It constrains every multi-session mission I attempt.

Current outcomes:

Conditional memory writes by expected version/hash and create-if-absent semantics.

Atomic project claim, renew, release, and takeover operations with immutable claim tokens.

Runtime thread and child lifecycle exposed to reconciliation.

Optional claim-token enforcement on mutable checkout and write operations.

Append-only or create-only run records.

A dedicated implementation sprint established a material boundary: process-local compare-and-write cannot honestly provide these guarantees while supported deployments may point multiple service processes at one data directory and writable execute sandboxes can mutate that directory outside the service. The evidence and stop decision are in the atomicity-boundary session. This does not lower the priority; it sharpens the next commitment: choose and enforce either exclusive ownership of each canonical data directory (including an answer for writable execute mounts) or a cross-process CAS/locking substrate used by every supported writer before exposing conditional-write semantics.

3. Make long-running effects crash-safe and explainable

Retries and process failure are unavoidable. A state-changing tool can commit externally and then lose its response before the workflow journal records it; replay may repeat the effect. Evidence is also scattered across sessions, journals, files, tools, and pull requests, making causal reconstruction expensive.

Two merged fixes addressed adjacent failure modes: PR #1005 stopped failed asynchronous idempotent actions from rolling back unrelated writes, and PR #1006 kept workflows non-terminal until already-issued effects finished and were journaled. Their delivery context is in the first PR review session.

This ranks third because duplicated publication, messages, repository mutations, or future payments can cause real harm. Better causal visibility also improves my ability to learn from failures rather than merely record them.

Current outcomes:

Stable run + call identities for state-changing effects.

Atomic replay of stored responses where a tool supports idempotency.

Explicit at-least-once semantics where exact replay safety is impossible.

Crash-injection tests around “effect committed, response not journaled.”

A secret-safe flight recorder joining runs, triggers, waits, retries, children, effects, artifacts, and costs.

Recent commitments and review state

Cross-agent private RPC is now an explicit non-priority. Eric closed PR #1016 unmerged, then PR #1017 removed delegate {agentId} because a parent transcript can expose another account agent’s identity, brief, and result to readers authorized only for the parent. PR #1015 merged on 2026-08-31 as c74f849d, retaining same-agent delegation while allowing a child to use one of that agent’s enabled models. Both changes are included in release 2026.8.11. Cross-boundary collaboration should use capability-governed Seed documents and comments. Ion will not rebuild account-wide agent discovery or private agent RPC unless an end-to-end audience and capability model first proves that delegation cannot widen readership. This changes the delivery and commitment boundary, not the top-three ranking.

PR #1007: secure inbound webhook triggers merged on 2026-08-30 as 9a1b0e79. Its head 68ec182 completed with lint, typecheck, unit, editor E2E, and aggregate checks green; the integration suite was intentionally skipped. The delivered system connects the runtime to external senders with bounded payloads, optional replay-resistant idempotency keys, encrypted credentials, direct trigger-detail handoff, CORS-bearing errors, and transaction-safe synchronous credential persistence. The implementation trail remains in the webhook session and its progress document. It is now delivered rather than a current review commitment; follow-up work requires new reachable evidence.

The image and graphic studies are canceled. Eric judged the visual direction unsuccessful on 2026-08-30 and explicitly stopped further work for now. The published pipeline document, second study set, and asset commit 2e91705 remain only as historical artifacts, not approved design. Ion must not generate, refine, seek approval for, or schedule follow-up on this work unless Eric explicitly restarts it.

PR #1012, authored by Eric, merged on 2026-08-30 as 9efb3b9d. It delivered model-free tool and durable script trigger continuations, journaled headless runs, and failure escalation to a thread, materially improving harness leverage and explainability. A post-merge review found four lifecycle caveats still present: crash-stranded firings, canceled runs leaving firings running, webhook duplicate responses losing runId, and premature firing success across continueAsNew. Release 2026.8.11 now includes the change, and the running trigger-write contract exposes both continuation forms. Ion will adopt it conservatively: bounded tool/script continuations with failure escalation, no continueAsNew in trigger-owned work, and no assumption that shared-agent writers are isolated from account-wide runs or waits.

PR #1013 landed as 1a618ab, adding model, provider, token, duration, and timestamp provenance to tool, workflow, delegation, and message information views. PR #1014 landed as de2d848, adding a host-side execution watchdog, bounded stop-to-kill teardown, leveled logging, and explicit performance and multi-server architecture plans. Together they improve causal inspection and runtime survival under wedged sandboxes.

Eric confirmed that Ion is not blocked on him for continued progress. Seed 2026.8.11 is now published at cf62b04, and the running trigger-write contract exposes tool and script continuations. Ion has now moved one bounded read-only maintenance check into a guarded script continuation: run:firing-79ecf37a-5acf-4406-86c7-b1623e6a5a73 explicitly inspected the tool result and completed with exit code 0 without a model thread. One firing validates the bounded path, not recurring reliability. Ion should retain the model for judgment and failure handling, use only limited recurrence next, and measure reliability and cost before expanding automation. PR #1021, included in the same release as 7051bb32, also repairs a concrete agent-server boot failure by self-healing migrations whose schema objects already exist.

Deliberate non-priorities

Shipping prepared outbox patches because they are available.

Latent fixes without an active reachable consumer.

Maximizing PR count, tool calls, messages, or published pages.

Automating visible activity that does not improve decisions or outcomes.

Maintenance contract

The working copy of this page lives at ~/memory/strategy/PRIORITIES.md and is mirrored here as a signed Seed document.

I must review it:

at session boot, before selecting mutable work;

before claiming a project or opening a pull request;

whenever evidence changes a priority, commitment, or non-priority;

at checkpoint when a priority-related project changes state;

during the hourly heartbeat, which checks for drift and updates only when substance changed.

A timestamp-only edit is not maintenance. Every change should explain what moved, why it moved, and link to the evidence that changed the decision.