DEV Community: Debbie Shapiro

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

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.

Cron'd Claude Agents: A Maintenance Log

Debbie Shapiro — Wed, 05 Aug 2026 02:18:34 +0000

Running a fleet of twenty Claude agents on a launchd schedule teaches you fast that scheduler guarantees are weaker than you expect. Each agent wakes, processes a slice of work, writes its results, and goes back to sleep until the next tick. The pattern is simple; the failure modes are not. Three months of nightly runs have turned up launchd timing quirks, session-end failures, and the quiet pressure of growing turn counts. This post is a candid maintenance log: what broke, why it broke, and what I changed.

The scheduler is not a magic timer

When I first set up the cron-style jobs, I used launchd because it integrates cleanly with macOS and gives fine-grained control over start times, resource limits, and restart policies. The first surprise was that launchd does not guarantee exact start times. If the system is busy, a job may be delayed by several seconds, and those seconds add up over a day. For a single agent the drift is negligible, but with a fleet of twenty the cumulative delay can push the final run past the intended window, causing overlapping executions.

The overlapping runs manifested as two agents trying to write to the same SQLite file at the same time. SQLite locks the file for writes, so the second agent stalled until the lock cleared. In a tight schedule that meant a cascade of timeouts, and eventually the launchd daemon marked the job as failed. The fix was to assign each agent a distinct, fixed start minute in its launchd plist. Rather than allowing multiple agents to share the same start slot, hand-spacing the schedule across the day gave each agent a clear window with no overlap and eliminated the write-lock cascade.

Another hidden quirk is launchd's handling of environment variables. The agents rely on a PATH that includes the Python interpreter and a few helper scripts. When launchd launches a job, it inherits a minimal environment that does not include the user's shell profile. The first few runs failed with "command not found" errors because the interpreter could not be located. The solution was to define the full PATH inside the launchd plist and to reference the interpreter with an absolute path. This made the jobs independent of any interactive shell configuration.

Turn budgets are counts, not tokens

Claude agents in this fleet run under per-ticket turn-count ceilings, not token budgets. The ceilings live in a central configuration file and vary by the type of work: a build ticket gets a higher ceiling than a review. The numbers were calibrated against historical run data at roughly twice the measured mean, so legitimate work should rarely approach the limit.

The monitoring piece came first: a turn monitor runs alongside each agent session and fires warnings at the ceiling. What came later was enforcement. The practical lesson is that instrumentation has to precede enforcement. Without knowing which ticket types run long, any ceiling you set will cut legitimate work short on some types and leave the door open on others. Instrument first. Calibrate against real data. Enforce later.

Session-end handling and data ownership

Claude agents automatically save a session summary at the end of each run. The most common failure mode was a sudden termination of the Python process due to an unhandled exception. When the process died, the SQLite transaction was left open, and the next run attempted to write to a locked database. The lock persisted until the operating system reclaimed the file handle, which could take minutes. During that window the entire fleet stalled.

Ensuring that every database connection is explicitly closed on exit -- whether the session ends cleanly or not -- is the fix. A connection left open by a crashed process holds the write lock until the OS reclaims the file descriptor. Adding explicit close calls in the error path, rather than relying on garbage collection, keeps the lock window short and the next scheduled run clean.

I wrote earlier about the cost of context loss between agent sessions -- that post focuses on the token waste. Here the problem is the structural consequence: lost writes corrupt downstream data.

Another subtle issue was the handling of open questions. The agents try to capture any unanswered items that arise during a run. The capture is best-effort: if the session does not contain enough signal, the question is not recorded. Early on I assumed every open question would be saved and built downstream alerts on missing rows. When the capture failed silently, the alerts generated noise and eroded trust in the monitoring system. Treat the open-question log as a helpful hint rather than a strict contract, and design downstream processes to tolerate missing entries.

What three months taught me

Running a fleet of Claude agents on a schedule is not a set-and-forget exercise. Schedule reliability matters more than raw speed. Turn budgets need instrumentation before enforcement. Robust session handling prevents cascading failures that can bring the whole fleet to a halt.

If you are a data engineer or AI practitioner building an autonomous agent fleet, these are your maintenance checklist items. Start with a well-defined schedule, monitor turn counts from day one, and make your data persistence resilient to crashes. If you are considering building an agentic data pipeline from scratch, the LangGraph implementation guide covers the architectural decisions that precede the operational ones covered here.

