Memory is not a side quest
Facts have to survive the run. If you stand up the store yourself, you are still doing the ops half.
- Memory
- Ops

Agents that forget the last run are toys. The useful ones keep facts — plan is annual, last invoice failed — and read them back next time, without you wiring a store for every graph.
That is usually treated as a side quest. First you get the loop working. Then someone stands up a table. Then someone else stands up embeddings. Then the next graph cannot see what the last one wrote, because the glue was local.
We think this is a host problem. The graph should ask for memory. The host should keep it. In Linea that is a memory node: write a value under a key for the end user in the run, read it back on the next run, and add an expiry if it should not live forever. No weekend of schema design.
This is not a claim that memory is easy. It is a claim about who operates it. If the store is yours, you are still writing the ops half. We built Linea so that part comes with the run, and so every workflow that shares a namespace reads the same store.
If you already like your own database, keep it. Linea is for the case where the store exists only because the agent needed somewhere to put a fact.

