Below the API Line
Whose product decisions are encoded in your stack?
Gemini for Workspace has every advantage Google could give it. My inbox, my thread history, my calendar, my contacts. A frontier model, world-class compute, an entire org of engineers. The suggested replies are still only useful when the response is one or two lines. Anything longer doesn’t sound like me. The tone is too formal for the thread. It invents dates I don’t have free. It commits me to next actions I never agreed to. All this from a system that has my calendar. I paste the same thread into Claude or ChatGPT and the reply sounds like me in one or two tries.
Slack AI lives in the same bucket. Claude.ai and ChatGPT do better on the immediate paste, but I’m still working inside someone else’s product. The options for weaving something truly my own inside their walls are limited.
Naming the line
Garry Tan, on the YC Lightcone last week, citing his partner Pete Koomen:
Unless you have your own prompts and you can write it for yourself, you are below the API line for some PM or developer that is not you, who will not understand you, will not understand your needs, will not understand what you uniquely care about.
I’ve been watching the Gemini button fail at this for a year. Koomen had already named it back in April, in AI Horseless Carriages, built around the same Gmail case study.
It’s not Google’s fault. They have a lot of data about me. They don’t have my context. Someone wrote a system prompt for the median user, and the instruction “respond in my own voice to this email” is either not in there or overridden by something that is. I can’t see which. I can’t change either.
That gap, between the data the system has and the prompt that runs against it, is the API line. Above it, you write the prompt. Below it, you consume the output.
The vendor’s optimum is the median
The vendor must scope its prompt for the median customer. The whole book of users gets one prompt. A prompt that sounds like me would be wrong for the rest of the book, and a prompt that’s right for the rest of the book is wrong for me. Aggregating across that book pulls every system prompt toward the safe, generic middle. That’s the median-customer ceiling, and the vendor cannot raise it without giving each customer the keys, which is the same thing as putting them above the line. That move is not their business model.
LLMs don’t have taste; they average. Vendor AI features do that averaging twice. The model averages on the way in. The vendor’s prompt averages on the way out.
And even if the median prompt landed your voice tomorrow, the roadmap still belongs to someone whose business model is not your workflow. They can pull a feature you were using heavily, change its tone next quarter, gate it behind a higher tier, or quietly route it to a smaller model when their margins demand it. That’s just product management at a company whose customer is not you-specifically. The friction tax compounds below the API. You pay for mediocre output, and you pay for output you can’t keep.
Above the line, by example
A few months ago I spent about an hour building an email monitoring agent for myself. It watches my inbox. It triages. For threads that look like they want a real reply, it drafts a reply in my style into the Gmail drafts folder. I review the drafts like I’d review a junior teammate’s work, send the ones I like, edit the ones I don’t, ignore the ones it got wrong. It joins to my calendar so it knows when I’m meeting whom. (The same calendar Gemini has.) It can read what I’ve written about the people in my life because the context lives in markdown I own.
The first version confused itself. I was running everything through one long session, and the agent pulled fragments from one thread into a draft for another, classic context bleed. The fix was structural. I built a small orchestrator that hands each thread to a fresh executor with only the relevant context. Prompt cleverness wouldn’t have caught this; the tool architecture did.
The other interesting design choice is what the agent cannot do. It has no tool that sends mail. It can only add drafts. Safety is enforced at the tool layer, not at the prompt layer. The prompt could go off the rails entirely and the worst case is I open Gmail to a draft that’s wrong. No mail leaves without me. I’m not relying on instruction-following to keep me safe; I’m relying on the absence of the send tool.
LangChain documented the same pattern in their agents-from-scratch email assistant. Their send_email tool is gated behind an explicit human approval step, with the allowed decisions on it limited to approve or reject. Same logic. Safety lives in what the agent can call, not in what its prompt asks it to do.
That whole stack is mine. The prompt is in markdown. The tool list is in code. When the agent uses the wrong word for someone, I edit a line and commit. When I want it to handle a new kind of thread, I add an instruction. Nobody else’s roadmap controls what it does next month.
Drawing the map
Same model in both pictures. Wildly different output. Vendor AI buttons are the model with the harness chosen for you. Above the line is the harness you wrote.
For each AI feature in your stack, ask whose product decisions are encoded in it. If the answer is a vendor’s PM, you’re below the line on that workflow. If the answer is “ours, written down in markdown someone on the team can edit on a Tuesday,” you’re above. Most teams haven’t drawn that map yet. Drawing it is the first part of the work.
The personal computer revolution, again
Garry’s framing was that personal AI rhymes with the personal computer revolution. I think he’s right, and the choice is narrower than the analogy suggests. There won’t be a consumed-AI world and a personal-AI world running in parallel for any one person; you’ll live on one side. The ones who don’t move above the line will be running on prompts written by someone who has never met them, never read their inbox, and never will.
The Gemini button is still there. I don’t push it for anything longer than a sentence.