The one database every AI-powered company needs

Two calls this week, different companies, different problems — and both of them drew me the same picture.

The first was a European private equity firm sitting on thirty-five years of deal history. The second was the support team at a fast-growing US software company, buried under tickets, call recordings, and Slack threads.

Neither had a single place where everything the company knows lives together, where their agents could ask a question and get a real answer, instead of digging through folders and hoping.

That is a more common problem than either of them realised.

Here is how I built the system that solves it.

Most companies store their knowledge the same way: files in folders, notes in someone's head, history buried in email threads. A human can navigate that, slowly.

For an agent to navigate it, it could take around 20 minutes, require connectors, and consume a lot of tokens.

With a proper SQL and Vector database for scalability the agent can query rapidly, with less tokens.

The “brain” is the thing that makes that possible. One database that holds everything the company knows, stored in a way that can be searched by meaning rather than exact words. Not "find the file called Q3-notes-final-v2" but "what did we agree with this client about pricing, across every call we ever had."

There are two kinds of memory in this system, and mixing them up is the most common mistake I see.

The first is an agent's private notebook — how my chief-of-staff agent knows my tone, my morning brief preferences, the people I never want to drop. That is personal to that agent.

The second is the company's shared memory: every deal, every call, every client, every promise. That cannot live inside one agent. It has to sit behind all of them, reachable by any of them. The brain is that second thing. Every agent I add — a sales one, a Slack one you can ask out loud — connects to the same shared brain, with its own private notebook on top.

The stack is simple.

Postgres is a proven database that has run serious companies for thirty years. pgvector is the add-on that gives it meaning-based search. Both live in the same database, so there is no second system to keep in step.

I use Drizzle to keep the tables typed and safe, and OpenAI's text-embedding-3-large to turn text into something searchable. I host on Neon, but Supabase or Snowflake would work just as well.

That shape has three layers.

The skeleton. Companies, contacts, deals — the nouns of the business. Anything you filter or sort on lives as a real column: a deal's stage, its amount, its date. And every contact stores the ID of the company it belongs to, so "show me everyone at this firm" is a one-step lookup rather than a search.

The content. Every source becomes a document, sliced into chunks, each turned into a searchable form that captures meaning. The same shape handles a deal file today and a call transcript tomorrow, so you never rebuild this layer. The critical detail: every chunk remembers which deal, company, and person it belongs to. That link is what makes "find everything about this client, across calls and emails and notes" work.

The connections. Every piece carries a note of its source, so any answer is checkable. Typed links between things — this person referred that one, this company owns that deal — turn a pile of rows into a map you can walk. "Everything this one introduction produced" becomes a path you trace, not a guess.

Two rules worth writing down before you build:

Trust in the whole system comes from being able to check the source.

There is one ingestion agent. Its only job is to read what comes in and write it to the brain. Every other agent is a reader. They ask questions; they never write. That split is not just good architecture — it is the security model.

It is what stops a system you run in plain language from quietly poisoning itself.

The whole surface is four tools, which is the only four moves any agent can make:

The loop that does the most work runs entirely without me. A call ends in my notes app. A job notices, pulls the transcript, works out who the call was with and which deal it belongs to, slices it into chunks, and stores them with a note of their source. A fingerprint check means running it twice never creates duplicates. A new call, a new email, a new note — it fires every time, without me remembering to trigger it.

There are two speeds. The slow one is a nightly pull for sources with no live signal. The fast one is a direct write: when an agent finishes a call summary, it drops straight into the brain the moment it is done. Batch for the bulk, live for the moment it matters.

Keeping it current comes down to three jobs. When something changes, the record updates and gets re-embedded. Sources with no live signal get pulled on a schedule, with anything unchanged skipped. A nightly check flags anything that drifted. The rule underneath all of it: the searchable copy is allowed to be a little behind. The truth is never allowed to be in doubt. The brain is an index, not the source of truth. The files stay the truth. The moment you start correcting a fact inside the index instead of at its source, you have lost the plot.

My first instinct was to let every agent write to the brain. That is the fast road to a mess. One writer, many readers fixed it.

I almost built a fancy search index too. Then I measured it. At my size, a plain scan answers in under a tenth of a second, so I skipped the index entirely and made a note to add it when the data is a hundred times larger. Do not build for scale you do not have yet.

The biggest mistake: I did not write down the rules before I started. Keep one source of truth per fact, with exactly one thing allowed to write it. Everything else is a one-way mirror.

Everything I just described is one piece of a larger thing. I run my whole company this way — from a terminal, in plain language, with files as the company's state and agents as the workers. I call it the terminal company. The brain is the shared memory underneath, the thing that makes the agents worth talking to at all.

The part that gets attention is typing one sentence and watching agents move. The part that lasts is the memory under it.

I’m writing this all down in a book called The Terminal Company. And I want to write it with you, in the open.

The plan is simple: I build the thing, I test it, I break it, and then I tell you what happened, here, first. These newsletters are the early chapters. You get to read them raw and push back before any of it sets on the page.

So, one thing before you go. Hit reply and tell me two things.

Where does your company's memory live right now: one person's head, a buried folder, or somewhere humans and agents can easily reach?

And what part of all this do you want me to go deeper on in the book? The best replies shape what I write next.

See you next week.

Tim