Agent command centers need one source of truth

Pawel Jozefiak recently wrote about running a personal AI agent and the tooling he built to manage it. He moved from Notion to Obsidian to a custom SQLite-backed board, then to a native SwiftUI app with focus mode and menu-bar visibility.

The critical bug he hit was tasks re-executing because completion wasn't reliably recorded. He ended up with a six-layer memory system (working memory, weekly rollover, permanent index, deep profiles, semantic search, self-improvement pipeline) and a clear conclusion. There's a gap between generic task tools and full agent IDEs. What's missing is a "Command Center" for agent lifecycle: claim, execute, review, iterate, with real-time visibility.

I'm building Neotoma, a truth layer for agent memory. It doesn't build the dashboard or the agent. It provides the layer that a command center would use.

The gap he described

Jozefiak's options were either too generic (Trello, Linear) or too technical (terminal, JSON). Generic boards don't know about agent state. Who claimed what? Is the agent working or waiting for review? How is completion recorded so the agent doesn't run the same task twice? Raw logs and JSON don't give you a board at all.

He needed something in between: a single place where the agent and the human share task state, with clear semantics for claim, complete, and status, and fast enough that polling or real-time updates don't fall over. That "single place" is a data problem. The command center is the UI. The thing it reads from and writes to is the substrate.

What a truth layer provides

Neotoma stores typed entities, observations, and relationships. It exposes them over MCP so any agent (Claude Code, Cursor, a scheduled runner) can store and correct state. Idempotency and deterministic IDs are built in.

When the agent claims a task, it stores or corrects an entity with status "in progress." When it completes, it corrects again with status "done." Same idempotency key, same outcome every time. The bug Jozefiak hit (completion not recorded, task re-executed) is exactly what idempotent, durable writes are meant to prevent.

A dashboard or native app that wants to show "what the agent is doing" would query the same store: list entities by type (e.g. task), filter by status, show assignee and timestamps. The agent and the dashboard share one source of truth. No custom SQLite, no sync layer that can drift. The dashboard is a view over Neotoma.

Where the six-layer memory fits

Jozefiak's six layers (working memory, weekly rollover, permanent index, deep profiles, semantic search, self-improvement) are strategy-layer and application-layer concerns. They decide what to keep, what to compress, what to summarize, and what to feed back into the agent's behavior.

Neotoma doesn't do compaction or summarization. It's the durable, structured store those layers read from and write to. Working memory might be "last N observations" or "entities touched in the last 48 hours." Weekly rollover might write new observations (summaries, indexes) back into Neotoma. Semantic search might run over the same entity graph. The boundary is clear: Neotoma is the truth layer; the layers above it implement retention policy and retrieval strategy.

Why this matters for builders

If you're building a personal agent and you need task state, status tracking, and visibility, you have two paths. You can roll your own storage (SQLite, files, a custom API) and then build a board or dashboard on top. You'll run into completion semantics, idempotency, and cross-session consistency yourself. Or you can use a substrate that already gives you entities, observations, provenance, and MCP access. The command center becomes a client of that substrate. The agent is another client. Both read and write the same state.

I'm not building the command center. I'm building the layer it would sit on. Neotoma is the data plane for agent dashboards and lifecycle tooling. If that gap Jozefiak described gets filled by products (WizBoard-style or otherwise), those products will need a backend. A truth layer is that backend.

How this fits the trends I'm betting on

In six agentic trends I wrote about recently, I argued that agents will become stateful economic actors, that errors will become economically visible, that tool fragmentation will persist, and that usage will be metered. The command center gap Jozefiak hit sits at the intersection of those pressures.

When agents are stateful and long-running, you need to see what they're doing. Trend 1: "Product interfaces exposing agent history as something inspectable rather than ephemeral" is exactly what a command center is. When mistakes cost money or reputation, you need to know what the agent knew at the time. Trend 2: traceability and "what did the agent know?" make a single source of truth for tasks and status necessary, not nice to have.

When you use multiple tools and models, state fragments. Trend 5: the command center and the agent both need to read and write the same state, which is why the substrate has to sit beneath the UI. When usage is priced, re-executing the same task because completion wasn't recorded is visible waste. Trend 6: idempotent, durable completion is an optimization as much as a correctness guarantee.

I'm dogfooding Neotoma in my own agentic workflows and documenting the "agent task lifecycle" pattern: store task entities, use observations for status and history, update via MCP correct with idempotency keys so completion is unambiguous. That pattern is what would power a command center view (claim, execute, review, iterate) without each builder reinventing their own SQLite and sync logic. I'm also adding "agent dashboard / command center backend" to how I describe Neotoma so others looking to build that kind of tool know there's a substrate they can build on.