DEV Community: Debbie Shapiro

Multi-Agent Coordination Using Shared Memory

Debbie Shapiro — Mon, 14 Sep 2026 02:48:56 +0000

When a fleet of autonomous agents has to work together, the hardest part is keeping everyone on the same page. In a recent fleet deployment we scaled from three agents to ten (see what we learned scaling that workforce), each pulling data, transforming it, and publishing results for downstream pipelines on an hourly schedule. The agents never spoke directly to each other; instead they read and wrote a shared memory layer built on LoreConvo and LoreDocs. The result was a system that stayed consistent across runs, recovered gracefully from failures, and let new agents join without a single line of integration code.

Why shared memory matters for autonomous agents

Agents that operate in isolation quickly diverge. One agent may decide to rename a column, another may assume the original name still exists, and a third may generate a report that mixes the two schemas. By giving every agent a single source of truth, we eliminated that drift.

LoreConvo's cross-surface session memory lets an agent store the outcome of a run as a session, tag it with the project name, and link it to any prior sessions that contributed to the result. When the next agent starts, the auto-load hook automatically pulls the most relevant prior context, so the new run begins with a concise digest of what has already been decided. Full-text search powered by SQLite's FTS5 makes it easy to locate a session by keyword -- an agent can ask "how did we handle missing values in the last month?" and receive a list of matching sessions, even when the exact phrase never appeared in any of them (we go deeper into why FTS5 held up at this scale in our search engine benchmark).

LoreDocs stores knowledge in named vaults, each searchable with the same FTS5 engine. The Pro semantic index bridges the gap between terminology and intent, so when an agent queries a data quality rule that was written under a different name, the right document still surfaces.

How LoreConvo and LoreDocs keep the memory coherent

The first step was to give each scheduled job a project tag. Tags let us group sessions by the data pipeline they belong to, and the usage stats dashboard gave immediate visibility into how many sessions each project generated per day. Skill history tracking recorded which tools each session used, so we could later audit whether a particular transformation relied on a deprecated library.

When a session finished, the auto-save hook ran without any user interaction. It extracted a heuristic summary, captured tool calls, recorded tech-stack facts, and surfaced open questions when the log contained enough signal. Because the data lives in a local SQLite file that the user owns, we never had to worry about cloud-side latency or compliance concerns.

For sessions that needed tighter coordination, we used session linking and related-session discovery. Linking creates an explicit chain so an agent can follow the lineage of a transformation from raw ingest to final report. The related-session discovery feature looks for keyword co-occurrence and embedding similarity, then suggests sessions that are likely to be useful -- in the ten-agent fleet this cut the time spent searching for precedent by more than half.

LoreDocs complemented session memory by providing a structured vault for documentation (see the vault architecture blueprint for how vaults are organized). Each vault is scoped to a workspace directory, so when an agent started it could open the appropriate vault and instantly access all relevant design notes, schema diagrams, and versioned documents. Document versioning let us roll back a change to a data dictionary without hunting through git history. The Pro semantic index chunked each document at the paragraph level, allowing agents to retrieve the exact paragraph describing a data quality rule even when the rule was phrased differently in the code.

LoreConvo exposes a CLI for bulk operations -- its export and import commands moved a month's worth of sessions between development and production, and because the export format preserves UUIDs, re-importing was idempotent and safe. LoreDocs offers its own CLI for vault and document management; since a vault is just a portable SQLite file, keeping documents in sync across environments was just as straightforward.

External tools such as managed agents sometimes needed to run in the same environment. By marking those sessions as external, LoreConvo automatically excluded them from auto-load and search, preventing accidental contamination of the core memory. When we did need to include them, a single environment variable override made the sessions visible again.

Practical lessons from a ten-agent deployment

Starting with clear project boundaries proved to be the single most important decision. Tagging sessions and vaults by project gave immediate visibility into who was writing what, and the usage stats dashboard turned that visibility into actionable data about which pipelines were generating the most memory churn.

Letting the system handle persistence removed a class of problems entirely. The auto-load and auto-save hooks meant no agent had to implement its own persistence logic. Because the hooks run on every session end, we never missed a summary, and the heuristic extraction captured decisions that would otherwise have been lost in log files.

Session linking and related-session discovery work best when you treat them as a workflow primitive rather than a search utility. When an agent needed to recompute a metric, it followed the session links back to the original data source, then used discovery to find any recent experiments that touched the same columns. That pattern replaced ad-hoc log searching with a repeatable workflow.

Separating documentation from code -- while keeping them connected -- turned out to be the right abstraction. Storing design notes in LoreDocs vaults meant that agents could query the same knowledge base that engineers used for onboarding. The workspace-scoped vault behavior reduced friction: a new agent starting in a fresh directory automatically opened the appropriate vault.

Guarding against external noise matters more than it looks. Marking sessions that originated from third-party agents as external prevented those sessions from polluting the auto-load context. When we later needed to audit those runs, we could include them explicitly with a single flag.

Local-first portability proved its value when we spun up a fresh test environment. Because all data lives in a single SQLite file, moving the memory layer to a new machine was as simple as copying the file. The agents immediately had access to the full history without any network configuration.

Pro features became essential as the session count grew beyond a few hundred. The hybrid semantic search improved relevance significantly over FTS5 alone, and the LLM-based async summarizer upgraded heuristic summaries to higher-quality text that in turn improved the relevance of auto-load digests. The consolidation log gave us transparency into when and why a memory digest was injected, which made it straightforward to tune the TTL setting and reduce token overhead in downstream prompts.

The result

The shared memory approach turned a loosely coupled set of scheduled jobs into a coordinated team of agents that could reason about each other's work. The combination of LoreConvo's session management and LoreDocs' vault system provided a single, portable source of truth that was easy to query, easy to extend, and easy to back up.

If you are building pipelines that rely on multiple AI components, or you want a reliable way to keep your agents on the same page, you can explore both tools. If you are working through a larger deployment, get in touch.

MCP memory servers deserve their own category

Debbie Shapiro — Sun, 13 Sep 2026 00:50:13 +0000

When a data engineer or AI practitioner moves from one prompt to the next, the context often evaporates. A model may have just worked through a tricky data pipeline, but the next session starts with a blank slate, forcing you to copy-paste snippets, re-type configuration, or rebuild the mental map of decisions you just made. The friction adds up, especially when you are juggling multiple development surfaces -- Claude Code, the Codex desktop app, Cursor IDE, and Hermes Agent. What if the memory that powers those sessions could live in a single portable file that follows you across tools, projects, and machines?

The missing piece in modern LLM workflows

Large language models excel at reasoning, but they do not retain state between calls unless you explicitly provide it. In practice this means developers either store everything in external databases, write custom glue code, or accept that each new session starts from zero. External databases introduce latency, require network access, and add operational complexity that many engineers would rather avoid. Custom glue code quickly becomes a maintenance burden, especially when you need to support several IDEs or agents.

The result is a fragmented experience: a useful insight captured in one surface is invisible to the next, and the effort to reconstruct that insight grows with each handoff. The community has begun to talk about "MCP memory" and "session-persistence servers" as a way to standardize how LLM-driven tools keep track of work. Yet the concept still lacks a clear definition, a reference implementation, and a place in the ecosystem's taxonomy. Without a concrete example, the idea remains abstract, and tool makers are left guessing how to build reliable, portable memory layers. That is the gap a curated category would fill.

LoreConvo as the reference implementation

LoreConvo was built to answer exactly that need. It provides a local-first memory backend that works as a native MCP server on every major surface that supports the MCP protocol. A single .mcp.json configuration file placed in a project directory enables Claude Code, the Codex desktop app, Cursor IDE, and Hermes Agent to read and write sessions without any additional setup. Because the storage is a single SQLite file that lives on your machine, you retain full ownership of the data, can back it up with any file-sync tool, and move it to a new machine without re-creating accounts or re-authorizing services.

Cross-surface session memory means that a conversation you start in Claude Code can be recalled automatically when you open the same project in Cursor IDE. The auto-load hook runs at the beginning of each session, pulling in the most relevant prior context based on project tags, skill history, and linked sessions. At the end of the session, the auto-save hook fires without any user action. It extracts a heuristic summary: a brief description, the decisions made, the tech-stack facts discovered, and any open questions the model signaled. Open-question capture is heuristic -- when the session contains enough signal the hook records the question, otherwise it is omitted. If you want a deeper look at how this compares to Anthropic's built-in memory approach, the four-way comparison post covers it in detail. And if you are wondering whether local-first storage creates operational overhead, this post on local-first agent memory addresses that directly. Saved data is stored locally, and you can edit or delete any entry through the memory inspection UI.

The free tier gives you fifty sessions, full-text search, and export/import to explore the workflow. Pro removes that limit and adds team memory -- export selected sessions to JSON and import them on a teammate's machine with no server required. Pro also unlocks related-session discovery, which combines keyword co-occurrence with semantic similarity to surface sessions likely to help solve a new problem. A memory consolidation tool distills recent history into a digest injected at session start, so you arrive with context rather than hunting for it.

