A founder running a small services business walked me through something his team had built. Hand Claude a spreadsheet of transactions and it categorizes them and spots any errors. It gets about 95% of them right on its own, flagging whatever it isn't sure about. Useful, and clearly saves his team hours of manual checking.
His reaction wasn't excitement, though. It was closer to: I don't know how to string this together with everything else to make it a full workflow.
Some version of that came up in four other conversations that same week. Nobody was asking whether AI is capable enough. That question is settled for them, and they've moved on to a harder one.
The bin of Legos vs the instructions booklet
Between the AI labs and everyone building on top of them, your company has been handed a giant bin of Lego bricks: the models themselves, connectors into your email and file storage and CRM, reusable skills, agent frameworks, and more. The bricks are excellent, they're mostly cheap, and your competitors are shopping from the same bin.
The one thing missing from the bin is the instruction booklet, but that isn't a simple thing to solve. A general-purpose booklet can't really exist, because the one for your company is specific to your workflows, your data, your exceptions, and your people. Somebody has to write it, which requires a combination of workflow discovery and a bit of architecture: decisions about how the pieces of your internal AI setup fit together.
This is why a founder can feel stuck while agreeing that the technology is good enough. The bricks being capable was never the whole story.
Assembly capacity is the budget you're actually allocating
Here's the part that follows from that, and it's the part we'd most want an executive to take away.
If everyone has the same bricks, then the thing that's actually scarce at your company isn't money, model access, or licenses. It's the number of people who can turn bricks into a workflow your team will run, and at most companies that number seems to be around 10-20% of the workforce (this is based on our anecdata; this actually does not seem to vary across industries that much).
So every decision below is really the same decision: where do those few people's hours go? And the most common way we see that budget wasted is on polishing automations that were already working fine enough.
Spend it on breadth, not polish
That transaction workflow I mentioned at the beginning is neither a demo nor a prototype; it's a tool that takes hours off somebody's week starting now. It may not spot every single error perfectly, but it spotlights the items that a human needs to pay attention to. A human is in the loop and does their part, then the rest of the day carries on.
It's not 100% of the way there. But that's not an insult; it's worth remembering how many companies already lean on software nobody would call production-grade. The elaborate spreadsheet holding up half a business is a decades-old tradition, and these assembled workflows are just the newest member of that family.
It's worth remembering the 80/20 principle here: 20% of the effort can get you 80% of the way there. But getting from 80% to 100% takes 80% of the effort! Which means that pushing one working automation from ninety-five to ninety-nine costs roughly what four more ninety-five percent automations would have cost you. For most companies, four more is the better trade.
The exception is when one or more of these situations are in play:
- The task demands high accuracy and a mistake is expensive
- You want to hand it to a teammate who didn't build it
- It needs to run reliably without the builder babysitting it
- The volume grows past what casual supervision can cover
Short of one of those, leave it alone and point your assembler at the next workflow.
In the case of the business owner in the introduction of this article, it was worth it to him to go beyond the 80%. For him, he needed to transform the overall workflow - not just the step involving these transactions - that the entire team worked on. It was just one piece of a larger goal of a more holistic automation, and so it made sense to proceed beyond the 80%.
Why polish costs what it costs
It's worth being concrete about why that last 20% is so expensive, because it isn't a matter of writing a longer prompt.
When a workflow needs to be shared, reliable, and trusted beyond its builder, something shifts that's easy to miss: what you've built is internally-developed software. To emphasize the point: a Skill in Claude Chat or Cowork is software. And once you've got software, the rest of the software development life-cycle becomes a concern:
- How do you version it when somebody improves it?
- How do you tell whether a change made it better or worse?
- How do you check its accuracy on an ongoing basis rather than by vibes?
None of that is a new problem, and software teams have had answers for decades. What's new is who is hitting the questions: people who aren't software engineers, who never signed up to build software, and who got here by wiring bricks together in plain English.
That's the real bill for hardening. Not the extra prompt engineering, but a set of practices your assembler probably doesn't have and would have to learn on your time.
On the adoption ladder, DIY assembly gets a company solidly to L2 and sometimes L3, which covers a lot of valuable ground. It's the levels past that, where workflows become shared and load-bearing, that start asking for the software discipline.
So, in what order?
Putting it together, if you're deciding where the money and the attention should go:
- Let the tinkering run first. Find whoever's already inclined to wire things together, clear them some room, and see how far the ninety-five percent versions carry you. This is cheap, and it teaches you two things: which workflows matter enough to invest in, and where the real ceilings are for your business rather than where you guessed they'd be.
- Wait for a workflow to prove itself. When one hits an actual ceiling on accuracy, sharing, or reliability, you'll know, because somebody will be complaining about a specific thing rather than about AI in general.
- Then buy the hardening, not the capability. At that point the work has shifted from tinkering into something closer to software development, with discovery and change management wrapped around it, and that's when it makes sense to bring in help.
Companies that buy the platform first, before the tinkering, tend to end up with capable infrastructure and nothing proven to run on it, and the people who would have found the workflows worth building are by then watching a procurement process.
Where this leaves you
Back to that founder for a second. What he needed wasn't a better model, and it wasn't a more polished version of the tool he already had. He needed somebody whose actual job was stringing the pieces together, and nobody at his company had that job.
That's the gap worth staffing, and a lot of that first stretch you can do yourself: find the person already assembling things, clear their calendar a bit, and see how far they get. There are more than enough building blocks available these days; the booklet is the work.
If you'd like a helping hand writing your company's instruction booklet, send us a note, we're happy to chat.