Your AI Agent Doesn’t Have a Model Problem. It Has a Data Problem.

Why building reliable AI agents requires more than choosing a better LLM.

A book I read a while ago has been on my mind again recently: Designing Data-Intensive Applications by Martin Kleppmann.

I found myself going back to it, and this time, I started looking at some of its ideas through a different lens: AI agents.

We spend a lot of time discussing which model to use, how to improve prompts, and how to build better agent workflows. But many of the problems I keep running into aren't really about the model itself.

They're about data. How it's retrieved, how it stays up to date, how state is managed, and how different parts of a system stay consistent.

These are familiar engineering problems. We've been dealing with them long before LLMs became part of our daily work.

And I think many of the lessons from Kleppmann's book are just as relevant to AI agents as they are to traditional distributed systems.

Retrieval-Augmented Generation (RAG) is often presented as a straightforward solution: index your documents, retrieve relevant chunks, and send them to an LLM.

In practice, getting retrieval right is much harder.

Imagine building an AI assistant that understands a large banking application. A developer asks:

Where is the credit card detail screen, and which backend endpoint provides its data?

The answer might involve several parts of a monorepo:

A basic vector search might retrieve a file containing the words “credit card details.” But that doesn't necessarily tell us how the data flows through the application.

The relevant information may be spread across several files, and the relationships between them matter as much as the files themselves.

This is where data architecture starts to matter.

A more useful retrieval system could combine:

The goal isn't simply to retrieve text that looks relevant. It's to reconstruct enough of the underlying system to answer the question correctly.

This is closely related to a broader idea in Designing Data-Intensive Applications: the way we organize, index, and derive data has a direct impact on what our systems can do with it.

A better model can't reliably compensate for information that your retrieval system never found.

An API endpoint changes during a refactoring. The code is updated, the tests pass, and the application works as expected.

But the AI assistant still uses an old index.

A developer asks about the endpoint, and the assistant confidently returns the previous implementation.

The model might reason perfectly from the information it received. The problem is that the information is no longer current.

Traditional data systems have dealt with similar challenges for years: replication lag, stale caches, delayed processing, and derived data that falls behind its source.

AI systems introduce another layer of derived data. Embeddings, code summaries, knowledge graphs, and retrieval indexes are all representations of an underlying source.

When that source changes, these representations need to be updated.

A practical indexing pipeline might look like this:

Source code changes | v Detect changed files | v Rebuild affected chunks and relationships | v Update search indexes | v Make updated knowledge available to agents Enter fullscreen mode Exit fullscreen mode For a large repository, rebuilding everything after every change may be too expensive. Incremental indexing, dependency tracking, and background processing can make the pipeline more efficient.

The important part is having a clear strategy for keeping derived data in sync with its source.

This is also why an AI assistant should be able to identify where its information came from and, when necessary, check the current source before making a claim.

Retrieval quality isn't just about relevance. It's also about freshness.

Multi-agent systems are often described in terms of roles: a planner, a designer, a frontend developer, a backend developer, and a tester.

That sounds reasonable. But what happens when one agent fails halfway through a workflow?

Imagine a system that creates a GitLab merge request, runs tests, and asks a reviewer agent to inspect the changes.

The review request times out. The orchestrator doesn't know whether the operation failed or whether the result was simply delayed.

Depending on how the workflow is implemented, the system might create duplicate work, lose track of the original task, or report a result that doesn't reflect the actual state of the merge request.

Adding another agent won't solve this problem.

type TaskStatus = | " pending " | " running " | " completed " | " failed " | " retrying "; interface AgentTask { id: string; status: TaskStatus; attempts: number; result?: unknown; error?: string; } Enter fullscreen mode Exit fullscreen mode This is only a starting point. A production implementation would also need persistent storage, task ownership, timestamps, retry policies, and a way to recover after a process restarts.

For operations with side effects, idempotency is important too. Retrying a task should not blindly repeat an action that has already succeeded.

A reliable workflow should be able to answer questions such as:

These are familiar distributed-systems questions.

An LLM can decide what to do next, but the surrounding system must reliably track what has already happened.

Memory helps an agent remember context. State helps a workflow remain correct. They are not the same thing.

When an AI system struggles with a large codebase, one tempting solution is to give the model more context.

Sometimes that helps. But it doesn't remove the need to decide which information matters.

Suppose your repository contains hundreds of projects and more than a million lines of code.

Sending thousands of files into a model's context window isn't necessarily useful, even if the model technically supports it. Much of that information will be irrelevant to the current task.

And if the relevant relationship between two files is missing, adding more unrelated files won't automatically make that relationship clear.

A more useful approach is to build a pipeline that selects and organizes information before it reaches the model:

User question | v Understand the task | v Retrieve relevant files and symbols | v Follow dependencies and references | v Rank and filter the results | v Build focused context | v LLM generates an answer Enter fullscreen mode Exit fullscreen mode This approach can reduce unnecessary context, improve relevance, and make the system easier to debug.

It also creates opportunities to cache results, reuse indexes, and apply access controls before sensitive information reaches a model.

The context window is a resource. The data pipeline determines how effectively we use it.

Traditional application observability helps us understand what happened inside a system through logs, metrics, and traces.

Agentic systems need much of the same infrastructure, but there are additional questions to answer.

Suppose an agent returns an incorrect answer. Looking only at the final response won't tell us why.

Was the source data outdated? Did retrieval return the wrong documents? Did a tool call fail? Did the model misinterpret the result? Did an earlier agent pass incomplete information to the next one?

To investigate the problem, we need visibility into the entire execution.

For an agent workflow, useful signals include:

Consider a coding agent that claims a bug is fixed.

A useful trace should help us determine which files it inspected, what changes it proposed, whether tests actually ran, and whether the test results support its conclusion.

This is more than logging the model's prompt and response. It's observing the behavior of a system that combines probabilistic reasoning with deterministic software components.

Without that visibility, debugging becomes guesswork.

And without evaluations, we may not even notice that a change to the retrieval pipeline has made the system worse.

Looking at AI agents through the lens of data-intensive applications changes how we approach their design.

Instead of asking only, “Which model should we use?”, we can ask a broader set of engineering questions:

These questions don't replace model selection, prompt engineering, or agent design. They complement them.

A powerful model is still important. But it operates within a larger system, and the quality of that system places real limits on what the model can accomplish.

Revisiting Designing Data-Intensive Applications reminded me that many of the difficult problems in AI engineering aren't entirely new.

We are building new kinds of applications, but we still need to deal with data consistency, derived indexes, distributed execution, state management, fault tolerance, and observability.

The difference is that we now have LLMs making decisions and interacting with these systems.

That makes the engineering around them more important, not less.

If you're building AI agents, don't focus exclusively on making the model smarter. Pay attention to the data it sees, the state it maintains, and the systems it depends on.

Because sometimes, the problem isn't that your AI agent can't reason.

It's that the system hasn't given it the right information to reason about.

Martin Kleppmann, Designing Data-Intensive Applications, O'Reilly Media, 2017.

The book explores the principles behind reliable, scalable, and maintainable data systems, including storage and retrieval, replication, consistency, batch processing, and stream processing. Many of those principles remain useful when designing the infrastructure behind modern AI agents.