The Unified Lists dashboard shipped this week. It's a clean CRUD interface: create lists, add items, reorder them, mark them done, promote them to reminders. Standard stuff. The interesting part? Sabine—my AI assistant—was already doing all of this perfectly well through natural language commands.
So why did we build it?
The Trust Problem with Invisible Work
For the past several weeks, I've been managing lists entirely through conversation. "Add milk to groceries." "Show me what's on my work list." "Move that item to the top." It worked. Sabine has seven list tools registered—create_list, add_items, query_items, update_item, delete_item, reorder_items, promote_item_to_reminder—and they all execute reliably.
But here's what I noticed: I didn't fully trust it.
Not because it failed—it didn't. But because I couldn't see the state. When Sabine said "I've added that to your list," I had no way to verify it without asking her to read the whole list back to me. When I asked her to reorder items, I had to mentally model the new sequence based on her description. The work was happening correctly, but it was happening in a black box.
This is the paradox of agent-first design: the better the agent works, the more invisible the system becomes. And invisible systems—even reliable ones—don't earn trust the way visible ones do.
The M4 Milestone: Agent Tools + Human UI
We built the Lists feature in four milestones:
M1 (commit 4da3d12): Tool registration. Seven tools, cluster pattern, all discoverable by the agent runtime.
M2 (commit 48b8a53): HTTP layer. 730 lines of security and performance tests. User isolation, SQL injection guards, content limits, p95 latency contracts.
M3 (commit 44c680c): Agent integration. 435 lines of end-to-end chat tests proving the agent could execute the full create→add→query→promote flow.
M4 (commit 223afbe): The dashboard. Complete visual interface with CRUD operations, optimistic updates, and real-time state display.
M4 wasn't technically necessary. The agent tools were already production-ready after M3. But M4 changed how the system feels to use.
Two Interaction Modes, One Source of Truth
Now I have both. I can tell Sabine "add that book to my reading list" while I'm in a meeting, then open the dashboard later to reorder items visually. I can drag tasks around in the UI, then ask Sabine "what's next on my work list?" and she sees the updated order immediately.
This is the interaction model we're aiming for across the platform: agent-first, but not agent-only. The agent handles the conversational, contextual, multi-step work. The UI handles direct manipulation, overview, and verification.
Both modes hit the same API endpoints. Both see the same real-time state. Neither is a second-class interface. They're complementary.
Optimistic Updates and the Illusion of Speed
One detail that matters: the dashboard uses optimistic updates. When you check an item as done, the UI updates instantly—before the server confirms. If the request fails, we roll it back. If it succeeds, the user never saw a loading spinner.
This is a small thing that makes a huge perceptual difference. The dashboard feels fast not because our API is particularly fast (though it is—p95 under 500ms for CRUD operations), but because we don't make the user wait for confirmation on operations that almost never fail.
The agent, by contrast, always waits. When Sabine marks an item done, she waits for the API response before confirming to me. That's the right behavior for an agent—she needs to handle errors gracefully. But in a UI, optimistic updates are the right move.
Same backend, different interaction patterns.
What This Means for Agentic Products
I think a lot of teams building agent-first products are going to face this same question: do we need a UI for data the agent already manages?
The answer we arrived at: yes, but not for the reasons you'd expect.
The UI isn't a fallback for when the agent fails. It's not training wheels. It's a different mode of interaction that serves different moments: the moment you want an overview, the moment you want to reorder five things at once, the moment you want to verify that the thing you asked for actually happened.
Agents excel at handling natural language, inferring intent, managing multi-step workflows, and working in contexts where you can't look at a screen. UIs excel at spatial reasoning, rapid direct manipulation, and building trust through visibility.
We don't have to choose.
What's Next
The next layer is real-time sync. Right now, if I add an item in the dashboard and then immediately ask Sabine about my lists, she sees the change—but only because she queries fresh on every request. If we added collaborative features (multiple users, shared lists), we'd need WebSocket-based live updates.
We're also exploring progressive disclosure: what if the dashboard only showed high-priority items by default, but Sabine could see and manage the full archive? Different views for different interaction modes, same underlying data.
And we're starting to apply this pattern to other domains. Email intelligence is next—Sabine already analyzes my inbox and surfaces key messages. What does the UI for that look like? Not a replacement for her briefings, but a complementary view that lets me triage visually when I want to.
The dashboard shipped because the work was already proven. Now we get to see how people actually use it.
— Ryan