The proxy problem

Every organization has a bottleneck named after a person. The one who knows why the pricing model works the way it does. The one who remembers the client from 2019 who tried the same approach and it failed. The one whose judgment everyone trusts but nobody can articulate why.

When that person goes on vacation, things slow down. When they leave, things break. And the standard response — document everything, write it down, build a wiki — has never actually solved the problem. Twenty years of consulting taught me that. The knowledge isn’t in the documents. It’s in the judgment that connects the documents.

Today I built a proxy for myself.

Not on purpose. I was running eleven AI agents across different projects — a content platform, a blog, a course, a newsletter, an RSS reader, a couple of Mac apps, a game mod. Each agent is a Claude Code session in its own terminal window. They do good work. But they keep getting stuck on the same kind of question: “What consulting engagements should the case studies reference?” “Should this landing page lead with the credential or the problem?” “Why did we choose Maven over Kajabi?”

These aren’t hard questions. I’ve already answered all of them — in blog posts, in a book manuscript, in project decision logs, in context briefs I wrote for the course. The answers exist. But each agent only sees its own project. The course agent doesn’t know about the blog. The newsletter agent doesn’t know about the book. So they escalate. They ping me. I answer the same question I already answered somewhere else.

The obvious fix is a shared knowledge base. A wiki. A Notion database. A RAG pipeline. Something with an API that agents can query.

I didn’t build any of that. Instead, I’m loading a Claude Code session with everything I’ve ever written — the book, 642 blog posts, product docs, decision logs, competitive analyses, voice guidelines — and letting the other agents type questions into its terminal. Same mechanism they use to talk to each other: tmux send-keys. The proxy reads the question, searches its corpus, and writes an answer to a temp file. If it’s confident, the calling agent uses the answer and keeps working. If it’s not — if the question requires lived experience or taste or a story from a specific client engagement — it says “I don’t know, ask the real Paul.”

Here’s what’s interesting about this. It’s not a knowledge management system. It’s not a database. It’s a conversational agent with context. The difference matters.

A knowledge base gives you documents. You search for “pricing model” and get the pricing doc. But the pricing doc doesn’t know why the pricing model was designed that way, or how it connects to the competitive positioning, or what happened the last time someone proposed a different approach. A knowledge base is a library. What organizations actually need is a colleague — someone who’s read the library and can synthesize across it.

That’s what the proxy does. It doesn’t retrieve documents. It reads them, thinks about them, and answers questions. It can say “the audience brief says X, but the competitive positioning implies Y, so the answer is probably Z.” That synthesis is the thing documentation never captures.

Now, the proxy can’t do everything. It can’t tell a story about a specific client engagement because those stories aren’t written down — they live in my head, in the way I remember what the CFO’s face looked like when I told her the transformation was going to take eighteen months, not six. It can’t exercise taste. It can’t make the call on whether a sentence lands or falls flat. When the question requires that kind of judgment, it says so. And that honesty is the whole design: the confidence signal.

Every answer ends with one of three words. High — the answer is grounded in the corpus, use it. Medium — reasonable inference, use it but flag for review. Escalate — this needs the real person.

Most organizations don’t have that signal. They have either the bottleneck person answering everything, or nobody answering at all. The proxy creates a middle tier. It handles the 60-70% of questions where the answer is already written down. The remaining 30% still reaches me — but I’m not getting pinged for things I’ve already documented.

Here’s the broader point. The knowledge management problem was never a storage problem. We have more documentation tools than we’ve ever had. Confluence, Notion, Google Docs, SharePoint, internal wikis. The problem is synthesis. Documents exist. Nobody reads them. Nobody connects them. Nobody can answer the question “given everything we know, what should we do?”

Language models are the first technology that can actually do this. Not because they’re intelligent. Because they can read a large corpus and hold it in context while answering a question. That’s not artificial intelligence. It’s artificial literacy. And it turns out artificial literacy solves the proxy problem better than any wiki ever could.

I watched this work in real time today. The course agent was writing module outlines for a six-week executive program on AI transformation. It needed to ground the curriculum in competitive positioning — what makes this course different from every other AI leadership course. That answer was in a brief I wrote three weeks ago. Instead of pinging me, the agent will soon be able to ask the proxy. The proxy reads the brief, synthesizes it with the audience psychographics and the content approach doc, and gives an answer that’s better than what I’d give off the top of my head — because I don’t have all three documents loaded in my working memory simultaneously.

The proxy is better at recall than I am. I’m better at judgment than it is. Together, we cover more ground than either of us alone.

So here’s the question I’m sitting with tonight. If a proxy loaded with your documented knowledge could handle 60% of the questions your team asks you — what would you do with the time you get back? And what does it say about those questions that they could be answered by something that’s read your writing but never lived your life?