All of this is exposed through 39 MCP tools -- each callable from any supported surface -- covering session management, onboarding, usage stats, related-session discovery, and memory inspection. The tools are composable, so you can build custom pipelines that fit your workflow without writing glue code.

Why a curated category matters

Having a concrete reference implementation clarifies what "MCP memory" and "session-persistence server" actually mean in practice. It shows the concept is not just a theoretical abstraction but a set of interoperable features that can be measured, compared, and improved.

When the community adopts a curated category, standardized expectations follow naturally. Developers know that an MCP-compatible memory server will provide cross-surface session recall, local ownership of data, and a set of management hooks -- which reduces the friction of evaluating new tools. Tool makers can target a well-defined API surface instead of reinventing storage layers for each product, leading to faster onboarding and more consistent user experiences.

Clear benchmarking becomes possible too. With a reference implementation, performance, storage efficiency, and feature completeness can be measured objectively. Rankings can then focus on real differences rather than vague marketing claims. Because LoreConvo stores data in a plain SQLite file and offers Python fallback scripts for environments without MCP support, developers can also extend the system, write custom exporters, or integrate with other data pipelines without waiting for a vendor update.

Local-first storage reduces risk in a more fundamental way: no hidden cloud dependencies, no surprise data-loss events, and full auditability. Teams can comply with internal data-governance policies while still enjoying the convenience of persistent LLM memory.

By positioning LoreConvo as a fully featured, cross-vendor MCP memory server, the ecosystem gets a solid foundation on which to build the next generation of AI-augmented development tools. The category will evolve, but the core principles -- portable local storage, automatic context injection, and a rich set of management hooks -- provide the benchmark.

Ready to try a memory layer that follows you across Claude Code, Codex, Cursor, and Hermes Agent? Explore the full toolset or subscribe to get posts like this weekly: Dispatches from the Labyrinth.

PS: We are accepting early access signups for a lifetime deal -- join the waitlist to be notified when it opens.

Related reading:

AI Memory for Claude: An Honest 4-Way Comparison -- comparing the memory primitive, claude-mem, mem0, and LoreConvo
LoreConvo: Coordination, Portability, No Lock-In -- why a memory layer has to travel across tools without locking you in

Which to Use: MCP, Function Calling, or Plugins

Debbie Shapiro — Wed, 09 Sep 2026 02:34:30 +0000

When clients ask me how to connect an AI model to their existing data stack, the conversation almost always comes down to three patterns: Model Context Protocol (MCP), function calling, and plugins. They solve related problems but they are not interchangeable. Using the wrong one adds unnecessary complexity; using the right one keeps the architecture clean enough to maintain two years from now.

Here is the mental model I reach for, built from projects across finance, healthcare, and e-commerce.

What Each Pattern Actually Is

Before the decision tree, the definitions -- because "MCP" and "plugin" are terms that get used loosely and that looseness causes real architectural mistakes.

Model Context Protocol is Anthropic's open standard for exposing tools to an AI model in real time. You write an MCP server -- a small process that declares a set of tools in a JSON manifest -- and a compatible client (Claude, for example) connects to it via STDIO or SSE. During a conversation the model can invoke those tools directly and receive results within the same turn. The key characteristic is that the connection is live and bidirectional: the model is an active participant in the session, not just a function that returns JSON.

Function calling is a lower-level pattern available through the raw chat completions API. You pass a tools array when you call the model; the model may return a tool_use content block naming a function and its arguments; your code executes the function and passes the result back in the next turn. The critical difference from MCP is that your code is fully in control of execution. The model proposes; you decide whether to act. This matters when you are running the model inside a batch job or a data pipeline where you need deterministic control over timing, retries, and parallel execution.

Plugins are packaged, distributed tools built on top of MCP (in the Claude ecosystem) or function calling (historically, in the OpenAI ecosystem). When you publish a plugin to the Anthropic marketplace, you are shipping an MCP server with a manifest that end users can install without writing any code. The plugin pattern is the distribution and packaging layer, not a separate protocol. If you need to share a tool broadly -- internal teams, paying customers, or the general public -- a plugin is how you do it without giving everyone access to your backend.

The Decision Tree

The fastest way to pick a pattern is to answer three questions in order.

Who controls when the tool runs? If the model decides when to call the tool based on the conversation, you are in MCP territory. If your code decides when to invoke the model and what to do with the result, you are in function-calling territory. This is the sharpest dividing line. An AI assistant that a data analyst talks to in real time belongs in the model-driven bucket. A nightly batch job that uses an LLM to classify support tickets belongs in the code-driven bucket.

Who consumes the tool? If the answer is "my application or my team," you build an MCP server and connect your client to it directly. If the answer is "other teams in the company without engineering support" or "paying customers," you package it as a plugin and let the marketplace handle distribution and versioning.

Third: Does the tool need to maintain state across turns? MCP servers can be stateful -- they run as a persistent process and can hold context between calls within a session. Function calling is stateless by design; each call is a fresh invocation. If your tool needs to track a multi-step workflow (a data quality remediation process that spans several model turns, for example) MCP handles that natively. With function calling, you manage state externally in your application layer.

Where Each Pattern Wins in Practice

Function calling is the right default for data pipelines. When you need to enrich a million records by running each one through a classification model, you want your orchestration code in charge. You can parallelize the calls, validate the outputs against a schema before writing, and retry failures without the model knowing anything went wrong. LangGraph workflows, dbt post-hooks that trigger model calls, and Spark jobs that use LLMs as UDFs all fit this shape. The LangGraph vs simpler tool-calling post goes deeper on where orchestration frameworks add value versus when a direct function call is enough.

MCP is the right default for interactive, session-based tools. If you are building an internal analytics assistant that your team uses in Claude's desktop client, MCP lets you expose your data warehouse, your internal APIs, and your file system as tools without writing a custom chat loop. The model handles the multi-turn reasoning; your MCP server handles the data access. The MCP Servers Explained post covers the mechanics in more depth if you are starting from zero.

Plugins are the right default when distribution is the problem. I have built MCP servers for several clients where the engineering team is happy maintaining the server but the business wants to roll it out to fifty analysts who just want to install a tool and start asking questions. Packaging as a marketplace plugin means the analysts get a one-click install, the engineering team ships a standard MCP server, and nobody has to teach non-engineers how to edit an .mcp.json file.

The Hybrid Case

Most mature setups use more than one pattern. A common architecture I see: function calling handles the batch enrichment and anomaly detection jobs that run on schedule; an MCP server exposes the results and supporting data to an interactive assistant the operations team uses to investigate anomalies; and a plugin wraps that MCP server so new teams can be onboarded without a configuration session with engineering.

These three layers do not compete. They solve different parts of the same problem.

A Note on Switching Costs

The patterns are not equally easy to swap out once you are in production. Function calling lives entirely in your application code, so you can change models, change schemas, or change orchestration frameworks without touching the AI layer. MCP creates a coupling between the server protocol and the client -- not a painful one, but something to design for. Plugins add a marketplace dependency; updating a published plugin requires a review cycle and you have to manage backward compatibility for existing installations.

If you are early in a project and are not sure which pattern you will need long term, start with function calling. The control it gives you is easiest to trade away when you later decide to move to an MCP architecture. Going the other direction -- from MCP to function calling -- tends to require rethinking the state management approach.

Ready to Map This to Your Stack?

Choosing the right AI integration pattern early saves months of rework later. If you are trying to decide where MCP, function calling, or plugins fit in your specific architecture, I can help you map it out. Reach out through the contact page and we can run through the decision tree for your use case.

Get posts like this delivered weekly: subscribe to Dispatches from the Labyrinth.

LoreConvo: Coordination, Portability, No Lock-In

Debbie Shapiro — Wed, 02 Sep 2026 19:29:43 +0000

When a data engineer or AI practitioner jumps between a code editor, a chat assistant, and a collaborative workspace, the mental overhead of keeping context alive is a real cost. You finish a debugging session in Claude Code, switch to a brainstorming chat, and later open a new session -- to discover that the decisions you made an hour ago are sitting in a separate log you cannot easily find. Duplicated effort. Missed connections. Context that should have followed you, but did not.

LoreConvo was built to close that gap. By treating every interaction -- whether a code snippet, a design discussion, or a tool invocation -- as a single searchable memory item, it lets you move between surfaces while keeping the full story of your work intact. Three pillars make that possible: coordinated multi-agent handoff, cross-surface persistence, and true data portability.

Multi-Agent Coordination

Modern AI workflows increasingly involve more than one agent. One generates a draft, another runs analysis, a third handles deployment checks. When those agents share no common memory, each one starts cold -- and the gaps between sessions become invisible tax.

LoreConvo's session linking and skill-history tracking turn handoffs into a continuous narrative. When a session ends, the auto-save hook records a concise summary, the tools called, the decisions made, and any open questions it detected -- all on a heuristic basis, without requiring any manual action. The next agent that picks up the work receives that context through the auto-load hook, which injects the most relevant prior sessions at the start of a new interaction.

