PilotDeck: A WorkSpace-Scoped Agent Platform With Editable Memory

The Problem PilotDeck Picks: Multi-Project Agents With Auditable Memory

Most agent tooling is built around a single session or a single repository. The README frames PilotDeck against that grain, listing Claude Code, Cursor and Trae Solo as tools that pushed model reasoning into the IDE, Claude Cowork as bringing project-level isolation to desktop knowledge work, and WorkBuddy as wiring agents into WeCom and Feishu. The gap PilotDeck claims is long-running, multi-project productivity work, where the questions change from "can the model write this function" to "which memory entry made it write this function" and "what did this task cost me." The README asks four of those questions explicitly: whether memory can be white-box and traceable, whether token cost can be tracked per task, whether task difficulty can be matched to model tier automatically, and whether work continues when the user steps away from the keyboard. The intended user is someone running several projects in parallel who has already been burned by global context pollution and by an agent that misremembers something they cannot locate or correct. That is a narrower audience than "AI productivity platform" suggests, and the README is more honest for stating it as an open question set than as a solved product.

WorkSpace as the Isolation Unit, and What That Actually Bounds

The architectural primitive is the WorkSpace. According to the README, every project gets its own file system, memory store and skill set. Three consequences follow from that layout, and the README names all three: parallel work stops interfering with itself, retrieval scope is bounded, and skills accrete per task rather than globally. The bounded retrieval point is the one worth dwelling on. If a WorkSpace owns its memory store, then a query against memory only ever scans that project's entries, which means retrieval cost and retrieval noise both scale with project size rather than with everything the user has ever done. The trade-off is that nothing crosses the boundary by default. A preference you established in one WorkSpace is not visible in another unless the system provides a mechanism for that, and the README does not describe one. Teams that want a shared house style across ten projects will find isolation working against them. The README also states the system natively supports the Model Context Protocol and behaves consistently across Web, CLI and IM front-ends, which suggests the WorkSpace state lives behind a shared service rather than in any one client.

White-box Memory and Dream Mode: The Strongest Idea Here

The memory design is the part of PilotDeck that is hardest to copy badly. The README says memory generation, extraction, storage and retrieval are visible end to end, and that when the AI misremembers, the user can pinpoint and fix the offending entry. That is a different posture from the usual retrieve-and-hope pipeline, where a wrong answer is untraceable because the retrieved context is never surfaced. Two supporting mechanisms are named. Dream Mode consolidates memory during idle windows, and there is one-click rollback. Consolidation plus rollback is a coherent pair: if idle-window rewriting of memory can be undone, then the user can let the system reorganize without treating every consolidation pass as irreversible. What the README does not say is how conflicts resolve when a new entry contradicts an old one, whether consolidation is scheduled or triggered, and what the rollback granularity is (one entry, one Dream Mode pass, or the whole store). Those are the questions to answer before trusting the memory layer with anything you would not want silently rewritten.

Smart Routing: Task Difficulty Detection and the Cost Claim

Smart Routing is described as auto-detecting task difficulty, sending complex calls to flagship models and simple ones to lighter models, with on-device and cloud co-orchestration. The README gives a concrete illustration from Xiaohongshu-style social media operations: with Smart Routing enabled, simple polishing and layout tasks are demoted to a sub-agent (the README names Sonnet 4.5) and Opus 4.5 is invoked only at planning checkpoints. The headline figure attached to this is roughly 70 percent cost savings on social-media workloads. Treat that number carefully. It appears under a heading called Real-world Numbers, the surrounding table is truncated in the material available, and there is no statement of sample size, time window or baseline configuration. The README also uses the phrase "shrinks dramatically" without a definition. The mechanism is plausible and the checkpoint pattern is a sensible place to spend a flagship model, but the specific percentage is a vendor-reported result that cannot be reproduced from what is published here. The routing layer also introduces a failure mode the README does not address: a misclassified task sent to a lighter model may fail in a way that is harder to diagnose than an outright error, because the output will look finished.

Always-on Execution and Where It Breaks Down

