Memory
Most agent memory systems are flat files scoped to one user. The agent appends notes, then re-scans them every turn to recall context. That works for a personal assistant. It breaks the moment two agents — or a watcher, or another teammate — need to converge on the same fact.
Lobu uses entity-based memory through Owletto. Facts attach to typed entities (Company, Project, Member), so any agent in your org reads the same record.
Filesystem vs entity memory
Section titled “Filesystem vs entity memory”This is the same split data teams already use. Analysts pull data into a notebook, run scripts, produce charts — then write the durable result back to the warehouse so the rest of the business can use it. Nobody asks an analyst to do every query in production tables, and nobody runs the company off one analyst’s notebook.
Agents need both layers too:
- Filesystem is the agent’s notebook — ephemeral. Downloaded PDFs, scratch scripts, intermediate CSVs, generated reports. One agent, one channel, one task.
- Entity memory is the warehouse — durable. Customer facts, decisions, project state, recurring operational knowledge. Shared across agents, sessions, and operators.
A note on a Slack DM filesystem dies with the sandbox. A fact written to Company:Acme survives and shows up the next time any agent — billing, support, CSM — touches Acme.
For the longer argument and where to draw the line between the two, see Filesystem vs Database for Agent Memory.
Entity memory in practice
Section titled “Entity memory in practice”A single inbound fact lands on the right entity and accumulates alongside everything else known about that customer:
Different sources, same destination. A CSM’s note in Slack, a watcher ingesting Linear bugs, and a credit decision from a separate agent all converge on Company:Acme. The next agent that reads Acme — through search, recall, or an explicit lookup — sees the full picture without re-deriving it from scratch.
This is the moat: shared, queryable, operator-visible memory that survives the sandbox.
Watchers: forcing your agent to dream
Section titled “Watchers: forcing your agent to dream”You don’t sit at your desk thinking about every Slack message — but at night your brain replays the day, drops the noise, and consolidates what mattered into long-term memory. That’s what watchers do for your agent.
A watcher has three pieces: a schedule (how often it wakes), a prompt (what to remember and what to ignore), and an entity to attach memory to. The prompt is the filter — it tells the agent which signals from a noisy event stream actually matter, so it doesn’t write down every OOO message and lunch plan.
watcher.poll(every: 1h)- Incident INC-4421 — checkout-v43 rollback in progress (Dan)
- Caching layer PR pending merge by EOD (Jay)
- INC-4378 postmortem drafting (Nina)
Five events came in; three made it into memory. Sam’s OOO and Nina’s lunch draft drop off the floor — they don’t match the prompt. The agent isn’t online, but the memory is moving. By the time someone asks “what’s going on with Acme?”, the answer is already in the entity.
When to use entity memory
Section titled “When to use entity memory”Reach for entity memory when you need:
- multiple agents (or watchers) to write into and read from the same record
- decisions and context that survive sandboxes and channel resets
- ingested external signal (Linear, HubSpot, Stripe, email) attached to the right customer or project
- operator-visible memory that can be audited and corrected in the UI
If you only need a working directory for one session, the filesystem is enough.
Set it up
Section titled “Set it up”Lobu memory wiring (TOML config, plugin install, CLI) is covered in the Getting Started guide and the Lobu Memory CLI reference.