Because each session is tagged by project and linked to related sessions, the system can surface a chain of work that spans multiple agents. A data pipeline that started with a schema design can be followed by a performance-tuning session, then a deployment checklist -- and all of it appears as an ordered timeline. The related-session discovery feature (Pro tier) enriches that chain by finding sessions that share keywords or similar embeddings, so loosely related work surfaces when you need it.

This coordination does not rely on a central cloud service. All links, tags, and histories live in a local SQLite file you own. Managed agent sessions are excluded from auto-load and search by default, preventing accidental contamination while still letting you opt in when those sessions become relevant.

Cross-Surface Persistence

Losing context when switching tools is one of the most persistent frustrations in day-to-day AI work. LoreConvo addresses this with a single portable database that every supported surface reads and writes without manual configuration. Whether you are working in Claude Code, Claude chat, Cursor IDE, the OpenAI Codex desktop app, or Hermes Agent, the same session file is available, and the same MCP tools work across all of them.

Full-text search powered by SQLite's FTS5 engine lets you locate sessions by keyword. When you start a new session, the auto-load hook pulls in the most relevant prior context automatically -- no copy-pasting, no re-typing decisions you already made. The session export and import tools make backup and migration trivial, and exported JSON preserves session identifiers so re-imported sessions remain idempotent.

For teams that need to share knowledge without standing up a server, the Pro tier adds local-first async session sharing. You export selected sessions to JSON; teammates import them with the same tool. The workflow stays entirely offline and under your control. A usage-stats dashboard shows session counts by surface, project, and tag, along with storage size and token estimates.

True Data Portability

Data ownership is where a lot of memory tooling falls short. When your session history lives in a cloud service you do not control, you are one API change away from losing access to work that belongs to you.

LoreConvo takes the opposite approach. The entire memory layer lives in a single SQLite file on your machine. You can move it to any other device, back it up like any other file, and open it with any SQLite client. There is no proprietary format, no hidden sync, and no vendor dependency. If you move to a different editor or a different AI assistant, you drop a .mcp.json configuration file in the new environment and the memory file follows.

Session export in JSON and JSONL formats makes it straightforward to ingest your history into other analysis pipelines or archival systems. If you need retention policies, the session-expiry tool sets a TTL on any session. For richer retrieval, the Pro tier adds a hybrid search index that combines vector embeddings with full-text scoring and a recency decay reranker -- handling queries like "how did we handle the schema migration last month?" even when the exact phrasing does not appear in any saved session.

Why It Matters

When you finish a sprint, you can look back at a searchable history that captures which decisions were made and why. When a teammate joins, they can import the same SQLite file and gain contextual awareness that would otherwise take weeks to rebuild. And because the data never leaves your control, you can meet internal data policies without negotiating with a third-party cloud provider.

The full LoreConvo capability list is at Labyrinth Analytics Tools. Questions about integration are welcome at Labyrinth Analytics Contact.

For a detailed look at how LoreConvo compares to other memory approaches, see Claude's memory primitive vs LoreConvo vs Claude Mem vs Mem0. And if you are using multiple AI coding tools, the guide to keeping them all in sync covers how LoreConvo fits into a multi-tool workflow.

Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

Why your AI memory should not be Anthropic's job

Debbie Shapiro — Thu, 27 Aug 2026 04:30:42 +0000

When you build an AI system that remembers past interactions, the storage and retrieval of that memory feels like a natural extension of the model itself. The reality is more complicated. The platform you run on often decides how that memory is kept, for how long, and whether you can move it elsewhere. If the platform decides to change its policy, your entire application can lose its history overnight. That risk is rarely discussed in marketing decks, but it shows up in production logs, support tickets, and costly re-architectures.

The hidden cost of platform-bound memory

Most AI platforms treat memory as a feature of the surrounding product rather than a service offered by the platform. In the second quarter of 2026, the leading providers did not ship any platform-level memory APIs. The result is that developers must build their own persistence layer on top of generic storage services, or rely on the vendor's proprietary solution. Both approaches have trade-offs.

When you store conversation history in a vendor-specific database, the data format is often tied to that vendor's SDK. If the vendor later deprecates the SDK, you must rewrite the extraction logic, migrate the data, and test every downstream component. The effort is rarely accounted for in the original project plan, yet it can consume weeks of engineering time.

Rolling your own storage with generic cloud buckets or relational databases gives you control, but it also means you are responsible for encryption, access control, and scaling. The platform does not help you with schema evolution, so each new version of your AI model may require a schema change. Without a clear separation between the platform and the memory layer, you end up with a tangled codebase that is hard to audit and hard to move.

These hidden costs are not just technical; they affect budgeting and compliance. A data-privacy audit will ask where the conversation logs live, how long they are retained, and whether you can export them in a standard format. If the logs are locked inside a proprietary service, answering those questions becomes a negotiation with the platform provider rather than a straightforward engineering task.

Why independence matters for long-term AI projects

Independence from a specific platform's memory implementation brings three practical advantages that compound over time.

There is no deprecation risk. When a platform decides to retire a feature, you are not forced to rewrite large portions of your code. Your memory layer remains stable because it is built on open standards that you control. This is not a hypothetical concern -- it is the default pattern in every technology generation I have worked through, from mainframe middleware to cloud-managed services. Platforms consolidate; proprietary APIs get deprecated; the teams that built on open formats keep shipping.

Data portability becomes a reality. Because the memory is stored in a format you define, you can export it to any downstream system -- whether that is a data warehouse, a compliance archive, or a new AI service you adopt later. The export process is a matter of running a script, not filing a support ticket with a vendor whose support queue is measured in days.

You also avoid lock-in. When the memory lives in a vendor's managed service, every new feature you add to your AI product must be compatible with that service's limits. By keeping memory independent, you can experiment with different model providers, switch to a self-hosted solution, or adopt a hybrid approach without rewriting the storage code. That flexibility is worth protecting early, before the cost of changing course rises.

In our consulting work, we have seen teams that built memory on top of a platform's proprietary store lose months of development time when the provider announced a change to its API. Teams that used a portable, well-documented storage format were able to migrate with a single data-copy operation and continue delivering value to their users. We covered the underlying principle in detail in Why your AI memory should not live on someone else's server -- the short version is that portability is a design decision, not a feature you add later.

What Q2 2026 is telling us

The absence of platform-level memory announcements from the leading AI providers this quarter is not a coincidence. It reflects a deliberate architectural boundary: model inference is a platform problem, but session memory, knowledge retention, and context persistence are product problems. The platform gives you a powerful model; what you do with its outputs -- including how you store and retrieve them across sessions -- is your responsibility.

This boundary matters for how you design your stack. If you have been waiting for the platform to solve memory for you, Q2 2026 is evidence that the wait is indefinite. The teams making progress are the ones who treated memory as a core engineering concern rather than a deferred feature request.

The good news is that the tooling for building a robust, portable memory layer is mature. SQLite is widely supported, human-readable, and easy to back up. JSON Lines is a straightforward format for streaming conversation logs. Standard relational schemas handle schema evolution well with migrations. None of this requires a managed service, and all of it travels with your codebase.

Building a memory strategy that lasts

A memory architecture that works long-term starts with a few deliberate choices, all of which connect back to the same principle that drives consent-driven AI architecture: the data you generate should serve you, not the platform that processed it. Keep the schema in plain text alongside your code so it can be versioned and audited. Automate the export and import processes early -- do not wait until a migration is forced. Test the memory layer the same way you test any other pipeline component: with schema migrations, data corruption simulations, and access-control changes.

When the memory lives in a format you define and tools you control, it does not matter which model provider you use next year. Your historical context travels with you.

At Labyrinth Analytics Consulting, this is the kind of architectural work we do with data engineering teams who are serious about building AI systems that hold up over time -- not just for the next sprint, but for the next generation of models. If your team is navigating these decisions, reach out and we can talk through what a portable, auditable memory layer looks like for your specific stack.

Get posts like this delivered weekly: subscribe to Dispatches from the Labyrinth.

LoreDocs: a local knowledge vault

Debbie Shapiro — Fri, 21 Aug 2026 22:41:57 +0000

When you spend hours building a model, you want the insights you capture to stay with you long after the notebook closes. A conversation with an AI assistant can surface a useful snippet, but when the session ends that context disappears. For data engineers and AI practitioners who move between experiments, code reviews, and production pipelines, that fleeting memory creates hidden rework. LoreDocs was built to give that knowledge a permanent home, so the effort you invest in prompting and discovery never gets lost.

Session memory is a great start, but it is not a knowledge base

AI chat tools excel at keeping a short-term thread alive. They can remember the last few hundred tokens, let you ask follow-up questions, and even summarize a recent discussion. That works well for a single debugging session, but it falls short when you need to reference a design decision made weeks ago, trace the evolution of a data pipeline, or share a piece of documentation with a teammate who joins the project later.

The problem is twofold. The memory lives in the runtime of the chat server. When the process restarts, the context is gone. The memory is also tied to a single conversation, not to the broader set of artifacts that make up an AI workflow -- code files, experiment logs, schema definitions, and external notes. When you have to re-enter that information, you waste time and risk inconsistency.

A durable store that can be queried, versioned, and linked to the files you already own solves those gaps. It lets you treat the output of every chat as a primary artifact, just like a Git commit or a data table. That is the premise behind LoreDocs: a local, portable vault that lives alongside your code and gives you the same level of control you expect from a database.

