mddb wants your AI agents to remember across every machine

An AI coding agent can learn a team's habits quickly. Tell it to run migrations before schema changes, use a particular test command or never edit generated files, and the next answer can improve. The trouble begins when that instruction stays inside one tool on one machine.¹

mddb is trying to make that accumulated setup portable. The publisher-connected project now describes itself as memory for AI coding agents, covering rules, skills, MCP servers, subagents and agent memory across Claude Code, Codex and Qwen Code. Top Apps HQ and mddb share a publisher, so this is a disclosed project feature, not independent coverage or a review.^1,2

The real asset is becoming memory, not configuration

The first version of the mddb story was easy to explain as configuration sync. A developer had CLAUDE.md in one place, AGENTS.md in another, separate MCP definitions and a pile of copied skills. mddb treated those files as versions of the same working setup and tried to keep them aligned.^1,4

That problem still exists, but it may become less important as agent harnesses learn to configure themselves. The harder asset is what the user and agent discover together: the exception that fixed a deploy, the test habit that prevented a regression, the reason a tempting library was rejected, or the preference that makes answers useful.¹

Memory compounds because each useful fact can improve later work. It also becomes expensive to abandon. If months of corrections sit in a proprietary cloud or a hidden local database, switching agents does not merely change a tool. It resets part of the working relationship.^1,2

mddb's new framing is that memory should belong to the user and travel between harnesses. Configuration is one expression of that memory, not the whole product. A rule may appear in CLAUDE.md for Claude Code, AGENTS.md for Codex and QWEN.md for Qwen Code while remaining one managed item with history.^1,2

The project still syncs rules, skills and MCP configuration.
Its wider goal is portable memory that survives a change of agent or machine.
The public site names Claude Code, Codex and Qwen Code as current harness targets.

What portable memory changes in ordinary work

Consider a developer who uses Codex on a desktop, Claude Code on a laptop and a third agent for quick reviews. Without a shared layer, every correction must be repeated. One agent may know the repository uses a special release command while another confidently runs the wrong default.¹

A portable memory item can be captured once, translated to the placement each harness understands and restored on a new machine. The public mddb example shows one instruction moving into the managed section of each agent's native file. The user should not need to replace the tools or force every vendor into one format.^1,2

The practical gain is not a futuristic universal brain. It is less repetition at the start of ordinary tasks. A restored machine knows the approved skills. A second agent sees the same repository rule. A rollback can undo the instruction that caused bad behavior yesterday.¹

This also creates a visible object that can be reviewed. Instead of important behavior hiding in a long conversation, a team can see that an instruction exists, where it applies and which version changed. That does not make the instruction correct, but it gives people something concrete to inspect.^1,3

One correction can be placed in several agent-native files.
A new machine can restore the same selected setup.
History makes accidental or harmful changes easier to identify and undo.

mddb Core, Orbit and Fleet are three different promises

mddb Core is the open-source foundation. The public site presents it as the self-hosted route for people who want the server and data under their own control. Core is the relevant choice for a solo developer who can operate a service and wants no hosted account dependency.^1,2

Orbit is the planned hosted service. Its page describes device-code enrollment, automatic discovery of supported harnesses and a dashboard where a person chooses what to sync. It also says nothing has to run continuously in the background on the developer's machine: changes sync inside harness sessions or when the user runs the sync command.²

Fleet is for organizations. The proposal adds a team layer above personal setup so an administrator can roll out mandatory skills and practices, inspect version compliance and stage changes to a subset of machines. The public page says personal layers remain separate and that session content, prompts and code are not collected for fleet compliance.³

These tiers should not be collapsed into one maturity claim. Core, Orbit and Fleet have different users and risk profiles. The public installer is still labeled coming soon, Fleet is explicitly coming soon, and the inspected repository describes a late-alpha, pre-release system rather than a finished consumer service.^1,2,3

Core is the open-source, self-hosted foundation.
Orbit is the planned hosted sync product for individuals.
Fleet is a planned enterprise control layer, not a generally available individual feature.

The security boundary is more important than the sync speed

Agent configuration sits uncomfortably close to secrets. MCP definitions may refer to tokens. Shell snippets may include credentials. A memory captured from a debugging session can accidentally contain private paths, customer names or an API response. A sync product that ignores this boundary can create a new central leak.^1,2

mddb's public promise is that API keys and tokens are not uploaded. It says only references and environment-variable names should sync, with secret scanning intended to block accidental credential capture. The local design also separates managed content from local placeholders so a restored machine still obtains its secret from its own environment.¹

