I Almost Wired Up Three APIs. The Context Was Already in Their Inbox.

A PE fund I work with — small team, tight ops — brought me in to sort out their data layer. I was three days into the design: folder watchers, a custom sync, three SaaS API integrations, webhooks for the bits that don't have APIs, a whole architecture diagram. I was pretty proud of it, honestly.

Then we got on a call last week. I walked the team through the build, and halfway through, the partner stopped me.

"Tim. Everything you're describing already comes into our email."

He was right. Their deal updates from Goldman? PDF attachments to a shared inbox. Citi capital calls? Email attachments. Sage exports from their fund admin? Forwarded as CSV by their controller every Monday. Quarterly statements, diligence docs — all email.

Three days of API design, and none of those APIs needed.

This is the trap I see every week: smart teams reaching for APIs the moment they want AI to do something with their data.

But here's what most businesses actually have:

That is the context library, and it's already there. Most of it isn't in an API — it's in human channels: email, Docs, folders, files. The mistake is reaching for an API when AI can just read what humans read.

One shared mailbox. Microsoft Graph for that one mailbox. An agent that parses every inbound message — who sent it, what the attachment is, what fund, what deal, what date — and drops the parsed result into a Postgres database with a pgvector column for semantic search.

Same outcome, with 10x less code. Zero vendor lock-in. No "this SaaS deprecated their endpoint" risk three years from now.

The fund's controller still emails the Sage CSV every Monday like he always has, and nothing changed for him. The agent picks it up, parses it, indexes it, and by the time the partner sits down on Tuesday, the data is in the dashboard.

Sit down for five minutes and audit where your business context actually lives. I bet it's in five or six places, and not one of them is an API.

For a private equity firm: every deal, every memo, every diligence file. Sitting in email and SharePoint.

For a SaaS company: every feature spec, every customer call recording, every postmortem. Sitting in Notion and Drive.

For an agency: every client engagement, every deliverable, every retrospective. Sitting in shared folders and meeting notes.

For a coach or consultant: every session transcript, every framework, every client outcome. Sitting in Granola and Notion.

The pattern is the same across every business I work with. The context is everywhere, which means it's also nowhere. Nobody can find anything. Nobody can search it. Nobody can ask a question across all of it.

That changes the moment you build an ingestion layer.

Three steps, no API required.

Step 1: Parse

Get everything into text. PDFs become markdown. Attachments become text. Meeting transcripts become structured notes. Images get OCR'd. You don't need fancy tools for this. Claude can do most of it with a script.

Step 2: Store

This is where Postgres comes in. Specifically Postgres with pgvector. That extension lets one database do two jobs. Structured data and vector search, in the same place. I use Neon. A lot of teams I work with use Supabase. Either works. Pick the one your team already knows.

One database, two jobs. SQL for the structured stuff. Vector search for "find me anything similar to this." No second tool. No second bill. No second thing to learn. pgvector is enough for almost every business under a few million documents.

Step 3: Query

Put an agent on top. Now anyone can ask a natural language question. The answer is grounded in your actual material. Not training data. Your data.

This is the new infrastructure stack. Parse, store, query. Three boxes. Skip the API layer entirely until you have a real reason to add it.

This is the part I really want you to pay attention to.

Anthropic shipped Memory in Managed Agents on April 23. It's in public beta inside the Claude Platform. It works as actual files the agent can read, write, and edit on its own. You can open them. You can inspect them. You can steer them.

Here's why it matters.

Before Memory: every time you started a new session with your agent, the agent forgot everything. You'd re-paste context. Re-explain your preferences. Re-tell it which client you're working on. Useful, but stateless.

With Memory: the agent now keeps memory files. It reads them, writes to them, edits them, organizes them across sessions. The memory lives next to the agent and you can read it like a notebook.

What this lets you do:

Now think about pairing that with what we just built.

The pgvector layer is your business corpus. Every deal, every doc, every transcript. Lives in Postgres. Queryable on demand.

Memory is your agent's running notebook. Decisions, preferences, ongoing state. Lives next to the agent. Updated every session.

Together, they are how an agent becomes a real colleague. The corpus is what it knows. Memory is what it remembers about working with you. This is what Human + AI looks like when it actually works.

This is the architecture I'm betting on for the next year of client work. Stop treating the agent as a stateless tool. Treat it like a person you're onboarding. Give it a corpus to read. Give it a notebook to write in. Let it get better at the job every week.

Memory is in public beta now at console.anthropic.com. If you already have a Managed Agent, flip it on this week. If you don't, this is a reason to build one.

Five things, and none of them require the stack I almost built.

Do all five this week. You'll have a working version of what I built for that PE fund. Without the three days I almost wasted on APIs.

Where is your context hiding? Email, Drive, SharePoint, Notion, somewhere else? Reply and tell me. I'm collecting patterns across industries and I'll share what I find back to you.

All the best,

Tim