The Always-on pillar is the most ambitious claim. The README says PilotDeck breaks the ask-and-answer loop: after the user signs off, the agent keeps discovering candidate tasks, runs long-horizon monitors, and lands deliverables as local files with a summary report waiting. Two things are left unspecified. First, "discovering candidate tasks" implies the agent decides what is worth doing without a human in the loop, and the README gives no description of how candidates are filtered, ranked or capped. An agent that generates its own backlog is an agent that can generate its own token bill. Second, the deliverables land as local files, which means the always-on loop is tied to a machine that stays running. There is no discussion of what happens if that machine sleeps, or whether the loop resumes. The cost-tracking question from the introduction is also not answered anywhere in the material: the README asks whether token cost can be tracked per task, but the published highlights describe routing and savings rather than a per-task accounting surface. If per-task cost visibility is the reason you are evaluating PilotDeck, the README does not yet demonstrate it.

Getting It Running: What the README Does and Does Not Give You

This is where the material runs thin. The README includes an Installation and Quick Start link in its navigation and a section anchor for it, but the body of that section is not present in the material available, so no install command, package name, config key or environment variable can be quoted here without inventing it. What can be stated from the repository metadata: the primary language is TypeScript, the default branch is main, the licence is AGPL-3.0, the homepage is pilotdeck.openbmb.cn, and a live demo is linked at pilotdeck.openbmb.cn/pilotdeck.github.io/demo/p/pilotdeck-demo. The README also points to a tutorial under pilotdeck.openbmb.cn/pilotdeck.github.io/docs/en/introduction and to a MiniCPM wiki, which is consistent with the OpenBMB and ModelBest involvement stated in the About section. If you are evaluating this for adoption, the first practical step is to read the Quick Start section on the live site rather than the repository README, because the repository copy as supplied here stops before the commands. Do not assume a Node version, a package manager or a container setup; none is stated.

Release Cadence, Licence and the Real Maintenance Question

Three releases appear in the material, tagged v2026.09.07, v2026.09.09 and v2026.09.10, with the most recent push timestamp matching the newest tag. The versioning scheme is date-based, which tells you the project ships on a schedule rather than on semantic version boundaries. For a platform that owns your project files, memory store and skills, that cadence is the main operational risk: date tags carry no compatibility promise, so an upgrade cannot be reasoned about from the version string alone. Budget for reading changelogs between tags and for testing a rollback path, particularly around the memory store, since Dream Mode rewrites memory during idle windows and the README advertises one-click rollback but not a version-pinned migration story. On licensing, PilotDeck is AGPL-3.0. That is a strong copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the AGPL's source-disclosure obligation is generally understood to apply. Whether that fits your deployment depends on facts about your organisation that this article cannot assess. If you plan to embed PilotDeck in a product you distribute or host for others, get your own legal read before you build on it, and note that the README does not describe any commercial licensing alternative.

How It Compares to a Plain Coding Agent

The clearest contrast in the README is with Claude Code and Cursor, which the project positions as IDE-embedded reasoning tools. The difference is not model quality; it is statefulness and scope. A coding agent typically holds a session and a repository, and when the session ends, the accumulated understanding largely ends with it. PilotDeck's bet is that the durable unit should be a WorkSpace holding files, memory and skills, with memory exposed for editing and rollback, and with a router deciding which model tier handles each call. That is a meaningfully different design, and it costs something: more moving parts (a memory store, a consolidation pass, a routing policy, a background executor) than a single-session assistant, and more surface area for a misconfiguration to produce quietly wrong output. The honest framing is that PilotDeck trades simplicity for continuity. If your work is one repository and one sitting, the extra machinery buys you little. If your work is five projects running for months, the isolation and the editable memory are the features that matter, and the routing layer is the one to validate first because it is the one with a number attached that you cannot yet check.

Editorial conclusion

Adopt PilotDeck if you run several long-lived agent projects in parallel and the ability to inspect and edit a specific memory entry matters more to you than a polished single-session coding assistant. Do not adopt it if you need a stable, slow-moving dependency: the release tags here are dated daily, the README's cost and savings figures are presented as vendor results with a truncated table, and the deployment surface (Web, CLI, IM) is described but not documented in the material available. Before you commit, verify three things against the live repository: the actual install and run commands, which model providers the router can talk to and how you configure them, and whether AGPL-3.0 is compatible with how you intend to expose the service to users.

Official sources

1. License: AGPL-3.0
2. OpenBMB/PilotDeck on GitHub
3. Project website
4. README
5. Releases