DEPOT Download

Roadmap

Where DEPOT is going, and how far it has come.

Each bar is an outcome DEPOT is working towards; each segment is one initiative under it. 9 of 20 initiatives have shipped and 2 are in progress. Taken from the same roadmap the team plans on, no promises about dates.

Towards

v1.0.0, the first public release

Every initiative on this page shipped. Now at v1.2.1-beta. The betas are real builds people use every day; 1.0 is when the roadmap below is done.

45%9 shipped · 2 in progress · 9 to come

0.88% a day since the first release, 8 September 2026. At that pace the rest lands around December 2026. Indicative only: a straight line through a short history.

The outcomes

Shipped first, then in progress, then what comes next. Open an outcome to read its initiatives.

  1. Shipped

    DEPOT works for me

    Shipped, October 2026
    1. Local Markdown foundation
    2. Agents work inside DEPOT
    3. See the work at a glance
    4. The project page is the project's home
    5. Today is where the day is run
    The 5 initiatives

    One person covering product, design and engineering runs the whole day from DEPOT: the files, the board, Today, the agents and the project page. The first month of the product.

    1. Local Markdown foundationv0.8.0, September 2026

      Plain Markdown on disk, one dashboard, a scoped symlink into each codebase. No database, no account, no network needed. Shipped in the first four days (v0.1.0 to v0.8.0) and never reopened: every later initiative builds on these files.

    2. Agents work inside DEPOTv0.32.0, October 2026

      An agent finds its ticket, checks it out, is seen working, and hands the result back for a person to accept. This ran the whole month in four waves: the claim and trail, native T3 Code threads and delegation, run visibility and the release coordinator, then measuring whether agents actually follow the flow.

    3. See the work at a glancev0.34.0, October 2026

      Notifications that are calm and grouped, and an Overview that shows cadence rather than a list. Two epics, each revisited once: the bell went from the last ten to grouped per project (v0.17.0) to one row per item with Needs you first (v0.34.0); Overview went from recent projects to 7- and 14-day cadence tiles (v0.18.0, v0.21.0).

    4. The project page is the project's homev0.33.0, October 2026

      Written for someone who has never opened the board: masthead, releases as a strip, sections as tabs. Versions on tickets (v0.22.0) made the Releases tab possible; configurable lanes (v0.26.0) and a settled Done column followed. The settings rail and self-update came last, so a DEPOT running from a clone can look after itself.

    5. Today is where the day is runv0.19.5, October 2026

      Start the day with a focused project mix, work through Plan, Operate and Close, hand next moves to named agents, and see the day as parallel tracks. Shipped in three passes: focus sessions (v0.3.0), the cockpit (v0.10.0), then a return to the original design with a stepper and a prototype-led iteration (v0.12.0).

  2. Shipped

    DEPOT works for other ENG.

    Shipped, October 2026
    1. Share a project without losing the local foundation
    The initiative

    A second engineer joins a project, syncs the same Markdown through the hub, and claims, trails and conflicts stay honest across machines.

    1. Share a project without losing the local foundationv0.32.0, October 2026

      Planned on day one and held as an open question until the 13 September alignment review asked for a bounded experiment before committing to a transport; the work itself began on 2 October. The experiment ran on Git refs (v0.20.0) and was removed three days later in favour of a DEPOT hub: a Cloudflare Worker with one room per project and R2 for content. Share and join from the dashboard shipped on 7 October, and the week after made claims, attribution and sync status honest across machines.

  3. Now

    DEPOT works for PMs

    2 of 4 initiatives shipped

    Product managers, designers and leadership load into DEPOT without a terminal and run the roadmap from it: layers they define, themes proposed from the history, releases and milestones on one timeline. The current push.

    1. Anyone can install DEPOT
    2. Plan the road ahead
    3. Loved by PMs
    4. Strategy briefs and change impact
    The 4 initiatives
    1. Anyone can install DEPOTOctober 2026

      Design, product, sales and leadership get one artefact to install and one link to join, and never need a terminal or a repository; the engineering parts are there to ignore. The mission is in DEPOT for people who never link a codebase; delivery is the first-install plan and its tasks, then a quiet start at login.

    2. Plan the road aheadv0.34.1, October 2026

      A calm roadmap a product manager, a designer and an engineer can read and maintain, derived from the plans, tasks and releases DEPOT already has. The first slice shipped in v0.34.0 and v0.34.1 fixed it for a real release history. Still open from the plan: drag to reschedule, archive, a Now/Next/Later view, a portfolio across projects, and history with planned-versus-actual.

    3. Loved by PMsIn progress

      The roadmap and the project page become something a product manager prefers over their old tool: drag to reschedule an item, archive what is no longer planned, a portfolio view across projects, history with planned against actual, and a public roadmap page published from the same data. What was left open from *Plan the road ahead* after its first slices shipped.

    4. Strategy briefs and change impactLater

      What is left of connecting strategy to delivery now that the roadmap tab exists: short strategy briefs in Markdown, links from a brief to the roadmap items, plans and design decisions it justifies, and a way to see which work a changed decision affects.

  4. Now

    DEPOT works across all your devices

    1 of 3 initiatives shipped

    Every machine you own that runs DEPOT is visible from any other: you can see which are online, hand them projects, see their DEPOT version, update them, and delegate agent work to the harnesses installed there. Control stays on each machine: a device advertises itself only when its owner says so.

    1. Devices, presence and delegation
    2. Device management feels awesome
    3. Harden the hub so shared projects are safe to rely on
    The 3 initiatives
    1. Devices, presence and delegationOctober 2026

      Devices become first-class in the workspace: a Devices tab with live presence, project assignment from either side, per-device opt-in to accept work, versions and remote update, and delegating a run to another machine's local harness. Ships as v1.1.0-beta in stages.

    2. Device management feels awesomeIn progress

      The rough edges after devices shipped: the model picker lists what another device can run, a run sent elsewhere feels as immediate as a local one, and a device that is behind or not accepting work is obvious before you pick it. Follow-on to *Devices, presence and delegation*.

    3. Harden the hub so shared projects are safe to rely onNext

      Make the hosted hub dependable before anyone else relies on sharing: usage and budget alerts, damage detection, restore from backups, tamper-evident backups, safer credential storage, and a self-hosting conformance check. No new collaboration features.

  5. Next

    DEPOT works for designers

    Nothing scheduled yet
  6. Next

    DEPOT models a real organisation

    0 of 7 initiatives shipped

    A project has roles the way a team does. Each role has a charter: what it owns, what it reads, what it may touch, which harness and model it prefers. Work moves between roles through tickets and documents, with the trail recording every step. Vault-level agents watch across projects. A release, a docs refresh or a feature becomes a workflow of roles rather than one long prompt, and a run that hits a harness limit carries on rather than stopping the day.

    1. Agents UI and MCP that know the organisation
    2. Ask DEPOT anywhere
    3. Every AI session on this machine is visible
    4. Handoffs between agents
    5. Specialists with a charter
    6. Work continuity across harness limits
    7. Workflows: release orchestrator first, docs keeper second
    The 7 initiatives
    1. Agents UI and MCP that know the organisationNext

      A project's agents are visible and editable from the dashboard as a plain list of roles, and the MCP server tells any agent which specialties exist, so a planner plans against the real team and an orchestrator hands off to the right role by name.

    2. Ask DEPOT anywhereNext

      One chat that knows where you are: across every project at the root, one project inside it. A bubble on every page, a big Ask DEPOT on the dashboard, a full page when a conversation needs room. The composer carries harness, model, role, reasoning, access and where to run. Every thread persists and continues in its own harness session.

    3. Every AI session on this machine is visibleNext

      DEPOT watches what the harnesses already write to disk and lists every AI session on this machine: harness, model, working directory, linked project, claim or run if any, last activity. Read is universal; stop and reply only where the harness gives a real handle. A lost run record no longer loses the session.

    4. Handoffs between agentsNext

      One agent hands bounded work to another role through a sub-task DEPOT launches on that role's agent; the result returns through the existing reply flow to the parent conversation. No message bus. Everything is in the trail and works on one device.

    5. Specialists with a charterNext

      Project-level agents defined by a Markdown charter: role, owned paths, docs to read, docs owned, standing instructions, harness and model preferences. The brief they receive is only their ticket, their charter and the docs the charter names. Vault-level agents are a distinct layer that reacts to project events across projects.

    6. Work continuity across harness limitsNext

      When a harness reports a session or usage limit mid-run, DEPOT says so plainly and offers to wait and retry or, when the charter opts in, to continue on the next harness in its preference list with the ticket note and the Git diff as the handoff. Never a silently resumed transcript on a different harness.

    7. Workflows: release orchestrator first, docs keeper secondNext

      A workflow is a Markdown document of ordered steps, each naming a role and what it receives. The release coordinator becomes the first workflow instead of a special case. A docs keeper runs on a schedule and keeps DEPOT docs current. DEPOT's own release, run on a second unlinked DEPOT, is the test bed.

Order within a bar is the order the work started or is expected to. A segment is an initiative, not a unit of time.