Dashboard has no way to see or manage agent memories; settings tabs should go vertical to make room

[fengtality]

The gap

Agent memories are reachable from Telegram and from chat, but not at all from the web dashboard — which is the primary surface in local mode.

Of the 155 routes the web app registers, zero touch memories or skills:

memory/skill routes: NONE

Agents already have deep routes for strategies, sessions, journals, canvases and learnings (/api/v1/agents/{slug}/strategies/{sslug}/...), so the store is the one part of an agent's state with no API and no UI.

What each surface can do today:

surface	list	read	write/edit	delete
Telegram /memory	✅	✅	❌	✅
Chat (manage_memory MCP tool)	✅	✅	✅	✅
Web dashboard	❌	❌	❌	❌

handlers/memory/ is 171 lines and exposes exactly two callbacks — memory:del:{idx} and memory:refresh — so even Telegram is view-and-delete; editing means deleting and asking the agent to rewrite. The MCP tool has the full set (write | read | search | list | delete | audit).

Why it matters

Memories change what an agent does, silently. A real example from this week: an LP run failed, the agent wrote

agents/condor/store/user_1/memories/consult_lp_agent_before_config.md

and every later LP request routed through consult solana_dex_lp_expert because of it. That is the system working — but the only way to discover why the behaviour changed was to read the file off disk. A dashboard user cannot see that a memory exists, let alone correct one that is wrong or stale.

Memories are also per-agent and per-user:

agents/<agent_slug>/store/user_<id>/memories/<name>.md

so the same agent remembers different things depending on whether you arrived via Telegram (user_456181693) or local mode (user_1). That split is invisible today and is exactly the kind of thing a UI should surface.

Proposal

1. API: /api/v1/agents/{slug}/memories — GET (list), GET /{name}, PUT /{name}, DELETE /{name}. MemoryStore already exists and is what both other surfaces use, so this is a wrapper, not new machinery.
2. UI: a Memories section in Settings — list by agent, show description and body, allow edit and delete. Editing is the capability no surface has today.
3. Show which user_<id> store is being viewed, since the Telegram/local split is otherwise invisible.

Worth deciding as part of this: whether skills (same store, skills/ beside memories/) belong in the same panel.

Settings tabs: horizontal → vertical

Adding Memories makes an existing problem worse. frontend/src/pages/Settings.tsx has six tabs, seven for admins:

Servers | Gateway | Keys and Wallets | LLM Endpoints | Voice & AI | Privacy | (Admin)

rendered as a single horizontal row where every tab is flex-1 — equal width, no wrapping, and no overflow-x:

<div className="mb-6 flex gap-1 rounded-lg border ... p-1">
  <button className={`flex-1 rounded-md px-3 py-1.5 text-sm ...`}>

So each new tab makes all of them narrower rather than scrolling, and the longest labels ("Keys and Wallets", "LLM Endpoints") are already the ones under pressure. On a narrow viewport they squeeze instead of overflowing.

Suggest switching to vertical tabs — a left rail with the panel to its right:

• room for 8+ sections without shrinking anything, so Memories (and whatever follows) costs nothing
• long labels stop competing for horizontal space
• the pattern most settings screens use, and it reads naturally at the width the dashboard already has
• ?tab= deep-linking and the admin-tab gating stay exactly as they are — this is layout only

Notes

Memory files live under agents/**/store/, which is gitignored and also excluded from the file watcher, so nothing here changes what ships or triggers handler reloads.

Related but distinct: #152 (serverless consults lose their memory/skill scope). This issue is about there being no dashboard surface at all.

🤖 Generated with Claude Code

https://claude.ai/code/session_0166iQoxKce23GkUwuQJxdkr