LoreConvo handles session memory -- it saves and recalls the thread of a conversation automatically. LoreDocs is the complementary layer for everything that needs to survive longer than a session: schemas, experiment logs, model notes, and the design decisions that shape a project over months. They are different retrieval problems, and we built separate tools for them rather than trying to stretch one into the other. For a deeper look at how the two products work together, see LoreConvo and LoreDocs on the Anthropic Marketplace and the technical case for a dedicated vault store.

A vault that lives where your projects live

LoreDocs stores everything in a single SQLite file that you own. Because the file sits on your own filesystem, you retain full control over backups, encryption, and sharing. There is no hidden cloud service that could become a single point of failure, and you can move the file to a new machine simply by copying it.

The vault model is built around named vaults. You can create separate vaults for different teams, projects, or domains, and tag them for easy discovery. The workspace-scoped auto-vault feature mirrors the way many data engineering tools bind configuration to a directory: calling vault_open_workspace(path) either opens an existing vault bound to that path or creates a new one. The call is idempotent, so onboarding a new repository is as simple as opening the folder -- the vault appears automatically without extra configuration steps.

Free users start with three vaults, which covers most personal experiments. The Pro tier removes that limit and unlocks semantic search and auto-discovered document relationships when a project's knowledge base grows beyond what keyword search can navigate efficiently.

Turning raw files into searchable knowledge

A knowledge vault earns its keep when you can find what you need quickly. LoreDocs provides two complementary search mechanisms. The built-in FTS5 full-text search lets you locate documents by keyword across all vaults, using the same indexing technology that powers many modern databases. For data engineers who already rely on SQLite, this feels familiar and performant without any additional infrastructure.

Pro users also get a hybrid semantic search built on LanceDB. The system creates embeddings for each paragraph, combines them with BM25 full-text scores, and ranks results with reciprocal rank fusion. Documents are split at paragraph boundaries, keeping each chunk under 256 tokens to preserve context while staying within model limits. You enable semantic mode with a single flag on vault_search, and the index can be rebuilt on demand if you add a large batch of documents.

Importing existing knowledge is straightforward. If you already maintain an Obsidian vault, point vault_import_dir at the root folder and LoreDocs will walk the directory tree, read markdown files, and extract YAML frontmatter tags automatically. For ad-hoc files, vault_add_doc accepts a path to a text file, making it easy to add logs, experiment notes, or code snippets without leaving the terminal. Because every document is versioned, you can always roll back to a previous state -- useful when you need to understand why a model was tuned a certain way or trace a schema change across several iterations.

Linking chat, code, and data without friction

LoreDocs integrates directly with the tools you already use through a suite of MCP (Model Context Protocol) tools that expose vault operations as native actions. Whether you are working in Claude Code, Cowork, OpenAI Codex, Cursor, or Hermes Agent, you can add a .mcp.json file to your project and the vault becomes available to the AI without any additional setup.

When you run a chat session with LoreConvo, the assistant can pull relevant passages from the vault in real time. The vault_prime call injects the entire context of a chosen vault into a single request, allowing the model to answer questions that depend on multiple documents. This eliminates the need to copy-paste snippets manually and reduces the chance of misquoting a source.

For environments that do not read .mcp.json, LoreDocs offers a Python fallback script. Any agent that can execute Python can use it to retrieve documents, making the vault accessible even in custom pipelines or batch jobs. Because the vault is stored locally, a data pipeline can also read the latest version of a schema definition directly from the vault, ensuring that transformation logic always matches the documented contract.

Bringing it all together

LoreDocs was built to fill the gap between fleeting AI chat memory and a robust, searchable knowledge repository. Local SQLite storage, multi-vault organization, full-text and semantic search, versioning, and MCP integration combine to turn every conversation, note, and code snippet into a durable artifact you own and control.

Paired with LoreConvo, you get a workflow where the assistant can retrieve and reference the exact documentation that informed a decision, and you can later audit that decision through the version history. The result is less time re-entering information, fewer inconsistencies across experiments, and a clearer path from prototype to production.

Explore the full LoreDocs feature set on the Labyrinth Analytics tools page, or reach out if you want to talk through how a local knowledge vault fits into your data engineering pipeline.

Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

MCP Servers: AI Meets Your Data Stack

Debbie Shapiro — Wed, 19 Aug 2026 15:27:24 +0000

Data engineers have spent decades solving the problem of moving data to consumers reliably: pipelines, contracts, schemas, access controls. AI agents introduced a new class of consumer -- one that calls functions instead of running queries, reads context instead of pulling rows, and needs answers in natural language rather than JSON payloads. The Model Context Protocol (MCP) is the emerging standard that makes this interface explicit.

This post explains what an MCP server actually is, how it fits into a production data stack, and what a data engineer needs to know to build one. It is not about ML feature stores or model-serving infrastructure -- that is a different and well-covered topic. MCP is about something more foundational: how an AI agent discovers and calls tools exposed by a server, and how you as a data engineer define that interface.

What MCP Is (and What It Is Not)

The Model Context Protocol is an open standard, developed by Anthropic and adopted across the AI tooling ecosystem, that defines how AI agents (called MCP clients) connect to external tools and data sources (called MCP servers). An MCP server is not a model-serving layer. It does not run inference, manage feature vectors, or sit between your warehouse and a training pipeline. It is a server that exposes tools -- typed functions an AI agent can discover and call -- and optionally resources (context data the agent can read but not modify) and prompts (reusable templates for common operations).

Think of it as an API specification that AI agents know how to read natively. When an MCP client like Claude Code or Codex opens a project, it reads a .mcp.json registration file at the project root, discovers the MCP servers listed there, and makes their tools available as native capabilities. A query_warehouse tool on your MCP server becomes something Claude can call directly -- no system-prompt engineering, no parsing hacks, no custom plugin code on the client side.

The contract between client and server is defined in the server's tool schema: each tool has a name, a description, and a typed input schema (JSON Schema). The client sends a structured tool call with arguments matching that schema; the server validates them, executes the operation, and returns a typed result. That exchange is the whole protocol at the application layer -- the rest (transport, versioning, capability negotiation) is handled by the SDK.

Why This Matters to a Data Engineer

Most discussions of MCP are written from the model side -- how AI products add support for MCP servers, what clients are available, which platforms have adopted the standard. That framing treats the data engineer as a passive party whose systems the AI will eventually connect to, when it gets around to it.

The more useful frame: an MCP server is infrastructure you build to expose your data stack to AI agents, with the same level of control and observability you apply to any other interface. You define which operations are available. You write the schema. You implement the validation, the access controls, and the error handling. The AI agent calls your interface -- not the other way around.

This distinction matters because it means the data engineering problems you already know how to solve apply directly. Schema contracts, versioning, access control, audit logging, caching -- none of these go away when the consumer is an AI. They become more important, because a poorly-specified interface surfaces as AI hallucination or unexpected behavior, which is harder to debug than a failed API call.

What a Data Stack MCP Server Looks Like

The concrete shape of an MCP server for data engineering work typically includes a small number of tools, each corresponding to an operation that makes sense for an AI consumer to perform. A few examples from real usage:

A run_query tool that accepts a natural-language question or a structured query spec, translates it to SQL (or executes a pre-defined parameterized query), and returns results as structured JSON. The AI agent calls this to answer factual questions about your data without needing direct warehouse access.

A get_schema tool that returns the schema for a table or set of tables -- column names, types, descriptions. This is the context an AI agent needs to write correct SQL or reason about data structure, and it is far more reliable as an explicit tool call than embedded in the system prompt.

A list_recent_events tool that returns the last N rows from an event stream for a given entity or time range. A monitoring or debugging agent can call this to understand what happened in the system without needing to write a query from scratch.

Each of these tools has an explicit input schema that constrains what the AI can pass, a validation layer that enforces those constraints before any database operation runs, and a result structure the AI knows how to parse. Fine-grained access rules -- restricting which tables a tool can touch, which columns are exposed -- live in the server implementation, not in the AI's instructions. That is where they belong: enforced at the interface boundary, not negotiated in a prompt.

The .mcp.json Convention

The mechanics of registration are straightforward. A .mcp.json file at the project root tells any MCP-compatible client which servers to connect to and how to start them. The file is project-local and gitignored by default, so credentials and paths stay on the machine and are never committed.

{
  "mcpServers": {
    "data-stack": {
      "command": "python",
      "args": ["-m", "my_mcp_server"],
      "env": {
        "WAREHOUSE_URL": "${WAREHOUSE_URL}"
      }
    }
  }
}

When Claude Code opens this project, it reads the file, starts the server as a subprocess, discovers the tools via MCP's capability negotiation handshake, and makes them available. The same file works for Codex -- we verified this directly: the same .mcp.json that Claude Code reads at project open is the same file Codex reads, with no per-client configuration. One file, every agent.

The server itself can be written in any language that has an MCP SDK. Python and TypeScript are the most mature options. The SDK handles the transport layer (stdio or HTTP/SSE), the capability negotiation, and the tool-call dispatch loop. You implement the tool handlers.