That is the right principle, but a public statement is not an external security audit. Anyone testing the alpha should use a dedicated environment, inspect the exact objects before sync and verify that exported data contains no token value. Self-hosting reduces one dependency; it does not remove mistakes in capture, access control or backups.^1,2

Memory introduces another privacy category beyond credentials. A note can reveal a business plan, health condition, internal incident or a person's preference without containing a formal secret. The safe default should be selective sync, clear scope and an easy way to inspect and delete an item before it travels.^1,2

Tokens and API keys should remain local; verify this in actual exports.
Treat memory as sensitive even when it contains no credential.
Start with a disposable environment and a narrow sync scope.

Translation between agents is the difficult technical part

Copying one file to another is easy until the tools disagree about structure. One harness reads a single root instruction file. Another supports scoped files by directory. Skills may be folders, commands or database records. MCP servers use similar concepts with different JSON shapes and placement rules.¹

mddb uses adapters to translate one logical entity into each harness's native representation. The public example turns one rule into managed sections of CLAUDE.md, AGENTS.md and QWEN.md. That approach respects the tool a user already has, but it creates a hard question: what does not translate cleanly?^1,2

A responsible adapter must preserve unsupported fields or refuse rather than silently flattening them. Otherwise a successful sync can change meaning. Placement, precedence and merge behavior need tests because an instruction at the repository root may behave very differently from the same sentence in a global profile.¹

This is where history and rollback become more than convenience. If a translated change damages one harness, the system needs to show the source entity, rendered file and exact version, then restore the previous state without overwriting unrelated local edits.^1,2

One logical rule may render differently in each harness.
Unsupported semantics should fail visibly, not disappear.
Rollback must preserve unrelated local content.

What the alpha should prove before public release

The first proof is lossless round-trip behavior. Import a real setup, sync it, restore it on a clean machine and compare the meaningful files. Comments, ordering and local-only sections should not vanish merely because an adapter understood the core fields.^1,2

The second proof is conflict behavior. Two agents can edit the same instruction while disconnected. A safe product cannot quietly choose the most recent timestamp when both changes matter. It should show the conflict, explain the options and make the resulting history auditable.¹

The third proof is recovery. Delete a managed file, remove a machine, rotate a credential reference and restore an old snapshot. Backup stories become credible only after destructive tests demonstrate what returns, what intentionally stays local and what the user must recreate.^1,2

Finally, installation and upgrade need to be boring. The public pages currently label the install command coming soon. Before that command is promoted, it should be pinned, inspectable and reversible, with supported platforms and data paths documented. A memory product should not begin by asking users to trust an opaque bootstrap.^1,2

Test import and restore on a clean machine.
Force conflicting offline edits and inspect the resolution.
Verify deletion, rollback, backup and uninstall before trusting valuable memory.

Who should try it now, and who should wait

The current audience is an experienced developer who already uses several coding agents, understands their configuration files and can isolate an alpha deployment. That person can provide useful evidence about adapters, conflict handling and whether portable memory reduces repetition.^1,2

A team with production credentials, regulated data or dozens of machines should wait for a versioned release, threat model, operational documentation and independent security review. Fleet's governance idea is interesting precisely because the failure radius is large. Early screenshots are not enough.^1,3

A single-agent user on one machine may not need mddb at all. Git, encrypted backups and a disciplined dotfiles repository can solve much of the configuration problem. mddb becomes more compelling when translation, live capture, history and cross-machine restore remove real repeated work.^1,2

The project's strongest claim is not that every AI agent needs another cloud. It is that the memory created through human correction should remain portable and inspectable. If mddb can prove that boundary without collecting secrets or flattening agent-specific meaning, it addresses a lock-in problem that will grow as agents get more personal.^1,2,3

Try now only in an isolated environment if you are comfortable evaluating alpha software.
Wait if the setup contains production secrets or requires audited controls.
Use the project only when it solves real multi-agent or multi-machine drift.

Sources and method

This is publisher-connected coverage. Top Apps HQ inspected the current local mddb repository, status and release-readiness documents, then compared those implementation claims with the public pages at mddb.cc, Orbit and Fleet. No independent reviewer or external customer evidence was available. The public installer is still marked coming soon, so this article describes a late-alpha, pre-release product direction rather than a generally available service.

mddb: portable memory for every AI coding agent mddb · August 2, 2026 · primary
mddb Orbit: hosted sync for AI agent setup and memory mddb · August 2, 2026 · primary
mddb Fleet: team control for AI development environments mddb · August 2, 2026 · primary
The previous Top Apps HQ feature on mddb configuration sync Top Apps HQ · July 22, 2026 · context