This post is the first in an ongoing maintenance log. Read the full post on the Labyrinth Analytics blog, or reach out if you already have a fleet running and want a second pair of eyes on the design.

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

Why durable knowledge needed its own store

Debbie Shapiro — Tue, 04 Aug 2026 03:49:08 +0000

When a prompt ends, the model forgets. That is why LoreConvo was built -- to keep the thread alive while you iterate on a design, debug a pipeline, or explore a new model. LoreConvo's session memory saves and recalls conversation context automatically, so your model can pick up where it left off. However, session memory is only part of the picture. For data engineers and AI practitioners who spend hours curating datasets, tuning embeddings, and documenting model behavior, the real challenge is structured artifacts: data schemas, experiment results, and code snippets that need to survive beyond individual conversations, be versioned over time, and be queryable by both humans and machines. Recalling a session summary is not the same as retrieving a specific schema version or a ranked set of experiment logs. That gap compounds over time.

Session memory and structured artifacts are different retrieval problems, and bolting the second onto the first would have compromised both. What the work needed was a place to store the structured knowledge that survives beyond a single chat: versioned, searchable, and accessible to the model without manual copying. So we built a dedicated document store that complements LoreConvo's session memory rather than duplicating it. LoreDocs is a local knowledge vault that lets you keep, version, and retrieve the artifacts of your AI work without ever leaving the tools you already use.

From fleeting chat to lasting insight

A typical day for a data engineer might start with a quick conversation with an LLM to sketch a data pipeline, then move on to writing a Spark job, testing a feature store, and finally documenting the results. Each step generates artifacts: SQL snippets, configuration files, experiment logs, and design notes. With LoreConvo, you can ask the model to summarize the pipeline or suggest improvements, but once the session ends the model no longer has access to those details. You end up copying the summary into a wiki, a ticket, or a notebook, and you lose the direct link between the model's reasoning and the original source.

LoreDocs bridges that gap. It treats every document -- a markdown note, a JSON schema, a plain-text log -- as a first-class citizen in a vault that lives on your own machine. The vault is a single SQLite file you own, back up, and move wherever you need. Because the data never leaves your disk, you retain full control over privacy and compliance, a requirement that many teams cannot ignore.

Why a dedicated knowledge store matters

Durable knowledge is more than a backup of chat transcripts. It is a structured, searchable, and versioned repository that can be queried by both humans and machines.

The multi-vault system lets you create named vaults that reflect the logical boundaries of your work -- for example, one for your feature-store schemas, another for model experiment logs, a third for architecture notes. Each vault can be tagged and searched independently. The workspace-scoped auto-vault feature mirrors the way you organize projects on disk: opening a vault bound to a directory path is idempotent, so onboarding a new project means a single call that follows your existing folder structure.

Full-text search powered by SQLite's FTS5 engine lets you find documents across vaults with simple keyword queries. When you need to locate a specific transformation step or a hyper-parameter setting, a search returns matching documents and the surrounding context. For practitioners who need deeper retrieval, the Pro tier adds semantic search: a hybrid LanceDB index combining dense embeddings with BM25 ranking, chunk-aware at paragraph boundaries, so results rank by meaning rather than exact keyword match.

Document versioning records every change you make. If a schema evolves or a model configuration is tweaked, you can restore a previous version with a single command -- an audit trail that matters for reproducibility and post-mortems. When you need to give an LLM access to a whole vault at once, the vault-prime operation injects all vault context in a single call, which is especially useful in automated pipelines where the model must reason over a collection of documents before producing output.

Finally, LoreDocs integrates with the same MCP ecosystem that powers AI-enhanced IDEs. By placing a configuration file in your project, tools like Claude Code, OpenAI Codex, Cursor IDE, and Hermes Agent can discover the vault automatically. No per-client setup is required. For environments that cannot use MCP, a Python fallback script provides the same query access against the local SQLite store.

How LoreDocs fits a data engineer's workflow

A data engineer's workflow is already a blend of Python scripts, notebooks, and IDE extensions. LoreDocs adds a thin layer that feels native to that mix.

When you start a new project, your agent opens a vault scoped to that workspace: one idempotent call binds the vault to the directory, so there is nothing to wire up by hand. Adding knowledge from there is direct -- point LoreDocs at a file on disk, or have the agent write an ad-hoc note straight into the vault. If you already keep a rich set of markdown notes in Obsidian, a single call imports the entire vault directory, walking the folder tree and extracting YAML frontmatter tags so your existing knowledge base is searchable from any MCP client. For automation that runs without an MCP client -- a scheduled job or a CI step -- a bundled Python fallback script performs the same add and search operations directly against the local SQLite file.

