Skip to content
API Blog

Memory

Lobu has two memory layers:

  • Filesystem for short-term working memory inside one sandbox
  • Owletto for long-term organizational memory shared across agents, users, and threads

The filesystem is where an agent does work. Owletto is where the organization remembers what matters.

Each Lobu user, channel, or DM gets its own filesystem workspace. That is the agent’s short-term working area for the current job:

  • downloaded files and raw inputs
  • scratch scripts and notebooks
  • generated reports, CSVs, and images
  • temporary intermediate outputs

Owletto is the separate memory product behind Lobu’s shared-memory layer. It stores durable knowledge so other sessions and agents can recall it later.

filesystem = short-term working memory + artifacts
owletto = long-term organizational memory

Compared with local filesystem memory, Owletto gives Lobu:

  • memory shared across agents, users, and threads
  • typed entities and relationships instead of loose notes
  • hybrid recall across entity lookup, text search, and semantic search
  • connectors and watchers for external data ingestion
  • an operator UI to inspect, edit, and correct memory

Use the filesystem for active work. Use Owletto for durable facts and shared organizational context.

If you want a non-Lobu agent to understand and use Owletto well, install the Owletto skill separately:

Terminal window
npx owletto@latest skills add owletto
npx owletto@latest init
  • owletto skills add owletto installs the starter skill into a local skills/ directory.
  • owletto init configures MCP/auth for supported clients.

For OpenClaw-specific setup, use:

Terminal window
npx owletto@latest skills add owletto-openclaw
npx owletto@latest init

In Lobu, memory is pluggable per agent. To use Owletto as the shared memory backend, configure [memory.owletto] in lobu.toml:

[memory.owletto]
enabled = true
org = "my-org"
name = "My Project"
models = "./models"
data = "./data"

At runtime, Lobu resolves memory like this:

  • If [memory.owletto] is enabled, Lobu derives the effective Owletto MCP endpoint from org
  • MEMORY_URL remains an optional base-endpoint override for local or custom Owletto deployments
  • If no Owletto endpoint is resolved, Lobu falls back to @openclaw/native-memory
  • Agents can still override plugin configuration through pluginsConfig

The @lobu/owletto-openclaw plugin adapts OpenClaw memory calls to Owletto MCP calls through the gateway proxy, so workers never need raw Owletto credentials or third-party OAuth tokens.

At a high level, Lobu + Owletto memory recall works like this:

  1. A user sends a message to a Lobu agent.
  2. Lobu routes the request into the worker and loads the active memory plugin.
  3. Owletto identifies likely entities and retrieves related knowledge.
  4. Recall combines entity-name matching, text search, and semantic search.
  5. That recalled context is injected before prompt construction.
  6. During the turn, the agent can search, read, and save new knowledge back into Owletto.
  7. Operators can review or correct memory in the Owletto UI.

Agents that talk to Owletto directly usually follow this pattern:

search_knowledge -> read_knowledge -> save_knowledge

Use:

  • search_knowledge to find relevant entities and context first
  • read_knowledge to inspect saved facts or semantic matches
  • save_knowledge to persist durable facts and supersede stale ones

Owletto is the right fit when you want:

  • multiple agents to share one memory space
  • memory that survives local sandboxes and channel filesystems
  • OAuth-managed integrations without handing tokens to workers
  • scheduled ingestion and analysis of external sources
  • operator-visible memory that can be audited and corrected

If you only need a local working directory for one session, the filesystem is enough. If you want durable, queryable organizational memory, use Owletto.