The bottleneck moved

Two years ago, getting AI to handle a real piece of your business meant building most of the judgment into it by hand. I built an AI-powered assistant for real estate agents around that time. It read a user's email account, sorted everything into rough priority order, and drafted a reply once someone decided a message needed one. None of that came for free. The model of that era couldn't just be told "write a good reply" and left to work out what good meant. It had to be shown: fed a stack of hand-picked example replies, good ones and bad ones, for every kind of message, before it produced anything usable. A model available today, smaller and cheaper than what counted as cutting-edge back then, does the same job with none of that scaffolding. It just knows what a good reply looks like.

That's not really true anymore. For a widening list of jobs, the honest answer to "can an AI do this" is now yes, or close enough to yes that it's worth trying. Which is a strange position to be in, because the thing that used to stop businesses from putting AI on real work isn't the reason most of them still aren't.

Here's the actual reason. Every business runs on a version of "how we do this" that's never been written down, because it's never had to be. When you hire a person, they don't get the whole job explained on day one. They watch someone else do it, ask questions when they're stuck, get corrected when they get it wrong, and slowly absorb the parts nobody ever said out loud: the exceptions, the judgment calls, the "we don't actually do it exactly like the manual says." That's worked for as long as businesses have hired people, because a person can infer most of a role from context and a few weeks of exposure.

Picture a junior account manager six months into a client-facing role. They know which clients want a call before a big email lands, which invoices always get disputed. None of that lives in a document anywhere. It's assembled from watching, asking, and getting corrected. Now picture handing that same job, unexplained, to something that has never sat in a single meeting.

An AI employee can't pick things up by osmosis. It doesn't sit in on a meeting and absorb the unwritten rule about which clients get the fast turnaround. If nobody has said what the job actually is, in enough detail for someone with zero context to do it correctly, an AI stepping into that role isn't going to guess its way to competence. It's going to guess its way to a mess, confidently.

We've watched this happen inside our own work, not just a client's. Building Magus OpenSecMCP, an engineering session was asked to write unit tests for the part of the system that lets a flagged connection earn its way back to trusted after enough clean responses. It wrote correct tests. They passed. What nobody had specified precisely enough was what a "clean" response actually looks like when it comes from a real server rather than a hand-picked example, and the tests fed it exactly that hand-picked shape, one no real response could ever produce. The mechanism was proven correct against an input it would never actually see, and broken against every input it would. Nothing about the work was careless. The instruction just wasn't specific enough to catch what it needed to catch.

So the bottleneck was never really capability. It moved, and most businesses haven't noticed, because "can the AI do this" and "has anyone ever said what this actually is" sound like the same question until you try to answer the second one and realize almost nobody can.

That's not a knock on any specific business. Nobody's ever needed to answer it before. The next piece in this series is about what it looks like when a business is stuck one step short of answering it: using AI constantly, and still not getting the return that should come with it.