The Task Store: persistent memory as a typed, versioned store, not a bigger prompt

The prompt window is the wrong place to keep memory

Ask most AI assistants to remember something and the honest answer is: it stuffs more text into the prompt. Conversation history, retrieved documents, a running summary of "what we decided" — all of it gets concatenated and re-sent on every turn. This works until it doesn't. The window fills, older facts get truncated or summarised into vagueness, and the model starts reasoning over a lossy paraphrase of its own past. Two turns later it contradicts a decision it made earlier, because the decision was never stored anywhere durable — it was a token sequence that scrolled off the top. Cramming context into the prompt window treats memory as text to be re-read, when what you actually need is state to be queried.

Panaptic inverts this. The agent's memory does not live in the prompt; it lives in the Task Store — a normalised, typed, path-addressable, version-tracked store that holds the state of every task run. The context window holds the working set the agent needs right now. The store holds the truth. The agent navigates that truth deliberately with tools, instead of hoping the relevant fact happens to still be inside the last few thousand tokens.

What the Task Store actually is

The Task Store is a graph of typed elements. Every element is typed against a JSON Schema, addressable by a stable path, and version-tracked so its history is recoverable. Three analogies get you most of the way there. It behaves like a Redux store that survives reloads, supports queries, and gives you time travel over its history. It behaves like a document database where every document is a node in a typed graph rather than an island. And it behaves like an entity-component system where every entity is reactive UI by default — change a value and the panel rendering it updates, no glue code required.

Because each value is path-addressable, the agent does not rewrite a blob of state to change one field. It targets a specific path, the way a reducer targets a single slice of a store. Operations declare in their schema which elements they touch, so a mutation is a precise, typed edit to a known location — not a hopeful regeneration of a whole document. That precision is what makes the store safe to share between an autonomous agent and a human clicking through the same task at the same time.

One store, two readers: the agent and the user

The detail that makes the Task Store distinctive is that it is the agent's working memory and the user's live workspace simultaneously — the same elements, not two synchronised copies. The agent inspects elements, runs semantic search across them, embeds them inline in its markdown replies via ::element syntax, and writes back to specific paths. The user sees those same elements rendered as panels, tables, and forms, because every element carries UI metadata in its schema and renders automatically. When the agent updates a value, the human's panel reflects it; when the human edits a form, the agent reads the new value on its next inspection. Nobody is working from a stale snapshot, and there is no "sync the AI's memory with the app's database" step to get wrong, because there is only one store.

This is why autonomy in Panaptic is a dial rather than a separate product. A task running in Manual mode and the same task running Autonomously read and write the same Task Store. Moving from human-driven to agent-assisted with approval gates to fully autonomous changes who acts on the store, not what the store is. The memory model does not fork when you turn the AI up.

Why version-tracked state makes agents reliable over long-running work

Reliability over long-running work comes from three properties that fall out of this design. First, durability: a fact written to a path is still there a thousand turns later at full fidelity, not compressed into a summary. The agent does not "forget" because nothing was ever held only in volatile context. Second, queryability: the agent retrieves what it needs by path or by semantic search instead of re-reading everything, so its accuracy does not degrade as the run accumulates history. Third, auditability by construction. Because the store is change-tracked, every state transition is captured with its actor — user, agent, or system — its operation, its inputs, and its timestamp. The audit log is not a plugin bolted on afterwards; the version-tracked Task Store is the audit log. You can ask not just what the state is, but how it got there and who moved it.

That last property is what lets teams trust an agent with real work. When an autonomous run does something surprising, you are not reconstructing intent from a chat transcript. You are reading a signed, ordered history of typed mutations against named paths. Combined with OpenTelemetry export to your existing observability stack, this gives you the same forensic clarity over an agent's behaviour that you expect from a well-instrumented service.

The working set holds attention; the Task Store holds truth

None of this removes the prompt window — it puts it in its proper place. The context window is for the agent's current focus: the few elements it is actively reasoning about, pulled in on demand and written back when resolved. The Task Store is for everything the task run knows. What needs to outlive a single run — customer records, case history, the audit trail — lives in Custom Data on your per-org Postgres, queried with real SQL. Separating attention from working memory from durable records is what lets an agent stay coherent across a process that spans hours, hundreds of operations, and several handoffs between human and machine. It is the difference between an assistant that remembers because you keep reminding it, and a business operating system whose memory is a queryable, typed, versioned store by design. If you want to see how it underpins authoring, execution, and audit on one plane, read the Platform page — and start free to build a task on top of it.