Agent memory doesn’t fail on storage. It fails when Skills can read and write without boundaries.
For a while now, we’ve been circling the same question inside seekdb (OceanBase’s AI-oriented database) and PowerMem (OceanBase’s memory management layer for agents):
How do you give an AI agent memory that actually works over the long run?
An agent that starts from zero every conversation is a poor long-term worker. It needs to remember user preferences, project context, past decisions, and lessons from tool use — including what worked and what didn’t.
Early agent memory setups were usually simple: local files, Markdown logs, a workspace folder, or whatever still fit in the current context window.
That’s fine for experiments. But once an agent is used day after day, the cracks show up fast. How do you sync memory when you switch devices? How do you carry experience across workspaces? How do teams share what their agents learned? And how do you separate user-private memory, project memory, and team memory?
There’s a deeper issue, too: memory isn’t solved by “store everything.”
If an agent just piles up chats, logs, and task traces, it doesn’t automatically get smarter. Often the opposite happens — you end up with more memory and less ability to find what matters when it matters.
So the hard part isn’t persistence. It’s ongoing organization, precise retrieval, and safe reuse.
That’s the problem seekdb and PowerMem are built around.
seekdb focuses on the data and retrieval layer underneath memory — combining structured data, full-text search, and vector search so an agent can pull back what’s relevant to the current task instead of shoveling history back into context.
PowerMem sits closer to a Memory Management Layer for agents. It isn’t only about storage. It’s about the full lifecycle: what to extract, what to keep, what’s stale, what to merge, and what’s worth reusing in future tasks.
User preferences, project decisions, bug-hunt notes, team workflows, tool habits — these shouldn’t die in a single chat. They should graduate from ephemeral context into durable memory the agent can use later.
At larger scale, in production environments that demand higher reliability, OceanBase (a distributed SQL database) can also carry long-term memory with stronger operational guarantees.
In short: seekdb, PowerMem, and OceanBase address the data plane, retrieval, and lifecycle of agent memory.
But once memory is real inside an agent runtime, a new class of problems appears.
After memory is a service, Skills become the new boundary
In an agent runtime such as OpenClaw — where agents load Skills, call tools, and run tasks — memory isn’t just an internal history blob. Third-party Skills may want access to it too.
One Skill might need project history. Another might summarize user preferences. Another might write new lessons back into memory. Others might combine memory with external tools.
That raises very practical questions:
Can a third-party Skill read user-level memory?
Can it write workspace memory?
Can it touch team-shared memory?
Can it obtain database URLs, API keys, or direct connection details to the memory service?
Without clear answers, “memory as a service” can increase risk instead of reducing it.
Long-term memory may hold preferences, project history, team decisions, business context — and also code snippets, configs, error logs, and execution notes. Once that material becomes a durable asset, it can’t be freely read or modified by every Skill.
From an infrastructure perspective, the question isn’t only:
How do we store and retrieve memory?
It’s also:
How do we distribute, execute, and authorize third-party Skills that access memory?
The problem isn’t who can call an API
Technically, calling a memory API is easy.
JavaScript works. Python works. Go works. Rust works. MoonBit (a statically typed language with multi-backend compilation, including WebAssembly) works too.
The real issue isn’t which language can send HTTP. It’s how the runtime enforces boundaries when any third-party Skill can reach memory.
If a Skill holds a PowerMem API key and connects directly, its blast radius is hard to control. It might query memory it shouldn’t see, write where it shouldn’t write, exfiltrate results over the network, or bypass runtime audit — expanding access without the user understanding what happened.
A better model: Skills don’t connect to memory services directly. They request controlled capabilities through the runtime.
For example:
memory.search — retrieve memory within an authorized scope
memory.add — write new memory
memory.update — update existing memory
tool.call — invoke external tools on an allowlist
log.emit — emit controlled logs
In this model, a Skill doesn’t know how to reach PowerMem, seekdb, or OceanBase, and it doesn’t hold API keys. It only knows which capabilities it has been granted.
The runtime performs the actual access.
It checks user, agent, workspace, scope, and Skill permissions; allows or denies the call; and when needed, trims, redacts, or blocks results — while writing an audit trail.
Memory stops being a global resource any Skill can read or write. It becomes a set of capabilities the runtime explicitly grants.
That’s the shift from Memory API to Memory Capability.
An API is an interface.
A capability is something granted — scoped, auditable, and revocable.
Why we started looking at MoonBit + Wasm
A quick intro to MoonBit: it’s a modern, statically typed language aimed at engineering ergonomics and multi-target compilation. It can compile to WebAssembly (Wasm) — a portable binary instruction format — and is a good fit for packaging small, well-defined units of logic.
For agent Skills, we care about MoonBit less as “yet another language” and more as a way to make Skills easier to govern.
A third-party Skill shouldn’t be a one-off script. Over time it may be distributed, installed, reviewed, and granted access to memory, tools, the filesystem, or external services. It should declare: what inputs it accepts, what it returns, what errors it can surface, which permissions it needs, and which memory scopes it touches.
If those boundaries live only in dynamic JSON, prompt conventions, or developer discipline, you can ship quickly — and struggle to govern later. MoonBit’s static typing and compile-time checks can make boundaries explicit before runtime.
Compiled to Wasm, a Skill can run as a lightweight, sandbox-friendly module. It still doesn’t get API keys or direct connections to PowerMem, seekdb, or OceanBase. When it needs memory, it goes through runtime capabilities — same as before.
MoonBit → clearer, more engineering-friendly Skill definitions
Wasm → a module shape that sandboxes well
Runtime → real authorization, audit, and enforcement
Today, many Skills are written in JavaScript or Python. Mature ecosystems, fast iteration — great for proving ideas.
But an open third-party Skill marketplace pays a governance tax: runtimes to install, version skew, long dependency chains, harder supply-chain review.
Native binaries are the other pole. Go, Rust, Zig, C/C++ can produce clean deploy artifacts — excellent for high-trust infrastructure: runtimes, CLIs, daemons, plugin managers, API gateways.
If every third-party Skill shipped as a native binary, though, it behaves more like a normal host process: filesystem, network, environment variables, subprocesses, direct DB connections. Audit and trust costs go up.
We wanted something between scripts and native binaries:
Light to distribute
Clear execution boundaries
Small default privileges
External power only when the runtime grants it
That’s why MoonBit + Wasm landed on our radar.
Wasm is often introduced as “fast code in the browser.” Fair — but on the server, edge, and plugin side, the interesting property is sandboxed execution.
Without explicit host capabilities, a Wasm module doesn’t get the filesystem, network, environment, or subprocesses by default. What it can do depends on what the runtime exports.
That maps cleanly to third-party Skills.
The platform doesn’t run a full-privilege host program. It loads a module in a sandbox: inputs in, computation, results out. Memory, tools, and external services require explicit capabilities.
MoonBit + Wasm doesn’t magically solve security by itself.
Permission checks, audit, redaction, and revocation still belong to the runtime. Wasm supplies a sandbox-friendly module; MoonBit supplies clearer types and boundaries.
Together, they make it easier to fold third-party Skills into capability-based memory access.
From memory to Skills — the problem leads here naturally
Back to the starting question: how do you make agent memory truly durable?
Step one: memory can’t live only in context or local files. It must persist, be searchable, migrate, and reuse.
That’s seekdb, PowerMem, and OceanBase.
Step two: once memory lives inside a runtime like OpenClaw and third-party Skills consume it, you need answers to:
Who can access memory?
What scope — user, workspace, team?
Write access — or read-only?
Can results leave the trust boundary?
Can you audit what happened?
Memory shouldn’t be a casually callable API. It should be a runtime-granted capability.
In that picture:
seekdb — retrieval substrate (structured + full-text + vector)
PowerMem — extract, manage, update, reuse
OceanBase — production-grade persistence at scale
MoonBit + Wasm — Skills as bounded, distributable, sandboxed units that access memory only through the runtime
This isn’t “bolt seekdb onto MoonBit” for its own sake.
It’s what happens when agent memory becomes real in production runtimes: Skill execution and authorization become the next layer.
MoonBit + Wasm is one serious path on that layer.
References
PowerMem: https://github.com/oceanbase/powermem
MoonBit: https://www.moonbitlang.com/
Top comments (0)