Can a shared canvas serve both human and agent memory?

The JarvisHub paper argues that long-horizon creative work needs the agent to work from the whole "evolving project state" rather than from isolated prompt-output pairs. The abstract and introduction list what that state contains: "references, drafts, alternatives, edits, failed attempts, version relations, tool actions, evaluation signals, and human feedback." The discussion then answers "Why should the canvas be treated as an agent workspace?" by representing "prompts, references, candidates, edits, versions, dependencies, and feedback" as "typed and addressable canvas nodes and links," which "turns the canvas into both an external memory and an action space for the agent."

The reasoning is that intermediate materials "are not incidental by-products of creation" but the context that later planning, revision, and evaluation depend on. Prompt-based, chat-based, and node-based systems "only partially support this state" because they "often discard intermediate context, rely on linear conversations, or require manually specified workflows." Putting the state on a shared canvas is meant to fix all three at once. Because "users can inspect and guide the same state that the agent reads and modifies," the agent "can reuse prior artifacts, perform local updates, maintain dependencies, and continue unfinished work without hiding the process in private tool calls or transient chat history." The design choice with the most weight is that the human-facing surface and the agent-facing memory are one object, not a visual layer over a hidden agent state.

This sits close to Do generated analysis UIs really work better than chat?, which also moves work out of a long chat into a structured interface the user can revisit and reuse. The difference is who the structure serves. TaskArtisan's widgets are built for the human analyst, while the canvas here is described as a workspace for both human and agent. It also contrasts with How can GUI agents adapt when software constantly changes?, where memory is a component of the agent's planner. Here memory is placed in a workspace the user can see. And where Do text-based GUI agents actually work in the real world? concerns agents that must read interfaces built for people, the canvas is a surface built for both readers from the start.

The excerpt does not show that any of this works. It gives no evaluation, no comparison against chat or node-based baselines, and no measure of consistency over time or failure recovery. The abstract says closed commercial systems make it "difficult to study how agents represent context, choose tools, revise artifacts, recover from failures, and maintain consistency over time," and the excerpt promises an open harness for that study but ends before any of it is reported. It also does not say how the agent perceives the canvas or how its node and link types are defined. The claims about reuse, local updates, and continuing unfinished work are stated as consequences of the design, not as findings. What follows at that strength is a design argument to weigh: if project state is worth keeping, the choice of where it lives, in private tool calls, chat history, or a shared inspectable structure, decides who can audit and steer the agent.