Fitting MCP Into an Existing Stack

The practical question for most data engineers is not whether to adopt MCP -- agents in your organization are already calling APIs, asking questions about your data, and writing queries against your warehouse with varying levels of accuracy. The question is whether you have an explicit, controlled interface for that activity or an implicit one.

An MCP server makes the interface explicit. You decide which operations are exposed. You define the contract. You implement the observability -- every tool call can log its inputs, outputs, execution time, and calling agent, giving you the same audit trail you would expect from any production API. That traceability becomes important when an AI agent is involved in a data pipeline decision: you want to know which tool it called, with which arguments, and what it received back.

The fit with existing data engineering tooling is direct. An MCP server reads from whatever your agents already have access to: a Snowflake or BigQuery warehouse, a dbt-curated mart, a Redshift cluster, a set of Parquet files in S3. It does not replace those systems or the pipelines that feed them. It sits in front of them, exposing a typed interface that AI agents know how to use.

The place it changes your architecture is at the boundary: instead of AI agents querying your warehouse directly (or being given broad database credentials and hoping nothing breaks), they call your MCP server, and your server enforces the contract. That is a familiar pattern. It is what a well-designed data API has always done. MCP makes it native to the AI tooling ecosystem.

Getting Started

The lowest-friction entry point is to pick one high-value, bounded operation -- a query your team runs frequently, a schema inspection that agents currently do badly, a data lookup that keeps producing wrong results -- and wrap it as a single MCP tool. Get that working end-to-end: registered in .mcp.json, callable from Claude or Codex, returning structured output. Then add tools from there.

The Anthropic SDK documentation covers the server implementation and tool schema format. LoreConvo and LoreDocs, the session-memory and knowledge-vault tools we built at Labyrinth Analytics, are both MCP servers -- you can inspect their tool registrations as examples of what production schemas look like in practice.

If you are working through how MCP fits your specific stack, reach out -- I am happy to think through the interface design with you. And if you want to see what MCP-native tooling looks like from the consumer side, start at /tools.

Get posts like this delivered weekly: subscribe to Dispatches from the Labyrinth.

LoreDocs: Durable AI Knowledge Vaults

Debbie Shapiro — Tue, 18 Aug 2026 22:20:26 +0000

When a data pipeline forgets its own lessons, the cost shows up in every run.

You have spent weeks building a feature extractor, fine-tuning a transformer, and wiring a scheduler that moves terabytes of logs from a bucket to a lake. The next sprint you discover that the same edge case you solved last quarter has resurfaced, and the sole record of the decision lives in a chat transcript buried under weeks of unrelated conversation. You spend hours digging, re-creating the context, and testing again. The loss is not just a nuisance; it is a hidden expense that eats into the margin you are trying to protect.

Session memory in LLM assistants is useful for a single interaction, but it does not survive beyond the process that created it. Structured knowledge that lives in a durable store can be indexed, versioned, and queried across projects. The gap between what the model remembers right now and what the team can retrieve tomorrow is where many AI-native workflows stumble. LoreDocs was built to bridge that gap.

Session memory is fleeting, vaults are persistent

LLM assistants keep a short-term context window that is refreshed with each new request. That window is powerful for generating code or answering a question that references the immediately preceding turn, but it does not survive a restart, a new branch, or a different user. When the conversation ends, the internal state is discarded. The result is a series of isolated islands of knowledge that cannot be linked together.

A durable knowledge vault stores each document as a discrete, versioned entity. The vault lives in a single SQLite file you own, can copy, back up, or delete at will. Because the data never leaves your machine, you retain full control over privacy and compliance -- a requirement that many teams cannot ignore. LoreDocs treats every note, design doc, or experiment log as a fully-fledged citizen, assigning it to a named vault that can be tagged and searched later.

When you need to recall a past experiment, you do not have to replay an entire chat history. You query the vault directly and get the exact version of the document you saved, complete with its metadata. This separation of concerns -- session memory for immediate reasoning, vault storage for long-term retrieval -- lets you design pipelines that are both responsive and auditable.

A vault architecture that matches the data engineer's workflow

LoreDocs adopts a multi-vault model that mirrors the way you already organize code and data. Each vault is identified by a name and can carry arbitrary tags, allowing you to group related artifacts (feature-extraction notes, model-evaluation results, pipeline-ops runbooks) without creating separate directories on disk. The workspace-scoped auto-vault function, vault_open_workspace(path), automatically creates or reuses a vault bound to the directory you are working in. Call it once at the start of a project and every subsequent call returns the same vault, eliminating manual configuration.

All vault data is stored in a single local SQLite file. That design gives you portability, zero-dependency indexing, and version control in a single file. Moving it to a new laptop, a CI runner, or a secure archive brings the entire knowledge base intact. SQLite's built-in FTS5 engine powers full-text search across every vault without a separate search service. Every document write creates a new version, so you can roll back to a prior state, compare changes, or restore a deleted note with a single command.

The free tier lets you create up to three vaults, which is enough for a personal project or proof-of-concept. When you need unlimited vaults, the Pro tier ($9/month) removes that limit and unlocks advanced retrieval capabilities.

From keyword matching to semantic relevance

Full-text search works well when you know the exact phrase you typed into a document. In practice, engineers often remember the concept but not the wording. LoreDocs addresses this with a hybrid search stack available in the Pro tier.

The hybrid engine pairs BM25 full-text scoring with BGE-small-en dense vector embeddings, then combines the two score lists using reciprocal rank fusion -- a straightforward algorithm that merges keyword relevance and semantic meaning into a single ranking. When you call vault_search with semantic=true, each document is split into paragraph-sized chunks of no more than 256 tokens, and both the BM25 tokens and the embeddings are indexed. The query is processed the same way, so results surface the most conceptually relevant passages even when the exact keywords differ.

Because the embeddings are stored locally in a LanceDB index, search stays fast without an external API. The entire pipeline -- ingest, chunk, embed, index -- runs on the same machine that holds the SQLite file.

The Pro tier also adds auto-discovered document relationships. As you add new notes, LoreDocs analyzes the text for references to existing vault entries and creates lightweight links. Over time, a graph of related experiments, model cards, and data schemas emerges without manual tagging. That graph can be traversed programmatically, enabling downstream tools to surface the most relevant context for a new training run.

Integration that feels native, not forced

A common pain point for AI-native tooling is the need to configure each client separately. LoreDocs sidesteps this by exposing a native MCP server that is recognized automatically by several popular development environments. Claude Code (all surfaces), OpenAI Codex desktop app (verified May 2026), Cursor IDE (verified June 2026), and Hermes Agent from NousResearch (verified June 2026) all discover the server from a project-local .mcp.json (or .cursor/mcp.json for Cursor) without any additional setup. Once the file is present, the environment lists LoreDocs among its available tools.

For environments that do not read .mcp.json, LoreDocs ships a small Python fallback script, query_loredocs.py. Any agent capable of running Python can point it at the SQLite file and issue the same vault operations. This pragmatic path ensures that a scheduled job or a CI step can retrieve knowledge without a full MCP registration.

Importing existing knowledge bases is also straightforward. The vault_import_dir command walks an Obsidian vault, reads every markdown file, extracts YAML frontmatter tags, and creates matching documents in the target LoreDocs vault. Nested folders are preserved, and the operation is idempotent -- running it again will not duplicate entries. For engineers who already maintain rich markdown notes, onboarding is a single command.

All of these integration points are designed to fit naturally into your existing workflow. You can spin up a new vault as part of a repository setup, import the project's design docs, and then let downstream scripts query the vault for recommendations recorded during a previous experiment. The result is a feedback loop that reduces duplication of effort and keeps institutional knowledge alive.

When you need more than a chat log

LoreConvo, the conversational companion in the Lore family, excels at keeping a running dialogue with an LLM. It can summarize a session, capture decisions, and store the result in a LoreDocs vault. However, LoreConvo's memory is bound to the active chat; it cannot answer a query that was never part of that conversation, nor can it surface relationships that span multiple sessions.

LoreDocs fills that gap by providing a queryable, versioned store that lives beyond any single chat. When you need to retrieve the exact configuration of a data pipeline built six months ago, you ask LoreDocs directly. When you need to discover which experiments referenced a particular feature flag, you run a semantic search across all vaults.

In practice, the two tools complement each other. During a design meeting, LoreConvo captures decisions in real time; at session end, you can link the saved session to a LoreDocs vault entry using the cross-product session-to-doc linking feature, so the decision is findable by future keyword or semantic search. Later, that search surfaces the design note that mentioned a specific data-drift detection method. You retrieve the exact version, see the linked experiment results, and feed those parameters into a new training run. When the run completes, you add a result document and the auto-discovery engine links it back to the original design note, closing the loop.

By separating the conversational capture layer from the durable retrieval layer, you avoid the memory-overload problem that occurs when a single system tries to do both. LoreDocs gives you the stability of a database while LoreConvo gives you the fluidity of a chat.

Start building a durable knowledge layer

