Where Your AI System's Data Should Actually Live

A while back I went looking for the "real" version of a document one of my agents had produced. There were three copies. One in the repo, one in a cloud drive, one in a knowledge base. All slightly different. None of them labeled as the source of truth. I had built a system that could research, write, and coordinate across agents, and I couldn't answer the most basic question about it: which copy is real.

That is the failure most AI-system storage advice walks you straight into. The reflex when you start building anything with agents is to pick one store and pour everything into it. Pick the wrong one and you don't notice for months, because everything technically works. Then you go to edit something by hand, or diff a change, or hand an agent its context at startup, and the store fights you.

The fix isn't a better store. It's accepting that not all data is the same kind of data, so it shouldn't all live in one place. Route each artifact to the tier that's good at holding its kind.

The three defaults, and where each one breaks

Before the pattern, the alternatives, because I tried versions of all three.

Put everything in a vector store / RAG index. The reflexive AI-app default, and for its actual job, semantic retrieval over a big pile of text, it's great. The problem is people reach for it as the system of record, and retrieval is not a source of truth. A vector store is opaque: you can't open it and read what's in there, you can't edit a line by hand, and there's no clean answer to "which copy is real" because the whole point is fuzzy lookup, not canonical storage. Retrieval is a read path. Treating it as your truth means your truth lives somewhere you can neither inspect nor correct.

Keep everything in one knowledge base. Notion, Confluence, Obsidian. Seductive because it's genuinely excellent for humans: rich structure, comments, editable from a phone on the couch. But it loses on the two things agents care about most. It isn't reliably diffable, so you can't see what changed between two versions the way version-control history shows you. And it isn't dependably readable at boot, the way a plain file an agent loads at startup is. Structure also erodes: a clean hierarchy in month one is a swamp by month six, because every human edit nudges it sideways and nothing enforces the shape.

Put everything in the repo / git. For code, configuration, and canonical text it's the best tier there is: diffable, reviewable, readable by every agent at startup, full history for free. But binaries bloat it, sensitive data must never touch it, and no human is editing a markdown file in git from their phone. Git is a great canonical store for the things that belong in git, and a bad home for everything else.

Each one wins decisively at one job and loses badly when you stretch it to cover the other two. So stop stretching.

Route by character, not by convenience

The pattern I landed on is three tiers, each matched to the nature of what it holds:

• A version-controlled file tier (git, a repo) for code, configuration, and the canonical text agents read at startup. Diffable, multi-agent-readable, low-volume. This is your spine.
• A file/object store tier (a cloud drive) for deliverables, binaries, and sensitive data that has no business in version control. Rendered outputs, large files, anything with PII.
• A relational, human-facing tier (a tool like Notion) for relational structure, comments, and mobile-first human editing. Where a person curates and reacts, not where agents boot from.

The deciding question isn't "where is it convenient to put this." It's "what is this thing, by nature." Code is diffable text many readers consume: file tier. A 40-page PDF with a client's name in it: object store. A status board a human pokes at from their phone: relational tier. The artifact's character picks the tier. You're not making a storage decision so much as reading what the thing already is.

When I'm genuinely unsure, three questions in order settle it:

1. Is it code, config, or canonical text an agent reads at startup?
   -> version-controlled file tier (the repo)

2. Is it a deliverable, a binary, or sensitive data that shouldn't be in git?
   -> file/object store tier (the cloud drive)

3. Is it relational structure, comments, or something a human edits from a phone?
   -> relational / human-facing tier

First match wins. That ordering matters, because some artifacts answer yes to more than one question, which is the whole reason you need the next piece of discipline.

One copy is real; the rest are labeled mirrors

Some things legitimately want to live in two places. A summary an agent generates may need to be canonical text in the repo and visible in the human-facing tool. The trap is letting both copies pretend to be the original. That's exactly how I ended up with three versions of one document and no idea which to trust.

The rule that fixes it: when something lives in more than one tier, one tier is the single source of truth and every other copy is a pointer-only mirror, labeled as such. The mirror says, in plain text, "canonical version lives over there." Nobody edits the mirror expecting it to stick. There is always exactly one answer to "which copy is real," and it's written down.

That discipline is the cost of the whole approach. You accept a little duplication, and you accept that maintaining the canonical-vs-mirror pointers is manual work nobody else will do for you. In exchange you never again lose ten minutes deciding which copy to trust, and you never ship the stale one.

Why this fits my systems, and when it would be overkill

I run two AI systems this way: a personal assistant and a trading-automation system. Both are multi-agent and coordinate through files rather than a shared database. That architecture is what makes the three-tier split pay off:

• The agents need a boot-time-readable canonical store, plain files in version control, so every agent reads identical context at startup and changes are diffable. Git wins here, decisively.
• A human (me) still needs a mobile editing surface for the things a person actually curates. The relational tier wins there, and only there.
• Deliverables and anything sensitive need a home that isn't version control. The object store wins that one cleanly.

No single store does all three well. The vector index can't be the spine, the knowledge base can't be the boot context, the repo can't hold the PII. So I stopped asking which store to use and started asking which tier each artifact belongs to.

I want to be honest about the other side, because most of the internet would sell you three tiers regardless. If you're building a single-user app with no agents, this is overkill. One good store and a backup is the right call, and adding tiers is just ceremony you'll resent maintaining. The pattern earns its keep when you have multiple agents that need a diffable canonical context, a human who needs to edit some of it by hand, and outputs or data that can't sit in git. Short of that bar, don't bother.

The shift that mattered wasn't picking the perfect database. It was realizing the question was wrong. Storage isn't one decision. It's a routing decision you make per artifact, by reading what the thing actually is.