Two takes on agent memory.

Engram gives a coding agent a brain on the machine it's running on. A Go binary, a SQLite file under ~/.engram/, and a set of MCP tools tuned for the way coding agents work — mem_save, mem_search, session lifecycle, conflict surfacing. It's local-first by default, with optional cloud replication if you want to share between machines.

Markbase is a hosted MCP endpoint that stores plain markdown documents in folders. There's no binary on your machine, no SQLite file, no syncing — agents just point at the URL and read and write the same documents. The contract is "files in folders," not "rows in a database."

They're solving overlapping problems with very different shapes. Which one fits depends on what you want the memory to look like, and who needs to reach it.

Engram's strengths

• Local-first, zero dependencies. One binary, one SQLite file. No service to sign up for, no network round trip.
• Coding-agent-shaped tools. mem_save expects a title, type, and a What/Why/Where/Learned structure. That structure is opinionated in a useful way for coding workflows.
• Open source, self-run. If "I want to own the process and the disk" is non-negotiable, Engram already meets you there.

Where Markbase is shaped differently

Markbase makes the opposite trade-offs on purpose, because the problem we're optimizing for is "a fleet of agents on different machines sharing the same memory" — not "a single coding agent on this laptop."

• Hosted, not installed. There's no binary, no SQLite, no upgrade path to manage. Two minutes from invitation to a working endpoint.
• Plain markdown, not a database. Documents are .md files in folders, with YAML frontmatter. You can read them, diff them, paste them anywhere. There's no schema-versioned table layout to migrate.
• Cross-machine by default. The endpoint is the endpoint. Claude Code on your laptop, Claude.ai in a browser, a CI agent on a build runner — they all hit the same URL and see the same memory. No sync command, no chunked exports, no second machine to enroll.
• Knowledge that crosses projects. An Engram database is per-machine, per-codebase — what one project's agent learned lives there and stays there. Markbase keeps each project's memory in its own workspace, but an agent isn't confined to one: ask it to design something in your new project using the architecture decisions from your old one, and it can read both in the same conversation. Past work becomes input to the next project, not just an archive of the last one.
• Concurrency prevented, not surfaced. Engram surfaces conflicts after both writes have landed, then lets you audit and reconcile. Markbase prevents them at write time: every read returns an ETag; every update_doc sends back the ETag it expects. If the document changed, the second write fails cleanly with an etag_mismatch and the agent re-reads and retries — in a single tool call, with no human in the loop.

Structure, but on your terms

Engram bakes structure into its database schema — mem_save takes a title, a type, and a What/Why/Where/Learned body. That's a sensible default for a single coding agent, and it's the same shape for every save, in every project, forever.

Markbase lets you author the shape. If decisions need a status enum, a date, and a typed link to the record that supersedes them, you write that — drop a _schema.md in the folder and the folder becomes a typed collection. Records inside it are still .md files, but every write conforms to the schema, and agents can query the collection by field like a table. Different shapes for different kinds of memory, in the same store.

Most other agent-memory tools sit at the opposite extreme: they're a scratchpad. Any agent writes anything in any shape, and the only way to enforce a convention is a CLAUDE.md in each repo telling each harness "please use this folder for decisions, this shape for postmortems." Conventions live outside the memory they describe, get replicated by hand, and drift.

Markbase puts those conventions inside the memory store too. Every folder can carry an _markbase.md alongside its _schema.md: what this folder is for, what's append-only, who writes here. Agents working on a path read the _markbase.md chain root-to-leaf before they act, and apply what they find. The shape is enforced; the working conventions travel with the data.

Can I use both?

Yes — and for some setups it's the right answer. Engram is great as a per-machine scratchpad for what one coding agent learned during its own session. Markbase is the shared layer: the architecture notes, the decisions, the long-lived context that other agents on other machines need to read. The two formats are different enough that the split is clean.