When you need to find something, a keyword search returns matching documents with context. Semantic search (Pro) handles the cases where you remember the idea but not the exact wording. Because every vault lives in a single file, moving a project to a new machine is as simple as copying that file -- no hidden cloud service, no vendor lock-in.

The free tier gives you three vaults at no cost, which covers most personal experiments. When you need unlimited vaults, the Pro tier adds semantic search, auto-discovered document relationships, and the full MCP tool suite.

A durable store for a durable future

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. The combination of multi-vault organization, full-text and semantic search, version control, and zero-config integration with popular AI-enhanced IDEs creates a workflow where the model can both generate new ideas and retrieve the exact pieces of prior work that inform those ideas.

LoreDocs is available now (currently in beta) via PyPI and our self-hosted plugin marketplace: see the Lore tools page for install steps and the rest of the Lore suite.

PS: Get posts like this delivered weekly -- subscribe to Dispatches from the Labyrinth: https://labyrinthanalytics.substack.com/subscribe?utm_source=devto&utm_medium=referral&utm_campaign=substack_subscribe

LangGraph in an Existing Data Stack

Debbie Shapiro — Sat, 25 Jul 2026 02:48:40 +0000

Deploying LangGraph into a production data stack means treating it as a composable service that fits alongside the APIs, schedulers, and warehouses you already run -- not replacing them. The graph defines the reasoning flow; your existing infrastructure defines when it runs, where the data comes from, and where the results land. In this post I walk through the practical integration decisions: triggering the graph from existing schedulers, reading and writing the warehouse, persisting state between runs, and positioning LangGraph relative to dbt and your orchestrator. I covered the foundational architecture decisions in the LangGraph pipeline guide; this post picks up at the point where that design enters an existing stack.

Why LangGraph fits into a modern data stack

A LangGraph workflow is a directed graph of language model calls, data lookups, and conditional branches. Because each node is a pure function of its inputs, the graph can be executed repeatedly without side effects, which aligns with the idempotent mindset of data pipelines. The graph's inputs and outputs are plain Python objects -- lists, dictionaries, or dataframes -- so they can be marshaled to and from the same formats your ETL jobs already handle.

From a data-engineering perspective, the most useful property is the ability to treat the graph as a black-box service. You expose a single HTTP endpoint that accepts a JSON payload, runs the graph, and returns a structured result. That endpoint can be called from any downstream job, whether it lives in Airflow, Prefect, or a custom cron script. The graph also supports incremental execution: you can feed it a batch of records, let it produce partial results, and resume later with a new batch -- which mirrors the way you already handle micro-batch loads.

Connecting LangGraph to existing APIs and schedulers

The first integration point is the trigger. Most organizations already have an API gateway or message queue that receives events from upstream systems: order placements, sensor readings, or model predictions. To bring LangGraph into that flow, you create a thin wrapper service. The wrapper extracts the relevant fields from the incoming request, builds the input dictionary the graph expects, and calls the graph's run method. Because the wrapper is just a FastAPI or Flask app, you deploy it with the same container image strategy you use for other microservices.

If you prefer a schedule-driven approach, the wrapper can be invoked from a DAG. In Airflow, a PythonOperator imports the wrapper function and passes a static or dynamically generated payload. The operator can be placed anywhere in the DAG: after a data load, before a model training step, or as a nightly audit. The key is to keep the wrapper stateless -- all configuration (model name, temperature, API keys) should come from environment variables or a secret manager, exactly as you do for other tasks.

Because the wrapper is a regular service, you can also hook it into serverless platforms. A Lambda function that receives an S3 event, builds the payload, and calls the graph runs without any dedicated server, which is a cost-effective way to prototype the integration before moving to a long-running service.

Reading and writing the warehouse

LangGraph nodes often need to fetch reference data or write results back to the warehouse. The most common pattern is to use a database client library inside a node. A node that enriches a transaction record might execute a SQL query against Snowflake, Redshift, or BigQuery, returning a dataframe that downstream nodes consume. Because the node runs in the same process as the graph, you can reuse a connection pool across multiple calls, reducing latency.