The conversation model solved the problem of short-term context, but the real value of AI in data engineering comes from accumulating knowledge over weeks, months, and years. By giving that knowledge a dedicated store, LoreDocs lets you treat every experiment, schema change, and model insight as a reusable asset.

LoreDocs is available now from the Anthropic marketplace and PyPI. See the Labyrinth tools page for install steps and the rest of the Lore suite.

If you are new to the Lore suite, start with why your Claude sessions start from zero for the session memory context, and then see how LoreDocs vaults are designed for AI projects for the architecture that makes durable knowledge retrieval work.

Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

AI Memory for Claude: An Honest 4-Way Comparison

Debbie Shapiro — Mon, 17 Aug 2026 00:58:57 +0000

When you spend a day stitching together prompts, pulling data from a pipeline, and then trying to remember what decision you made in the last session, the friction shows up as wasted time. The problem is not the model itself -- it is the memory layer that sits between you and the model. Over the past year four approaches to Claude memory have emerged. This post compares them directly: the Claude Memory Primitive, claude-mem, mem0, and LoreConvo. I have written individual deep-dives on LoreConvo vs mem0 and LoreConvo vs claude-mem; this post consolidates the full four-way picture in one place. The goal is a clear picture of the trade-offs in architecture, cost, privacy, and workflow so you can pick the tool that matches your situation. I have tried all four; I built LoreConvo, so I will tell you exactly where the others win.

Architecture and data ownership

The most obvious difference is where the memory lives.

The Claude Memory Primitive stores session snippets in a cloud-hosted graph that Anthropic manages. You send a request, Claude returns a short summary, and the service keeps a record tied to your API key. This model is the simplest to start with, but the data never leaves Anthropic's environment. For teams that must comply with strict data-handling policies, that retention is a deal-breaker.

claude-mem adds a thin layer that converts the graph into a JSON file on the client side. The file is written to a local directory, but the tool periodically syncs it back to a remote store for backup. The result is a hybrid: you get a local copy you can inspect, but you also rely on a cloud service for durability. For a lot of solo developers who just want Claude to remember what they figured out last Tuesday, that automatic behavior is exactly right.

mem0 takes a different route. It builds a vector store on top of a local database using an embedding model to index each interaction. The library exposes memory management operations that let you add, query, and delete memories programmatically. Because the index lives on your machine, you have full control -- but you also manage the embedding model yourself, which adds both complexity and ongoing cost.

LoreConvo uses a local-first design that combines portability with cross-surface reach. All session data lands in a single SQLite file you own. The file can be moved, backed up, or versioned with any tool you already use -- there is no hidden cloud component. At the same time, the MCP server exposes the memory layer to Claude Code, OpenAI Codex, Cursor, and Hermes Agent without any per-client configuration. You drop a .mcp.json file in the project root and the server discovers it automatically. Because the storage is local, privacy is guaranteed: only you, or teammates you explicitly share with, can read the file.

Pricing and scalability

Cost is another axis where the four diverge.

The Claude Memory Primitive is bundled with Claude API usage fees. There is no separate memory charge, but every call that reads from or writes to the graph incurs API cost. For a solo developer on a laptop this can be inexpensive; for a team running hundreds of sessions per day the extra calls add up quickly.

claude-mem is free to install. The optional remote backup service is priced per gigabyte stored. A few megabytes of session data costs almost nothing; once you archive weeks of history the price scales linearly with usage.

mem0 itself is free, but you need to provision an embedding model. Using a hosted embedding API typically costs a few cents per thousand tokens, and running a local model draws on GPU resources. For data engineers who already have GPU capacity the marginal cost is low, but for smaller teams the external API fees become a hidden expense that compounds over months.

LoreConvo offers a predictable two-tier structure. The free tier gives you up to fifty sessions, which covers most experimentation and short-term projects. Pro costs eight dollars per month and removes the session limit while adding semantic search, related-session discovery, and team memory sharing. All of those features run against the same local SQLite file, so there are no per-call fees layered on top. For a solo developer, Pro costs less than the extra API calls that the cloud-native options typically generate, and for a small team the flat monthly price makes budgeting straightforward.

Privacy and control

When you hand data to a cloud service you implicitly trust the provider's security practices. The Claude Memory Primitive encrypts data in transit and at rest, but Anthropic retains a copy. If you are working with proprietary code, regulated datasets, or internal architecture decisions, that retention introduces compliance risk.

claude-mem's hybrid approach gives you a local copy you can audit, but the remote backup still stores the data in a third-party bucket. You can disable the sync, but then you lose the automatic durability feature -- and you have to remember to disable it consciously.

mem0 puts the entire responsibility on you. The index files are local and inspectable with standard tools. However, the library does not enforce access controls, so any process with file system access can read the memories. You must set up your own OS-level permissions.

LoreConvo's design is built around ownership. The SQLite file lives in a directory you choose, and the memory inspection UI lets you list, filter, and delete sessions with a single command. The auto-save hook runs at the end of every session without any user action. It extracts a heuristic summary that captures decisions, tech-stack facts, and open questions when the session contains enough signal -- this is best-effort, not a guarantee on every save. Because the data never leaves your machine, you retain full control. Pro users can export selected sessions to JSON and let a teammate import them, all without a central server.

Which tool fits your situation

If you need zero setup and are comfortable with Anthropic managing your memory in the cloud, the Memory Primitive is the fastest path. It works well for quick prototypes where privacy is not a concern and you are not already paying close attention to API usage.

claude-mem earns its 45,000 GitHub stars. If you want a local copy with automatic backup and you are comfortable with the hybrid cloud model, it is the most polished community option. The seamless capture -- you keep working and your conversations get remembered -- is genuinely useful for solo developers who do not want to think about the memory layer.

mem0 wins for teams that need deep vector search and are willing to manage the embedding infrastructure. If you are building pipelines that benefit from semantic similarity lookups across thousands of stored facts, and you have the GPU or the API budget to support that, mem0 gives you more retrieval depth than the other options.

LoreConvo fits the practitioner who wants a portable, ownable file with cross-surface reach and predictable costs. The FTS5 full-text search handles most recall needs without an embedding layer. Session linking, project tagging, and the auto-load hook create context chains across runs without manual bookkeeping. If you work across multiple surfaces -- Claude Code in the morning, Cursor in the afternoon, a headless pipeline at night -- LoreConvo carries the same memory layer to all of them. The Python fallback script save_to_loreconvo.py lets any script read or write memories without registering an MCP tool, keeping the integration lightweight for automation.

For data engineers running multiple pipelines, the combination of skill history tracking, project tagging, and session linking turns the memory store into a lightweight audit trail: what decisions drove each pipeline design, which schemas changed and why, and where to pick up a refactor that stalled two weeks ago.

Bringing it together

The honest answer is that none of these four tools is wrong for every use case. The Claude Memory Primitive is the zero-friction starting point. claude-mem is the community-built standard that most developers reach for first. mem0 is the right choice when you need semantic retrieval at scale and can manage the embedding overhead. LoreConvo is the option when you want a single file you own, cross-surface reach you do not have to configure per client, and a flat monthly cost that does not scale with query volume.

You can see the full LoreConvo tool set and install instructions at the Labyrinth tools page. If you are comparing these options for a specific pipeline or agent architecture, reach out -- I am happy to walk through the trade-offs for your stack.

PS: Interested in a Lifetime Deal on LoreConvo Pro? Join the waitlist.

Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

Agentic AI Help: Scopes, Sprints, Red Flags

Debbie Shapiro — Sun, 16 Aug 2026 00:25:41 +0000

When a data team decides to bring an external AI specialist into a project, the excitement is often matched by a lingering fear: will the engagement drain the budget without delivering the promised value? The market is full of offers that start with a high-level promise and end with a six-figure invoice. For data engineers and AI practitioners who need predictable outcomes, the key is understanding the three common engagement formats -- audit, prototype sprint, and embedded build -- along with the realistic time and cost commitments each entails. Knowing the warning signs that indicate a vendor may be heading toward scope creep can save both money and sanity.

Understanding Fixed-Scope Consulting

A fixed-scope consulting engagement is built around a clearly defined problem statement, a concrete set of deliverables, and a mutually agreed timeline. The consulting firm outlines exactly what will be produced, how success will be measured, and what resources the client must provide. Because the scope is locked before work begins, the client can budget with confidence and avoid surprise invoices.

In practice, a fixed-scope audit typically lasts between two and four weeks. The consulting team spends the first few days aligning on data access, security constraints, and the business question. The remainder of the period is devoted to a systematic review of the existing pipeline, model architecture, and operational monitoring. The final deliverable is a concise report that highlights gaps, quantifies risk, and recommends next steps. For a mid-size organization, the cost of a thorough audit usually falls in the range of $30,000 to $50,000, depending on data volume and regulatory complexity.

The advantage of an audit is that it provides a factual baseline without committing to any code changes. Data engineers appreciate the focus on concrete artifacts -- schema diagrams, data lineage graphs, and model performance logs -- because those items can be directly incorporated into existing documentation. AI practitioners benefit from the clear identification of bottlenecks, such as feature drift or inefficient batch processing, which can be addressed in a later sprint.

When a Prototype Sprint Makes Sense

