AI coding agents keep forgetting how you work. mddb is building one shared memory.

The expensive part is the instruction, not the file

Copying a configuration directory through Git, a cloud drive or a dotfile manager can keep identical files in several places. That works when every program expects the same file. AI coding agents do not. A repository rule might belong in CLAUDE.md for one tool and AGENTS.md for another. A reusable skill can require different front matter, folder names or discovery rules. An MCP server may be represented in JSON in one environment and TOML in another.

Literal file sync cannot decide whether two differently named sections express the same rule. It cannot safely translate a personal instruction into a project instruction. It also cannot tell whether a missing block means deletion, an unsupported feature or a parser failure. Treating the file as the product leaves those questions to the user.

mddb instead models instructions, skills, agents, MCP servers and projects as entities. An adapter reads the native file, converts supported parts into that common model, and later renders the model back into the format a chosen agent expects. The bet is that a stable semantic layer can absorb vendor differences better than a growing pile of copy scripts.¹

A canonical model creates a new kind of responsibility

A shared model sounds cleaner than a folder full of files, but it also creates a harder engineering problem. The model must preserve details that matter to one agent without pretending every feature exists everywhere. If Claude Code supports a construct that Codex does not, the adapter needs an explicit compatibility result. Silent loss would be worse than a visible mismatch because the generated file could still look valid.

The repository addresses this with a harness registry, versioned descriptors and adapters built around managed sections. mddb owns the blocks it writes while leaving unrelated user content alone. That boundary matters. A tool that rewrites an entire instruction file can destroy comments, hand-written notes or vendor-specific settings that it never understood.

The current development scope focuses on Claude Code and Codex. The public site names several other agents as future destinations, but support on a landing page is not the same as a tested adapter. A credible release will need a visible compatibility table with versions, supported entities and known losses for every translation path.¹

The system is designed as memory, not another AI

mddb does not place a language model inside the synchronization loop. Its design treats the platform as deterministic memory and delivery machinery: watch a change, parse it, normalize it, record an event, deliver it and apply it through an adapter. Merging content that requires judgment can still be handed to a user's agent, but the server itself is not meant to rewrite instructions through a hidden model call.

That choice has practical consequences. There is no additional model bill for routine sync. The same input should produce the same output. Users do not need to hand the service an unrelated AI provider key. It also narrows the claim: mddb can preserve and move configuration, but it cannot promise that a bad rule becomes a good rule merely because it has been synchronized.

This distinction is easy to lose in a market where every developer product is described as intelligent. A deterministic tool can still be valuable. The standard should be whether it is predictable, reversible and clear about what it changed.

Profiles make the same computer behave differently on purpose

Developers rarely have one universal setup. A personal profile may include experimental skills. A work profile may require a specific review checklist. A client profile may need different server connections and stricter exclusions. Combining all of them into one giant instruction file makes accidental disclosure and conflicting behavior more likely.

The current codebase includes profile creation, listing, switching, archiving and restore flows. Device-level exclusions can keep selected categories or placements local. The intended workflow is closer to choosing a workspace than copying a new dotfile folder by hand. A profile switch should reconcile the managed parts of the environment while preserving content outside mddb's ownership.

Restore is part of the same model. Because changes enter an event log and snapshots represent earlier states, a user can ask to recover a profile rather than hunt through several tool-specific files. The useful test will be whether recovery remains understandable after a real conflict, an offline edit and a partially supported adapter all happen together.

Conflict handling matters more than a perfect demo

Two machines can change the same instruction while one of them is offline. A file service may choose the newest timestamp, create a duplicate or ask the user to compare raw text. mddb records changes as events and has explicit conflict states. The development repository includes three-way merge paths, manual resolution, keep-both handling for bootstrap cases and a guard that stops a conflicted item from being sent as if it were settled.

Those mechanisms are less visible than a polished dashboard, but they determine whether the service can be trusted. A sync product fails at the moment when it confidently overwrites the only correct copy. The public release should make conflict history and the source of each version readable without requiring knowledge of the internal event model.

The same standard applies to interruption. Pausing sync must be different from disconnecting an account. A deferred change must be retried rather than lost when a file is temporarily unavailable. The repository contains work on both behaviors, but long-running public use will reveal failure modes that a test suite cannot simulate fully.

The security promise is specific, but it still needs an audit

Configuration files often contain server URLs, environment variable names and sometimes secrets that should never have been pasted there. mddb's design says secret values must stay on the device. The local layer scans outgoing material for common credential patterns and high-entropy strings before a bundle is uploaded. The planned hosted vault stores references and metadata rather than secret values.¹

