I use AI heavily in my own work. I've got agents helping with research, writing, note synthesis, prospecting, coding, and document drafting. My best guess is that I'm at least three times more efficient than I'd be without it.
And almost none of those automations run unattended. None of the ones that produce something a client sees run unattended at all. The only workflows I let run with little oversight are internal ones where I can absorb a margin of error, and it turns out there aren't many of those.
So the time savings are real, but the work didn't disappear. It changed shape.
From doing the task to owning the system
Dan Shipper has made a version of this point, calling automation a lie in the sense that every automation needs a person on top of it making sure it's still working. The spin I'd add is about what that person is actually doing.
Automation doesn't remove work so much as convert execution work into systems ownership work.
Before, the work was writing the first draft, reviewing the pile of documents, synthesizing the notes, updating the tracker. After automation, a lot of that gets done quickly by a model, but somebody still has to define the workflow, give the model the right context, check the output, notice what went wrong, update the instructions, decide whether an edge case is worth baking in, and keep the whole thing pointed in the right direction as the business changes.
That's more than "human in the loop," which makes the person sound like a light reviewer at the end. For most useful automations, that person is also managing the information environment, the memory, and the standard the output gets held to. That's a lot!
Managing an AI isn't quite like managing a person
Comparing this systems management work to people management is fair, but it breaks in two places.
Context doesn't arrive on its own. A person absorbs company context all day long: from the meetings you're not in, from the all-hands, from a Slack channel they wander through, from the tone of a colleague in a room. None of that reaches a model on its own. You can connect it to your systems, sure, but access isn't the same as knowing what matters. Nobody's having hallway conversations with your automation, and it has no way to know which throwaway comment in a meeting will matter three weeks from now. So you have to build its information environment deliberately: what it reads, what it ignores, which examples matter, what belongs in a reusable instruction versus a one-off prompt, and which source it should trust when two of them disagree.
Improvement is a decision, not a default. A person will usually remember the feedback you gave them last month. A model has memory features and reusable skills, which help but don't close the gap. When it gets something wrong, you choose what to do: fix the output by hand, ask it again, rewrite the instruction, add an example, build a test, or decide the whole thing is too brittle and start over. That choice is itself work, and which answer is right depends entirely on the situation.
A person can be wrong in a way you understand, because chances are you were in their seat not that long ago. A model is often wrong in a way that feels alien, which makes diagnosing it slower even when the fix is quick.
Most automations settle at eighty percent
The pattern we see is that an automation gets most of the way there and a person finishes the rest by hand.
Sometimes that's the right trade! Getting from 80% to something close to 100% dependable can take much more effort than the first 80% did, because what's left is all edge cases, judgment calls, awkward integrations, and process-specific exceptions.
The test we'd apply isn't how good the automation is. It's how many people depend on it and what a mistake costs. A monthly report that one person cleans up in ten minutes can live at 80% for years. A daily workflow five people rely on deserves the durable fix, and getting there is a project rather than an afternoon.
Which jobs are actually impacted
The shape of the job matters more here than the capability of the tools.
My own work has no single activity that dominates the week. Product strategy, research synthesis, proposal writing, a bit of analysis, knowledge management, prototyping. AI helps with all of it, and each workflow is a little different, so getting meaningfully faster means a portfolio of small automations plus the work of orchestrating them together. That's a lot of ownership work for the gain.
Contrast that with a role where one activity is most of the job. Accounts receivable is the easy example: if a large share of somebody's week is matching invoices to payments, one strong automation there could change the job. Not trivial, since every customer has quirks, but at least the surface area is concentrated.
Which is why "AI can automate forty percent of this job" tells you almost nothing about what happens to the job. You also need to know how many different tasks that job contains, how often each one repeats, how much error the workflow tolerates, and who owns the automation once it exists.
Not everyone should become an automation builder
There's a version of the future in the industry conversation where everybody builds their own small pieces of software. Some of that is already happening.
But owning an automation asks for a fairly specific mix of talents: noticing which parts of a workflow are worth automating, translating messy human process into instructions, knowing enough about the tool to tell what's easy from what's fragile, testing the output, and being interested in the process rather than only the result.
That's a personality more than a skill set, and it belongs to the people we've called "tinkerers" elsewhere: the ones who enjoy wiring things together and poking at a system until it works. They exist in companies of any industry, and they're usually a small minority. Most people would rather the work just got easier so they could move on, which is a reasonable preference and not a failure of AI literacy.
At one company I worked with, the support team got a lot of leverage out of internal tools they'd built themselves. This was pre-LLM, so the tools were more conventional. But, it worked because one person was effectively dedicated to building and maintaining them, alongside helping run the support function. In other words, not everyone became a builder, one person specialized in helping the others.
That's comparative advantage applied to AI adoption. Being excellent at support, or accounting, or sales ops doesn't mean somebody should also become good at building and maintaining systems.
The question to ask instead
If you're rolling AI out in your company, the useful question isn't what can be automated. It's who owns each automation once it exists. The candidates:
- The person doing the job, if they're a tinkerer and the workflow sits close to their own expertise. Cheapest, but it becomes much tougher as soon as more than a couple of people depend on the output.
- A team-level operations person, which is the model that seems to hold up best when we look across companies.
- A shared function, whether that's IT, an enablement lead, or an outside partner. Good when several teams need the same thing, slow when the workflow changes often.
What we'd be wary of is assuming the ownership work can just be sprinkled thinly across everyone. That might carry the first wave of personal productivity gains. It probably won't carry the workflows a company eventually wants to depend on, and it's one of the reasons companies stall where they do on the adoption ladder.
But that's for the near-future; what about how you can get started now? A good starting point is to find the people who already enjoy this kind of systems work and give them some room to explore, then pick the handful of workflows where getting from 80% closer to 100% is worth the investment, and assign a name to each one. Which name, and at what level of seniority, is the subject of the org chart piece.
If you'd like a helping hand thinking that through, send us a note, we're happy to chat.