The memory graph
Every project has a Sessions tab, and its centerpiece is a navigable graph of what agents have actually done there — not a flat activity log, but a lineage you can traverse from a session down to the exact evidence a script was verified against.
Nodes and edges
Section titled “Nodes and edges”The graph shares its shape with the repository discovery graph on purpose — same {nodes, edges, summary} contract, same node-id conventions (case:{id}, script:{id}) — so the two can eventually merge into one view.
| Node type | Represents |
|---|---|
session |
One MCP agent negotiation |
tool_call |
A single tool invocation inside a session |
evidence |
An observed step from a retained evidence package — selector, route, whether it was fragile |
test_case |
A test case touched by the session |
script |
An automation script touched by the session |
execution |
One run of a script |
Edges are typed by what actually happened: negotiated for a read/inspect call, edited for a mutating one, verified when a run passed, produces for a run that didn’t, observed linking a tool call to the evidence it captured, and grounds linking evidence to the case it supports.
Stage layout
Section titled “Stage layout”The graph renders as stage columns — Sessions, Operations, Evidence, Cases, Scripts, Runs — the same left-to-right lineage read as the repository Discovery Map. Nodes get a parallax depth treatment by column, and edges onto verified or grounded nodes carry a glow so a proven path is visually distinct from an unverified one.
Sessions are colored by origin — MCP over HTTP, MCP over stdio, the web UI, a CI gate, or qmax-code — so you can tell at a glance whether a given piece of work came from an agent, a human, or a pipeline. A session still mid-run is highlighted with its live path; once it goes idle the highlight clears.
Authorization and bounds
Section titled “Authorization and bounds”Visibility on the graph is exactly what the Sessions tab already grants — your own sessions plus anything a teammate shared with the team — the graph never widens access beyond that. Every fetch is capped (30 sessions, 15 tool nodes per session, 400 linked events), and if a cap is hit it’s reported in the graph’s own summary rather than silently dropping nodes: truncated, dropped_sessions, and dropped_tool_nodes are always present, not just when something happened to overflow.
Summary metrics
Section titled “Summary metrics”Alongside the node and edge counts, the graph’s summary carries a small metrics block: fragile_step_rate and dead_click_catch_rate from observed evidence, critic_rejection_rate from automated verification, grounded_case_count, and memory_reuse_rate — the share of sessions in the graph that themselves recalled project memory before acting. That last number is the closest thing to a single-glance answer to “is this project’s agent work actually building on what came before, or starting over each time.”