The repository also includes defensive work around archive extraction, path containment, workspace isolation and marker injection. These are the ordinary, unglamorous boundaries where a synchronization service can become dangerous. Their presence is encouraging, but this article is not a security audit. The code is private during prelaunch, and the public has not had a chance to inspect, attack or reproduce the claims.

A public release should explain what content reaches a self-hosted server, what reaches the managed service, what remains local, how device tokens are revoked and how logs avoid recording sensitive material. Open source helps only when the published code matches the binaries and hosted behavior people actually use.

Core, Orbit and Fleet are one platform with different obligations

The product is presented in three layers. Core is the local engine plus a self-hosted server. Orbit is planned managed hosting for people who do not want to operate backups, TLS and account infrastructure. Fleet is the future team and enterprise layer. The local plane is intended for an Apache 2.0 release, while the self-hosted server and web layer are planned under AGPL 3.0.¹

Fleet is deliberately described as an overlay rather than a machine-cloning system. A company could distribute required rules or skills above a worker's personal layer, check whether the managed items arrived and keep an audit trail. Personal configuration should remain personal. The team administrator should see the state of required team entities, not the contents of every private rule on the laptop.²

That boundary will be difficult to prove in a dashboard. Inventory can easily grow into surveillance if the product begins collecting session content, prompts or broad activity data. The design documents prohibit those categories and require visible telemetry policy, but Fleet remains a future layer. Its eventual implementation needs separate scrutiny from the personal sync engine.²

The code exists, the public product does not yet

The public page still labels installation as coming soon and directs visitors to a waitlist. The repository reviewed for this article contains a TypeScript monorepo with schema, adapters, a harness registry, a synchronization engine, command-line tools, an MCP host, server routes and automated tests. It also contains unfinished work around onboarding, export and import, overlap handling, release packaging and the hosted service.¹

That difference should shape expectations. A working internal test suite can show that defined cases behave as designed. It does not establish that setup is understandable, that adapters survive vendor updates or that recovery works across months of messy personal changes. Those questions begin after strangers install the software on machines the developer does not control.

The project also promises that its open source repository will appear at launch. Until that happens, outside developers cannot verify the license boundaries, build the client themselves or inspect the secret-handling path. Prelaunch coverage should therefore describe direction and present implementation without awarding trust in advance.¹

Who might need this, and who can keep using Git

The clearest early user is a developer who already uses at least two coding agents or two computers and has meaningful instructions to preserve. The value rises when the setup contains reusable skills, several MCP servers, project rules and profiles that should remain separate. A person with one laptop, one agent and a short instruction file may gain little from another synchronization layer.

Git remains a sensible choice when the files are the same everywhere and the owner is comfortable resolving text conflicts. A private dotfiles repository is easy to inspect and has no new service dependency. mddb has to earn its place by translating formats safely, showing compatibility limits, restoring semantic entities and reducing work that file sync cannot address.

Teams should wait longer. Fleet's appeal is obvious because AI agent configuration is becoming an operational surface, yet the policy, privacy and employee-trust questions are larger than the installation problem. A pilot should start with a narrow team layer, visible data collection and a documented exit path. No administrator should need access to personal instructions merely to confirm that a required work skill is installed.²

What a credible launch must prove

mddb is tackling a real maintenance problem that grows as coding agents multiply. The strongest part of the concept is the separation between semantic entities and vendor files. The riskiest part is the same abstraction: if an adapter misunderstands a rule, one wrong interpretation can spread cleanly to every connected environment.

The first public release needs evidence that readers can inspect rather than a longer feature list. Installation should work on a clean machine. A compatibility matrix should name tested agent versions. Export should recover all user-owned data. Secret scanning should document false positives and limits. Restore should be demonstrated after conflicts and offline edits. The server should be genuinely self-hostable from the published repository.¹

Until those checks are possible, mddb is best understood as a substantial prelaunch build with a clear thesis. It has enough implementation to be evaluated seriously and enough unfinished surface to make restraint necessary. The next meaningful story is not another mockup. It is whether an outside user can install Core, connect two agents, break the setup, recover it and understand every step that occurred.

• Publish the promised source code and reproducible installation path.
• Name exact supported versions and translation limits for each agent.
• Demonstrate export, conflict resolution and restore on two real machines.
• Explain every category of data sent to a server and every category kept local.
• Let users remove the service without losing their native configuration files.