A prototype sprint is a short, intensive development cycle that builds a minimal viable solution to a specific problem. The sprint is bounded by a fixed number of weeks -- often three to six -- and a fixed budget, typically ranging from $50,000 to $80,000. The goal is not to deliver a production-ready system but to prove that a particular approach can meet the performance targets set by the client.

During a prototype sprint, the consulting team works side-by-side with the client's engineers. The collaboration model is transparent: daily stand-ups, shared code repositories, and a joint definition of "done." By the end of the sprint, the client receives a working prototype, a set of performance metrics, and a roadmap for scaling the solution. The prototype is deliberately kept lightweight, using modular components that can be swapped in or out as the project evolves.

For data engineers, the sprint offers a chance to see how new tooling integrates with existing ETL jobs, data warehouses, and orchestration frameworks. For AI practitioners, it provides a sandbox to experiment with model architectures, tuning strategies, and inference pipelines. Because the scope is fixed, any work that falls outside the agreed objectives is explicitly billed as a separate change order, protecting the client from hidden costs.

Embedded Build: A Long-Term Partnership

When an organization anticipates a multi-phase transformation -- such as moving from batch inference to real-time serving, or building a data-driven product line -- a longer-term embedded build may be the right choice. In this model, a consulting team becomes an extension of the client's own staff for a period that can range from three months to a year. The engagement is still scoped, but the scope is expressed as a series of milestones rather than a single deliverable.

The embedded approach balances predictability with flexibility. The consulting firm commits to delivering a set of milestones -- implement a feature store, establish CI/CD for model deployment, set up automated drift detection -- each with its own acceptance criteria. The client pays a monthly retainer, often between $20,000 and $35,000, plus a modest success fee tied to milestone completion. Because the team works within the client's environment, data engineers can directly observe how new pipelines are built, and AI practitioners can iterate on models using live production data.

A key benefit of the embedded model is knowledge transfer. As the consulting team builds components, they document decisions, write unit tests, and conduct walkthroughs with the client's engineers. By the end of the engagement, the client's staff is equipped to maintain and extend the solution without ongoing external support. The cost structure -- monthly retainer plus milestone bonuses -- makes budgeting straightforward while still allowing the project to adapt to new insights that emerge during development.

Red Flags That Signal Budget Trouble

Even with a well-defined scope, some vendors slip into practices that inflate costs and erode trust. The signals below often precede budget overruns and should prompt a deeper conversation before signing a contract.

Vague deliverables are the most common tell. If the proposal lists outcomes like "enhance AI capabilities" without specifying measurable metrics, the scope is open to interpretation. A solid contract will define success in terms of quantifiable targets -- reduce model latency from 500ms to 200ms, or increase feature coverage by 30 percent. Without those numbers, you have no basis for a milestone sign-off and no leverage if the delivery falls short.

Open-ended timelines have a similar effect. Promises like "we will deliver in a few weeks" without a concrete schedule leave room for extensions that compound monthly. Fixed-scope work should include a detailed timeline with milestones, review dates, and clear hand-off points. If the vendor cannot commit to dates, they cannot commit to budget either.

Hourly billing for core work is another indicator worth scrutinizing. While some discovery activities are naturally billed hourly, the core development or audit phases should be priced on a fixed-fee basis. Hourly rates that apply to the entire engagement make it difficult to predict total spend and give the vendor no financial incentive to move quickly.

Watch for a pattern of frequent change-order requests early in the project. One or two scope adjustments are normal when new information surfaces; four or five in the first month usually means the original proposal was deliberately under-scoped to win the bid. Each change order should be justified with a clear impact analysis and a mutually agreed cost -- and if you see the pattern repeating, that is a conversation worth having directly.

Two contract terms that are easy to overlook: data ownership and exit criteria. If the vendor retains copies of data or model artifacts after the engagement ends, you may face compliance or security issues regardless of what you were promised verbally. The contract should state that all data, code, and documentation remain your property and can be transferred at any time. Equally important is a clear definition of what "done" looks like for each milestone. Projects that lack defined acceptance criteria can linger indefinitely, consuming retainer months without producing a clean handoff.

Finally, ask for a breakdown of any third-party services bundled into the price. Some firms include managed feature stores or monitoring platforms without disclosing the separate licensing costs. Getting that breakdown up front lets you evaluate the true total cost of ownership, not just the consulting fee.

Choosing a Partner Who Aligns With Your Goals

The three engagement formats described above -- audit, prototype sprint, and embedded build -- are most effective when the consulting partner structures them around your existing environment rather than a generic playbook. That means working in the same cloud platforms, version-control systems, and orchestration frameworks your engineers already use. It means aligning on a definition of done before the first line of code is written. And it means building in enough knowledge transfer that your team is not dependent on outside expertise to maintain the system six months after delivery.

If you have been burned by vague proposals or hidden fees in the past, starting with a scoped audit is a low-risk way to move forward. The audit surfaces the most pressing technical debt, quantifies the effort required for remediation, and produces a roadmap that aligns with your budget constraints. From there, you can decide whether a prototype sprint or an embedded build is the logical next step -- with evidence, not a sales pitch.

If you are evaluating whether an outside engagement is the right move at all, the post How to Evaluate an Agentic AI Consultant (Before You Waste Six Figures) covers the selection process in detail. For information on what a LangGraph implementation engagement actually looks like in practice, see What a LangGraph Implementation Engagement Actually Looks Like.

Ready to talk through the right format for your situation? Visit Services to see the engagement options Labyrinth Analytics offers, or go directly to Contact to start a conversation.

Get posts like this delivered weekly: subscribe to Dispatches from the Labyrinth.

When to Use LangGraph vs. Simpler Tool-Calling

Debbie Shapiro — Fri, 14 Aug 2026 02:33:26 +0000

Single-shot tool-calling is the right default when a request is self-contained: one call, one result, move on. LangGraph is the right choice when your pipeline needs explicit state, conditional branching, or an audit trail that survives a crash. Knowing where that line sits saves you from a premature rewrite on one end and from months of fragile patchwork on the other.

I have written about building a first LangGraph pipeline and about deploying LangGraph into existing data infrastructure. This post covers the earlier question: how do you know it is time to make that move at all?

When the single-shot pattern starts to strain

A single-shot tool call works cleanly when the input is predictable and the output is all the downstream code needs. The pattern starts to cost you something under three conditions.

The first is variable input size or schema. A model that summarizes a 200-row CSV will behave differently when the same endpoint receives a 20,000-row file. Once you start adding pre-processing steps -- filtering, type conversion, enrichment -- those operations hide inside the prompt or accumulate as ad-hoc Python stitched around the call. The pipeline looks like a single step but is not.

The second is decision points that affect downstream routing. Picture a workflow that pulls a list of financial transactions, flags those above a threshold, and routes flagged items to compliance review while sending the rest to a reporting dashboard. If the flagging logic lives inside the model response, you lose the ability to audit why a particular transaction was routed the way it was. There is no explicit state to inspect, and no place to attach a log entry.

The third is accumulated error handling. When a tool returns an unexpected schema, you add a conditional check. Then one for rate-limit errors. Then one for the edge case where the upstream API times out at exactly the wrong moment. The code still looks like a single call but is surrounded by a maze of special cases that only the original author fully understands. Adding a new team member becomes a risk.

What explicit state and branching give you

LangGraph's core addition is a shared state dictionary that persists across nodes. Each node reads what it needs, does one thing, and writes its result back to state. That sounds like a small change, but it resolves all three of the problems above.

Handling variable inputs becomes a node. Instead of pre-processing inside a prompt or around a call, you write a node whose sole job is to normalize the input before the next node sees it. The graph makes that step visible, testable, and replaceable without touching anything else.

Conditional routing becomes an edge. In the compliance example, a node that evaluates the transaction amount sets a flag in state; a conditional edge then sends the flow to the "review" branch or the "report" branch based on that flag. The branching logic sits in the graph definition, not inside a prompt string, which means you can read it, version it, and change it without re-prompting.

Error handling becomes a node too. You can attach a retry node to any step, centralize timeout logic in one place, and route failures to a logging node that records what went wrong. The try-except blocks stop multiplying.

Observability is the compounding benefit. Because each transition can emit a log entry with node name, input snapshot, and output snapshot, you get a run timeline without any additional instrumentation. When a compliance auditor asks which rule flagged transaction 4,217, you can show them the exact state at the flagging node.

Four signals it is time to make the move

I use four practical tests when evaluating whether a new pipeline warrants a graph from the start.

The first signal is that the tool must handle meaningfully different input shapes. If you find yourself writing shape-detection logic to guard a single call, that logic should be a node.

The second signal is that the model output determines which downstream system receives data. Any time the output of one step controls where the next step sends results, you have a branch. Encoding it as an edge is safer and more readable than encoding it as a conditional inside the prompt.

The third signal is that you have written the same retry logic twice. Once is reasonable. Twice means you have a pattern that belongs in a shared error-handling node rather than scattered across the codebase.

The fourth signal is that the pipeline will face a compliance or audit requirement. If regulators or internal reviewers will ask how data moved through the system, the explicit state and log entries that LangGraph produces are much easier to present than a reconstruction from application logs.