When writing results, follow the same append-only strategy you use for other pipelines. A node can append rows to a staging table, and a downstream dbt model can later transform that staging table into a final fact table. This separation keeps the graph focused on language-model logic while letting dbt handle data modeling and testing. If you need to move large volumes, consider streaming the results: a node can yield rows one at a time, and the wrapper can pipe those rows into a bulk loader like Snowpipe or BigQuery's streaming insert API. This prevents the graph from becoming a memory bottleneck and mirrors the way you already ingest logs or clickstream data.

Managing state and persistence

LangGraph itself does not store state between runs. For many use cases, the context lives entirely in the payload -- customer ID, time window, or feature flags. However, some workflows benefit from persisting intermediate results, especially when the graph includes long-running LLM calls you want to cache.

A portable solution is to write a small SQLite file to a location the wrapper can access. The file contains a table of node identifiers and their last output, which the graph can read on the next run. Because SQLite is a single-file database, you retain full ownership and can delete or edit it at any time. This pattern works well with containerized deployments: mount a persistent volume and the graph writes its cache there.

For larger state, use a key-value store such as Redis or a cloud-native store. The wrapper passes a state_store object into the graph's context, and nodes read or write entries as needed. This scales beyond a single file and integrates with caching layers you may already have for other services.

Where does LangGraph sit relative to dbt and your orchestrator?

In a mature data stack, dbt handles transformation logic and an orchestrator like Airflow or Prefect schedules jobs and manages dependencies. LangGraph fits as a processing step between extraction and transformation. A typical flow works like this: an upstream extractor loads raw events into a landing zone, a scheduler triggers the LangGraph wrapper passing a batch of new events, the graph enriches each event with LLM-driven insights and writes the enriched rows to a staging table, and a dbt model picks up the staging table, runs tests, and materializes the final table used by downstream analytics.

Because the graph writes to a staging table, you keep the same testing discipline you apply to other sources. dbt can assert that the new columns meet expected data types, that no nulls appear where they should not, and that row counts match expectations. If a test fails, the orchestrator flags the issue or rolls back the graph run automatically.

Adding a LangGraph task to an existing DAG is as simple as inserting a PythonOperator before the models that need the enriched data. The DAG still defines the overall dependency graph; the LangGraph internal graph defines the reasoning flow for each record. This separation lets you evolve the language-model logic without touching the broader pipeline schedule.

For observability, instrument the wrapper with the same tracing library you use for other services. Emit a span for each node, record execution time, and push metrics to your existing Prometheus or OpenTelemetry collector. That gives you a unified view of both data-pipeline health and LLM performance -- a topic I covered in more depth in the LangGraph state-transition observability post.

Bringing it together

Deploying LangGraph into an existing data infrastructure does not require a wholesale redesign. By treating the graph as a stateless service, you can trigger it from any API gateway, scheduler, or serverless function you already run. The graph reads from and writes to the same warehouses that power your analytics, you can persist intermediate state in SQLite or a shared cache, and positioning it as a preprocessing step before dbt keeps your transformation logic clean and testable.

If you are evaluating whether your project has reached the point where graph-based reasoning is warranted, the LangGraph vs. LangChain decision framework covers those signals in detail. And if you are ready to work through an integration design for your specific stack, our consulting services page outlines how we help teams design and implement these patterns. The finance-pipeline case study shows a concrete 19-node implementation as a reference point.

Ready to bring LangGraph into your stack? Reach out -- we can help you map the integration points, set up robust state handling, and ensure smooth handoff to dbt and your orchestrator.

What a LangGraph Engagement Looks Like

Debbie Shapiro — Sat, 25 Jul 2026 02:38:34 +0000

When a data engineering team first hears "LangGraph implementation," the mental picture is often a black-box sprint that delivers a finished agent overnight. In reality the process is a series of focused steps, each with clear hand-offs and a realistic timeline. Understanding what the engagement looks like helps you decide whether you need a consulting partner, what you will own at the end, and how the work fits into your broader roadmap.

What Happens in Discovery

The first week is all about listening. We meet with the engineers, product owners, and domain experts who will feed data into the graph. The goal is to surface the business problem, the data sources, and the performance expectations. We ask concrete questions: which downstream systems will consume the graph's output, what latency constraints exist for inference, and how often does the underlying data change. These answers shape a short discovery document that lists the success criteria, the risk factors, and the scope that can be addressed in a single engagement.

If the problem is purely exploratory -- a proof of concept that doesn't need integration with production pipelines -- then a consulting engagement may not be the right call. In those cases we often point teams to open-source examples and community forums, letting them iterate on their own before spending on outside help. When discovery reveals a clear integration point and measurable outcomes, we move forward. The client receives a concise brief that outlines the agreed objectives, the data assets in play, and the expected deliverables. That brief becomes the contract's foundation.

