Run History
This is the “remember” pillar, and it’s the reason Mochi exists at all. Agents run a lot of commands on your behalf. The transcript is ephemeral and unstructured, there one moment and gone the next. Mochi keeps the record: what ran, how long it took, whether it failed, and why.
Almost none of that storage is Mochi’s. Flow already records every execution to a shared
embedded datastore, with a record that carries the reference, timing, status, exit code, process
ID, log archive, and the useful part, provenance:
source (cli, desktop, or mcp), clientName (claude-code, cursor), sessionId, and
workingDir. Records are lifecycle-aware: they appear as running the moment a run starts and
update in place when it finishes.
Two of those fields have justifications I like. workingDir exists because the workspace is
already recoverable from the reference but the path is not, and it’s the only thing separating
two checkouts of the same repo. sessionId exists so one assistant’s related runs stay grouped.
Mochi’s contribution is aggregation. A single pass over history rolls executions up per
executable and per workspace, keyed by executable ID rather than by reference so that verb
aliases like run, exec, and start of the same thing all collapse into one bucket. That same
rollup feeds both search ranking and the dashboard, so history gets swept once per invocation
rather than once per feature.
The dashboard turns it into four purpose-built views rather than one generic screen: Welcome for first-run setup, Pulse for health and what’s happening now, Launch for getting back to work, and Insights for activity over time. Insights surfaces the busiest, least reliable, and slowest workflows, plus recommendations. Those are plain heuristics today, a reliability rule and a duration rule, with stable IDs so that dismissing one survives regeneration. They are deliberately built as the seam that model-generated insights will later plug into.