Any single signal is enough to warrant a graph. Multiple signals together mean a single-shot approach will cost you maintenance time within weeks.

Getting started without a full rewrite

The transition does not require throwing out what you have. A two-node graph -- one node for the tool call and one for validation -- is a reasonable starting point. It introduces the state dictionary, makes the validation step explicit, and gives you a place to add a retry node if the call fails. From there you can extend the graph one node at a time as the need arises.

The hub post on building a first LangGraph pipeline walks through the essential steps: defining state, wrapping tool calls in nodes, adding conditional edges, and attaching error-handling nodes. The observability guide covers what to log at each transition so you can debug runs without replaying the entire pipeline. For finance-focused implementation detail, the case study at /work/finance-pipeline shows how a 19-node graph reduced manual reconciliation time by more than half on a production ledger pipeline.

If you are at the point where your current tool-calling code is starting to fight back, those three posts cover the path from the first graph to a deployed, monitored pipeline.

For help designing the graph structure for your specific stack, see /services or reach out through the contact page.

PS: Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

Why Consent and Provenance Are Worth Paying For

Debbie Shapiro — Wed, 05 Aug 2026 02:36:10 +0000

The AI-assisted workflow has become a daily habit for data engineers and AI practitioners. A growing list of free memory extensions promises to capture prompts, code snippets, and model outputs across editors, notebooks, and chat windows. They are open source, easy to install, and work on many surfaces. For many solo developers, that sounds like a perfect fit.

But as the number of sessions grows, the hidden costs of a "free-forever" model start to surface. When you are building pipelines that process sensitive data, when you need to audit who saw which decision, or when a team must trace the origin of a model tweak, consent and provenance become non-negotiable. LoreConvo was built with those requirements at its core, offering a paid tier that adds the safeguards free tools often overlook.

Below we explore the practical gaps in typical free memory layers and explain how LoreConvo's design choices address them without sacrificing the convenience that made the free options attractive in the first place.

Free tools excel at capture, but they leave consent to the back seat

Most free memory extensions focus on "capture everything": they listen to every prompt, every tool call, and every piece of generated code, then write it to a local file or a cloud bucket. The result is a massive, searchable archive that feels powerful at first glance. Their strengths are real -- cross-surface reach across popular editors and chat interfaces, full-text search that works for short queries, and open licensing that lets you fork or modify the code without legal friction. Those capabilities are valuable, especially for rapid prototyping.

However, they assume that every piece of captured data is safe to store and share. In practice, a single session may contain credentials, proprietary model parameters, or a discussion about a client's data policy. When a tool automatically records everything, you are forced to scrub the archive manually or risk leaking information later.

LoreConvo's consent model takes a different stance. By default, sessions that originate from external tools -- such as managed agents from other providers -- are marked so that they are excluded from auto-load and from the default search index. This isolation prevents accidental contamination of your primary knowledge base. If you decide a particular external session is safe and useful, you can override the exclusion with a simple environment flag or per-query option. The decision is explicit, not implicit.

The Pro tier extends this approach with team memory. When you export selected sessions to JSON and share them with teammates, the merge operation respects the same consent flags. No hidden data slips into a teammate's local store without their explicit import. This level of control is difficult to achieve with a free tool that simply writes everything to a single file.

Provenance matters when you need to audit decisions

A data engineer often has to answer questions like "Which model version produced this result?" or "What was the exact configuration when we tuned the hyperparameters?" Free memory layers typically store a raw transcript without structured metadata. You can search for a keyword, but you cannot reliably trace the chain of reasoning that led to a decision.

LoreConvo embeds provenance into every saved session through several complementary mechanisms. Project tagging lets you namespace sessions so all work related to a specific pipeline lives under a clear label. Skill history tracking records which tools or libraries were invoked during a session, giving you a quick view of the technical stack used at each point in time. Session linking automatically creates context chains between related sessions, so you can follow the evolution of an idea from a brainstorming chat to a final code commit. When a session's summary is later updated, the previous version is preserved in a version history field, giving you a built-in audit trail of how understanding evolved. Anti-pattern tagging lets you mark sessions that contain known pitfalls, and retrieve them for review when similar situations arise.

When you start a new session, the auto-load hook pulls in the most relevant prior context based on project tags, linked sessions, and recent skill usage. You do not have to remember the exact file name or search term; LoreConvo surfaces the right background automatically while still giving you full visibility into why that context was chosen. The memory inspection interface, available as an MCP tool, lets you list, filter, and delete sessions with a tabular view that includes tags, project names, and timestamps. The usage stats tool reports session counts by surface and project, storage size, and token estimates -- metrics that matter when you need to demonstrate compliance with internal data-handling policies.

Verified cross-surface identity is a harder problem than it looks

Free memory tools often claim cross-surface support, but "cross-surface" usually means "we have a browser extension and a VS Code plugin." It does not mean a verified, zero-config identity that follows you across fundamentally different agent environments.

LoreConvo's cross-surface identity is verified through direct testing on Claude Code (all surfaces), OpenAI Codex desktop, Cursor IDE, and Hermes Agent. The same .mcp.json file at your project root is what all four clients read -- no per-client configuration, no separate credentials. That is a substantively different claim from "we support multiple integrations," and it matters when you are switching environments mid-project and need the context from one environment to surface cleanly in another.

The consent model and the cross-surface identity are not separate features. They are the same design: your memory layer knows which sessions came from which surface, which ones came from external tools, and which ones you have explicitly approved for sharing. Free tools that capture everything cannot make that distinction.

Local ownership and portability keep you in control

Free tools sometimes rely on cloud back-ends or obscure storage formats that lock you into a particular ecosystem. When a service shuts down or changes its terms, you may lose access to years of accumulated knowledge.

LoreConvo stores everything in a single local SQLite file that you own. The file lives on your machine, on a network drive, or in any location you choose. Because SQLite is a widely supported open format, you can copy the file to a backup medium, move it to a new workstation, or mount it in a container without any special migration steps. Session export and import tools let you create JSON or JSONL snapshots of any subset of sessions, preserving UUIDs for idempotent restores. This portability is available in the free tier. The Pro tier adds async session sharing, allowing teammates to merge exported sessions without a central server.

Data residency is a concrete benefit for teams that must keep data within a specific jurisdiction. Since the database never leaves your environment unless you decide to share it, you retain full control over where the information resides and who can read it.

Advanced search and discovery

Free memory layers often rely solely on full-text search. That works for exact keyword matches but falls short when you need to find sessions that discuss a concept without using the same terminology. A search for "authentication" can miss sessions that discuss OAuth or token exchange.

LoreConvo's Pro tier adds a hybrid semantic search. It combines vector embeddings with BM25 full-text indexing, then applies a reciprocal rank fusion and a recency decay reranker. The result is a search experience that returns relevant sessions even when the query uses different phrasing. Related session discovery goes further, automatically linking sessions that share keyword co-occurrence and embedding similarity so future auto-load can use those connections. Free users still benefit from the robust FTS5 full-text engine. The semantic layer in the Pro tier reduces the time spent hunting for the right context when your vocabulary has shifted since you last touched a problem.

When does the Pro tier make sense?

The free tier of LoreConvo offers 50 sessions, full-text search, project tagging, and the auto-save hook that captures a heuristic summary, tool calls, tech-stack facts, and open questions when the session contains enough signal. For many hobby projects and early explorations, that is more than sufficient.

The Pro tier, at $8 per month, removes the session limit and unlocks semantic search, related session discovery, async LLM summarization, and team memory sharing. It also adds memory consolidation tools that analyze recent sessions, extract decisions, and inject a concise digest at the start of new work. If your workflow involves multiple collaborators, frequent model iterations, or any compliance requirements, those features provide measurable time savings and the audit trail that justifies the cost.

The honest comparison

Free AI memory tools have democratized the ability to capture and retrieve work across many environments. They are a great entry point for solo developers and quick experiments. Yet they typically assume that every piece of data can be stored without explicit consent, and they provide little structure for tracing the origin of decisions.

LoreConvo was designed to fill that gap: by default it isolates external tool sessions, tracks provenance through tags, links, and skill histories, and stores everything in a portable SQLite file that you control. The cross-surface identity is not marketing copy -- it is a verified zero-config behavior across four distinct agent environments. The Pro tier adds semantic search and collaborative features that keep the workflow fluid while preserving the audit trail required by teams working with sensitive data.

We measured the practical cost of context loss in an earlier post -- the numbers from running a real agent fleet are sobering. This post is the logical follow-up: once you decide the cost of losing context is real, the next question is what kind of memory layer you actually want. And we explored the local-first design rationale separately if you want the architecture argument before the feature comparison.

Free tools benchmark throughput and recall. They do not benchmark whether you consented to saving a session, whether you can prove where a decision came from, or whether your data stays in your jurisdiction. For the practitioners for whom those questions matter, the $8/month answers them.

Explore LoreConvo's full feature set at the tools page or get in touch if you would like to talk through how it fits your specific data environment.

PS: Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth.

Originally published at Labyrinth Analytics Consulting.