Eliminate The Work That Shouldn't Exist

Katie West has fifteen years in Customer Success. She has managed hundreds of customers across Rakuten and Rudderstack. She is, by any measure, a smart operator.

She spends her days writing the same email a hundred times.

Not because she wants to. Because the tool that would eliminate that work does not exist. She knows what the email should say. Usage dropped 20% last month. A feature isn't enabled. Nobody's logged in for three weeks. The data is there. The triggers are obvious. But no system connects the data to the action. So Katie opens a giant Excel sheet, finds the next customer, and writes another email by hand.

She can only reach enterprise accounts and the biggest gaps. Everyone else doesn't get reached at all.

This is the story of February for AI builders. Not a story about new models or funding rounds. A story about a specific gap between what operators need and what builders are making. The gap is not about speed. It is about existence. The work Katie does should not exist. Neither should most of what we watched operators grind through this month.

Andrew Mewborn, founder, spends ten hours a week manually A/B testing emails. Subject lines, hooks, body copy, CTAs. One variable at a time. Tracking in spreadsheets. He is the scientist, the lab tech, and the data analyst, all in one person. He doesn't need a better spreadsheet. He needs the testing to run itself.

Katie doesn't need a faster way to write customer emails. She needs the emails to send themselves when the usage data hits a threshold.

The difference between those two sentences is the difference between automation and elimination. And most builders are still building the first one.

Paul Irving sees this pattern across a hundred companies. He's a VC. Different industries, same problem. His example cuts clean. Friday afternoon, you email a client for a simple yes or no. They're three hours ahead. Don't see it until Monday. Busy Monday. Respond Monday afternoon. You get the answer Tuesday. Four days for a yes or no. AI made the email better. Nobody eliminated the wait.

His elimination version: voice AI handles the exchange asynchronously. The client calls Saturday afternoon while walking the dog. You have the answer Saturday night. No email chain. No calendar coordination. The work disappears.

Six dollars an hour for voice AI. Twenty-five dollars an hour for a human. The economics used to make elimination impossible. Not anymore. Two people and six weeks can now build what used to take a team and eighteen months. The problems didn't change. The cost to kill them did.

Paul's accounts receivable example makes the math even starker. Billions of dollars stuck in AR across every industry at any given time. The current approach: AI generates personalized follow-up emails, tracks responses, escalates to a human when needed. Still takes weeks. You automated the emails. You didn't eliminate the loop. The elimination version: an agent handles the entire conversation. Answers questions with invoice data. Reconciles discrepancies against purchase orders. Negotiates payment terms within pre-approved parameters. No human unless it's an exception. Shave two days off that cycle across an entire economy, and you're talking about trillions of dollars in unlocked value.

So why aren't more builders doing this?

Because elimination requires a different kind of seeing. When you find manual work, the instinct is to make it faster. Someone writes emails slowly, you build an AI email writer. Someone tracks results in spreadsheets, you build a better dashboard. That's automation thinking. It's intuitive. It ships fast. It feels like progress.

Elimination thinking asks a harder question. Why does this work exist? Katie writes a hundred customer emails because no system connects usage data to outreach triggers. Andrew runs manual A/B tests because no system advances to the next variable when a threshold is hit. The email isn't the problem. The test isn't the problem. The human in the loop is the problem.

John Gleeson, a VC at Success VP, watched Motive scale from one million to three hundred million in ARR. Now he invests in early-stage startups. He's not an engineer. Last time he coded was university. But he built his own CRM using Claude. Built fund modeling with Monte Carlo simulations. Commits to GitHub every day.

He treats building like training. His phrase: if you're a professional athlete, you'd go to the gym every day. You'd treat it like a glass ball you wouldn't want to drop. People who are a step behind the play get cut.

The bar moved. What used to impress at pre-seed doesn't anymore. John sees founders who shipped over a weekend what would have taken a team months. The question isn't whether you can build. Everyone can build now. The question is whether you know what to build. And the answer to that question lives inside the operator's day, not inside the model's capabilities.

Katie told us: all roads lead back to spreadsheets. Her data lives in five places. Sigma for product usage. HubSpot for contracts. The product database for actual users. Support tickets for health signals. Google Sheets for everything else. She hired someone to connect Sheets to Sigma. She's manually building out feature flag tracking. She's pulling contract data from HubSpot by hand. She will do this for six to twelve months, then invest in building it out properly. Then she will leave this company and do it all over again at the next one. Third time rebuilding the same infrastructure.

She's not asking for AI magic. She's asking for mail merge with usage data. In 2026.

The athletes, to borrow John's framing, are the builders who hear Katie describe her day and don't reach for the obvious automation play. They hear her say "I manually email everybody myself" and ask why that sentence is possible. They hear Andrew say "I spend ten hours a week testing" and ask why a human is in that loop at all. They hear Paul describe four days for a yes or no and ask why communication is still sequential when it could be parallel.

Elimination is harder to see than automation. It requires knowing the workflow deeply enough to ask whether the workflow should exist. That knowledge comes from talking to operators, not from reading model release notes. It comes from sitting with Katie while she opens the Excel sheet for the fortieth time this week. From watching Andrew toggle between tabs tracking subject line performance. From understanding that the pain isn't in any single step. The pain is that the steps exist.

The agents are coming. They will run daily life for billions of people inside ten years. They will book flights, manage calendars, handle invoices, schedule plumbers, refill prescriptions. But only where the doors are open. No API means no agent access. No agent access means humans are still stuck doing it themselves. The builders who create those doors, who build the access layers and trust infrastructure that let agents act on behalf of humans, will own the next decade.

But the first step is smaller than that. The first step is finding Katie. Finding Andrew. Finding the operator who knows exactly what needs to disappear but can't make it disappear alone.

The opportunities aren't hiding. They're sitting in plain sight in every operator's day. You just have to ask the right question.

Not how can we make this faster. Why does this exist at all.