Most AI tooling arrives with a dependency manifest that reads like a startup’s hiring plan.

Frameworks, adapters, clients, compatibility shims. Before you write a single line of business logic, you’re carrying 40 packages.

MeMesh deliberately chose a different path: three production dependencies.

That’s it.

Why Dependency Count Is a Design Decision

Dependencies aren’t free. Each one is:

When you add a dependency, you’re making a bet that the value exceeds the cost. For most “convenience” packages in AI tooling, that bet doesn’t pay off.

The FTS5 Argument

The most common pushback is: “But what about vector search? Semantic similarity? Embeddings?”

This is a valid question. It’s also usually wrong for the problem at hand.

FTS5 — SQLite’s built-in full-text search — handles the vast majority of agent memory queries with:

When a developer asks “what did we decide about the auth middleware?”, keyword proximity beats cosine similarity. The query is specific, the vocabulary is shared, the user knows what they’re looking for.

Vector search shines for semantic fuzziness: “find content similar in meaning.” That’s a different problem.

Operational Trust

There’s a deeper reason for minimal dependencies: operational trust.

When a tool misbehaves, you want to know exactly what it’s doing. A tool with three dependencies is auditable in an afternoon. A tool with forty is a black box.

For software that has persistent access to your project state — like a memory plugin — this matters more than it does for a one-shot utility.

The Constraint Is the Feature

The discipline of asking “do we actually need this?” before adding any dependency has made MeMesh more reliable, not less capable.

The result: 76 tests pass in 1.35 seconds. No native binary conflicts across platforms. No breaking changes from upstream updates. No surprise CVEs from transitive dependencies.

Minimalism in tooling isn’t about pride. It’s about respect for the systems that depend on you.