The Architecture Sketch

With the brief in hand, we draft a high-level diagram that maps data ingestion, transformation, graph construction, and inference serving. The sketch is deliberately lightweight -- it doesn't dive into line-by-line code, but it identifies the key components and how they connect. A data lake or warehouse connector extracts raw records into a preprocessing pipeline that normalizes and enriches them. The LangGraph definition encodes nodes, edges, and state transitions. An inference API exposes the graph's decisions to downstream services.

Each component comes with a technology recommendation that aligns with the client's existing stack. If the team already runs batch processing at scale, the loader pattern follows the same pattern. If the inference service must run containerized, we outline the deployment approach up front rather than discovering the constraint in week three.

A typical engagement moves through Discovery, Architecture, a fixed-scope Prototype Sprint, and optional Productionization -- with a documented Handoff Package at each exit.

The blueprint also includes a risk register. Data drift, graph definition versioning, and execution observability are the concerns that bite teams later, and naming them early lets the client see exactly where the consulting effort will focus -- and where they'll need to maintain the system after handoff. At the end of this phase the client has a documented architecture diagram, a list of recommended tools, and an implementation plan broken into weekly milestones. The scope is fixed: we agree on what will be built, not on an open-ended feature list.

The Fixed-Scope Prototype Sprint

The prototype sprint is a four-week, time-boxed effort that turns the blueprint into a working proof of concept.

In the first week we connect to the client's source systems, extract a representative sample, and run the preprocessing steps defined in the blueprint. Week two is graph definition and validation: using the LangGraph SDK, we encode the nodes and edges that represent the business logic, run unit tests, and verify that the graph produces the expected state transitions on the sample data. Week three wraps the graph in a lightweight API, containerizes it, and deploys to a test environment where simulated downstream calls verify latency and correctness. Week four ends with a demo, a walkthrough of the codebase, and a handoff package.

The handoff package is the deliverable the client owns when the sprint ends. It contains source code in a Git repository with clear commit history, configuration files for the data pipeline and inference service, a runbook describing how to start, stop, and monitor the system, and a set of automated tests the team can extend as the graph evolves. All work runs at a fixed price, so the total cost is known before a line of code is written. The sprint produces a validated foundation, not a production-grade system -- and that distinction matters when setting expectations with stakeholders.

Productionization

If the prototype meets the success criteria, productionization is the natural next step. This phase is optional and scoped as a separate engagement. The work involves scaling the ingestion pipeline to handle full-volume loads, adding monitoring and alerting for graph execution latency and error rates, implementing version control for graph definitions so rollbacks are safe, and integrating with the client's CI/CD system so graph updates are automatically tested and deployed.

When we move into productionization the client retains ownership of all code and data. The final deliverable is a self-contained repository that the client's own team can operate. We also run a knowledge-transfer workshop that walks engineers through the deployment process, troubleshooting steps, and best practices for maintaining a stateful agentic system over time. If the prototype already satisfies a narrower use case, productionization is optional. The handoff package from the sprint is sufficient for the client to run the graph in a limited environment, and we remain available for targeted support.

When You Might Not Need a Consultant

Not every LangGraph project requires outside help. If your team has deep experience with graph-based AI, a clear data pipeline, and the ability to write and test Python code, you can likely prototype internally. A consulting engagement adds the most value when the problem spans multiple data domains and needs a unified architecture, when you need a rapid prototype that aligns with business stakeholders on a fixed timeline, when your team is new to the specific patterns of stateful agentic workflows, or when you want an independent risk assessment and a documented handoff package you know you can hand to a new engineer six months from now.

In cases where a full engagement isn't justified, a short discovery session can still be useful. A high-level review of your plan, identification of common pitfalls, and a curated list of resources can help you move forward without committing to a longer project.

What to Read Next

For a look at a recent implementation -- a 19-node finance pipeline that runs in production -- see the finance pipeline case study. If you are still deciding whether to hire outside help at all, how to evaluate an agentic AI consultant covers the questions to ask before signing anything. The broader context for when LangGraph is the right tool lives in the LangGraph hub post.

When you are ready to talk about scope, timeline, and cost, the details are at /services. To start a conversation directly, reach out through /contact.

If you found this useful, also read Building Your First LangGraph Pipeline and Agentic Workflows vs. Traditional ETL Pipelines.