Writing | Rod Amora

The Two AI Skills I Would Put First: Imagination and Creativity

Fri, 02 Oct 2026 13:00:00 GMT

In one of my companies, our customer success team would randomly call clients to find out whether there were problems. We had thousands of client interactions a month, and the volume stood in the way of having someone review meetings for signs of trouble.

That is the kind of business problem I have in mind when I say the two AI skills I would put first right now are imagination and creativity.

By imagination, I mean seeing something your business could do that you hadn't considered possible. Creativity is connecting the information, the tools and the people who can help you try it.

We started by asking how to prevent churn

We started with a question: how do we prevent churn? We wanted to help our customer success team identify problems early, and looking for signs in client meetings was the obvious choice.

The team was already reaching out to clients, but the volume made it difficult to review meetings for signs of trouble too. So we looked at whether AI could help identify meetings that needed attention.

A client complaining, asking for the same information repeatedly, pointing out a missing report or something that hadn't been delivered, those were things we wanted to notice. So was a bad or upset tone in the conversation.

We used AI to classify the meetings for signs like those. If it flagged a meeting as concerning, we would send the transcript to the customer support team, and they would handle it from there.

The transcript gave them the conversation to work with. The AI's classification wasn't the response to the client, it was a way to bring a meeting to the attention of people who could do something about it.

I am describing how we approached the problem, not claiming a measured reduction in churn from that system.

AI classification gave us a way to test whether we could help the team find problems in that volume of conversations. The support team still handled what needed to happen with the client.

I've tested other things too, lead filtering and classification, monitoring messages to make suggestions. These are the kinds of things I mean when I talk about creativity in a business, looking at work we already do and finding another way to help with a problem in it.

Imagine what would solve the problem before choosing a tool

If you don't think of yourself as creative, I would start with the problems you already understand. You don't need an unusual idea to begin looking at why work gets stuck or why clients leave.

Look at where you spend money with little return, the work people dislike doing, what clients keep asking for and what they don't want anymore. There is plenty to think about inside an existing business before you go looking for an AI use case somewhere else.

Then spend time understanding why the problem happens. A client repeatedly asking for a report gives you somewhere to look, but you still need to find out whether the report wasn't delivered, wasn't clear or didn't answer what they needed.

Those are different problems, and I would want to understand which one I was trying to solve before asking someone to build anything.

From there, imagine what the best solution would look like in a perfect world. Leave the technology out of it for a moment and think about what you would want to happen for the client and the people doing the work.

And please don't turn this into telling your team they need to be more creative with AI while leaving them to guess what matters. They can help identify problems and suggest solutions, but you still need to decide which problems deserve the company's attention and give people room to work on them.

Learn enough about AI to see what you could try

The meeting example is why I care about learning what AI can do beyond writing an answer in a chat window. Once you understand that it can look for signs of trouble in a conversation, you can consider how that might help a team with more conversations than someone can review.

That doesn't tell you whether it will recognize the right problems or produce something the team can use. It gives you a possibility worth testing, and the more I understand about what agents can do, the more of those possibilities I can imagine.

We are still figuring out how to apply this technology in our businesses. I would keep learning and trying things rather than assume a fixed list of tasks covers what will be useful next.

That is why I think owners need to experiment with AI personally. In Don't Be a Detached CEO, I explain why that understanding matters even when someone else handles the technical work.

You can research what other people are doing, try things you want to understand, and pay attention to what the tool handles and what still needs your help. You are building enough familiarity to connect a business problem with something worth investigating.

Not every personal experiment needs a business case. Learning what a tool does and deciding to put it into the company's work are different decisions, and you need room for the first before you can make the second well.

Now, there are useful skills we can teach. The thread that prompted this article includes prompting, fact-checking, working with your documents and knowing when not to use AI. I agree those are worth learning.

We can teach methods and safeguards too. What no fixed checklist can do is tell you which useful possibilities to pursue in your particular business, because that requires understanding your problems and testing ideas against the work.

And when AI does free time in people's calendars, I would make room for some of that exploration. Decide which problems you want people to investigate rather than assuming a faster way to do their existing work will lead them there on its own.

You can get help turning the idea into something that works

You don't have to do all of the creative work yourself either. You can bring the problem and the possibilities you've imagined to more technical people and ask them to help you create a solution.

Give them enough to understand what you are trying to change, why you think the problem happens and what a better result would look like. That gives them something to work through with you, rather than a request to put AI somewhere in the business.

They can help you understand what is possible, suggest an approach you hadn't considered and work out how to connect the tools and information. You still need the people who do the work involved, because they are the ones who can tell you whether what comes back helps.

For an experiment like ours, I would ask the team to look at the flagged transcripts and tell us whether they contain problems they can act on. I would also want them to point out concerning meetings the system missed.

That feedback gives you something specific to change. You can investigate why a complaint was missed or why a meeting was flagged when the team didn't see a problem, then try again.

And flagging the right meetings still doesn't tell you whether fewer clients are leaving. Someone has to act on the information, and you need to look at the business outcome you wanted to improve before calling the experiment a success.

For the problem you choose, bring the outcome you've imagined to people who understand the work and the technology. Agree what a trial needs to show, then ask the people using the result whether it helped them do what you intended.

Use what you learn to decide whether to improve the approach, try another one or leave it alone.

Don't Be a Detached CEO

Wed, 30 Sep 2026 13:00:00 GMT

When you decide to build something with AI, you are committing more than money. You need time from the developers, time from the people who will test it, training, coordination, and room for all of that alongside the work the company already has to do.

And if you build the wrong thing, the cost can follow you into the next attempt. It is demoralizing to put that much effort into something that doesn't work, and from my perspective, the risk to future efforts can cost more than the money you spent.

That is why I think business owners need to spend time exploring AI themselves. You need to understand what the technology can do and how it connects to your business strategy, even when someone else handles the technical work.

You can trust your technical team and still take responsibility for learning enough to have that conversation. It doesn't require becoming an engineer or being the person who solves everyone's problems.

I didn't know where to start either

The scariest question for me when I started with AI was where to begin. I was looking at it as an owner, trying to understand where it fit in my own business, knowing what a wrong decision could cost.

In one of my companies, we started with the basics, what a language model was and what it could do. We tried putting it into all kinds of work, and most of those early ideas or projects failed, but we kept exploring.

For me, a big change came when AI started helping with things I hated doing manually, copying and pasting content from different places, organizing data and files, configuring spreadsheets and creating document templates.

I also used it to test workflows and configurations, and to read logs and data to help identify bugs and problems. Those were things I understood from doing the work myself, so I could recognize what the help meant.

Working with an assistant on my computer made the possibilities much clearer. I created a folder of text files with information that mattered to me, and worked with the assistant to gather information, test tools and draft documents.

There is a difference between reading an answer about how to do something and watching a tool work with your files. Seeing that in my own work gave me more things to ask about.

That is my experience, not a promise that your company should follow the same path or build the same things. Start with something you recognize and develop your own understanding from there.

AI leadership: learn enough to join the conversation

When I say understand AI, I mean knowing what the tools can do, seeing how other businesses use those capabilities and learning the common terms well enough to follow a conversation about them.

That can take you a long way without going deep into how the software is built. You can ask what AI can help with in 3D modeling or video editing, or what it means for an assistant to use a computer, without deciding to build any of those things yourself.

If your experience stops at asking a chatbot to write text, go and look at work beyond that, then ask what the tool actually did and what the person still had to do.

And when you look at another business using AI, pay attention to the work around the tool. What were they trying to change, what information did they give it, and how did people use what came back? Their example can give you something to consider without becoming a plan you should copy.

The language matters too. If someone uses a term you don't understand, ask them to explain it through the work they are proposing.

If they say an assistant needs access to a system, for example, ask whether that means reading information from it or being able to change something inside it.

You don't need to pretend to know the answer before asking. Getting comfortable with those questions is part of learning, and I would rather have that conversation than agree to something I don't understand.

A capable technical team can advise you on what is possible and how to build it. Your understanding helps you connect that advice to what you want the business to do, instead of leaving the entire conversation to the people who know the tools.

You can explore without a company project

But how do you start learning when you don't yet know what would be useful? You need room to try things before every idea becomes a proposal for the company.

If you are going to commit developers and ask people to change how they work, you need a reason for that investment. Personal exploration has a different purpose, you are finding out what the technology does so you can think about it for yourself.

You can be curious about whether an assistant can organize some information without making a plan to change how the whole team organizes theirs.

If every experiment has to come with a business case, you are asking yourself to explain the value of a tool you haven't had the chance to understand yet. That puts the decision ahead of the learning that could help you make it.

Some of what you try will suggest a business use, and some won't. You don't owe the company a new system every time you learn something.

Try something you want to understand

I would start with a question or a piece of material you know well, something where you can look at the result and judge whether the tool did what you asked.

For example, take copies of non-sensitive notes you are allowed to share and ask an assistant to help organize them into a document you could use.

If the tool can work with files, keep the experiment in its own folder. If you're using a chat tool without that access, paste the text and work with the answer there.

Keep its access limited to what you are trying. Anthropic's safety guidance recommends a dedicated folder and care with sensitive information, which is a sensible boundary for this kind of exploration.

Then look at what comes back and keep working with it. If something important is missing, explain what you needed and try again.

Notice what you had to tell it, what it handled and where it went wrong, because that is the experience you are there to get.

When you see another business using AI in a way you hadn't considered, bring that question back to your own exploration. Ask how that work is done, get the unfamiliar terms explained and try the part you can reasonably test yourself.

You can also ask the assistant what else it could help you do with the material you've been working on. Treat those suggestions as things to investigate, not proof that it can do everything it describes.

A useful experiment doesn't commit your company

Something working for you in an experiment doesn't mean it is ready for other people to rely on in their daily work. Deciding what to put into a well-designed workflow for the company is a separate decision.

You may learn that the tool needs information you can't give it, or that the work still takes more help than you expected. You can leave that idea alone and keep exploring something else, without asking the company to pay for a build just because you were interested in it.

How I Built AI That Could Work Across My Company

Mon, 28 Sep 2026 13:00:00 GMT

In one of my companies, some AI-produced work went straight to clients with very little checking. People were under pressure to deliver on time, then came the errors and complaints, and management had to deal with problems we hadn't caught before the work went out.

We had people using different tools, each figuring out how to use AI for themselves. I built a shared agent system so they could work with common instructions and the right client history, within rules about what each person and their agent could see or change.

I worked through it in two layers, the building blocks an agent needs to do useful work, and the business layer that organizes it around projects, people and permissions. Most of my time and effort went into those permissions.

I couldn't find a suitable system I could buy and afford. Building one was complicated, but understanding the pieces helped me see what we needed, and you can use that understanding whether you buy or build AI agents for your business.

Everyone was figuring it out separately

The differences were easy to see in the files. Some reports were short and to the point, others were full of AI slop, and presentations came back in different voices, templates and colors.

And there was no easy way to pass along what worked. When someone found a better way to use an agent, the rest of the team didn't automatically benefit.

We were missing company-wide rules about what could and could not be done, feedback about what was working, and visibility into how people were using AI. From my side, that made it impossible to understand the impact on the business and where we should put more time and effort.

Individual AI use can be useful, of course, and people can do a lot with their own tools. But we had left them to solve too much separately, then expected their work to come together as the work of one company.

The pressure to deliver was still there, and we couldn't rely on someone catching every problem before the client saw it. Leaving the team to figure out AI use on their own was our decision, so the common rules and the way work got checked were our responsibility too.

I think of that as single-player AI, each person working with their own agent and their own context. The work we needed to do was multiplayer, several people contributing to the same project and needing to understand what the others had done.

I split the problem into two layers

The first layer is the agent itself, what I call its primitives, basically the building blocks it needs to work. The business layer determines who can use those building blocks and for which work.

Take a client report. Someone asks the agent to analyze the data and explain what it means for that client. It needs the source files and somewhere to save the report, so another person can open the work and check it.

The files won't explain everything. The agent also needs memory, useful information kept from earlier work, so it can account for what the client asked for and what has happened since, instead of making the person explain the project again.

And it needs a skill, the instructions for how we do and check that kind of analysis, including how to prepare the report.

To carry out that work, I also have to choose the model and how much reasoning effort it should spend. I want the report done properly without paying for more than it needs.

To produce the file, the agent needs tools that let it act, and integrations, connections to the systems holding the material. For us, those include Google services and WhatsApp, because that is where parts of the client conversation and work happen.

Now take that same report and ask which client's files the agent should be able to read, whose instructions apply and who can approve a change.

That is the business layer. I put the work into projects and workspaces, with users and permissions controlling access. The project carries the particular job, and a workspace lets a team or unit share the work that belongs together.

The report might use a company-wide template and information from one client's project. The agent needs access to both, without gaining access to another client's records just because it can read the same kind of file.

The next person needs the project history too

Imagine a client project with two junior consultants and a senior overseeing the work. One junior uses an agent to do research and prepare a report, while the other analyzes data and builds a spreadsheet.

Both need to know what the client wants, what was agreed, what has happened so far and what changed in the latest conversation. The senior needs to inspect the work and understand what they used to produce it.

If that history stays inside one person's chats or local files, the next person has to reconstruct it. Even when the files are shared, they still need the explanation of why the work is being done and what the client expects now.

That is why we built the system around shared project history, from the first client interaction with sales to the latest WhatsApp message. Meeting transcripts, notes and conversations belong with the work, where the agents helping that team can reach them within the project's access rules.

Our system also processes interactions in the background to keep useful information for later. There is an overnight process that goes through the day's interactions and builds memory at the personal, project and company levels, rather than treating everything it learns as something everyone should see.

That gives the next interaction more to work with, but finding the history doesn't settle what every record means. If a client asks for a different deadline, the agent still needs to distinguish that request from an approved change.

A person remains responsible for that decision, and the shared history needs to help them make it.

Data analysis made the permission problem very clear. In our franchise structure, an agent working for one unit cannot expose another unit's financial data, sales or campaign performance.

The same separation applies to instructions. Some franchisor rules aren't for franchisees, and rules intended for our internal teams must not get mixed into work for clients. At the same time, a franchisee's agent needs the brand guidance and its own unit's rules to be useful.

So we couldn't put everything in a shared space and tell the agent to use what seemed relevant. A company-wide presentation template and a unit's financial records need different access rules, even when the agent uses both in one presentation.

That was where most of my time and effort went, building controls to keep people from seeing or changing things they weren't allowed to, even if they tried to trick the system into giving them access.

We had to build those rules into the software around the user and where the work was happening. A sentence asking the agent to keep information confidential wouldn't settle which files it could open or which changes the system would allow.

And restricting everything wasn't an answer either. Too little access leaves you with an agent that can't help with the actual work, while too much creates ways to leak information or damage something. We had to decide who could use each part and what they were allowed to do with it.

And I would separate permission to read from permission to act. Letting an agent read a client conversation to help prepare a response is a different decision from letting it send that response on the company's behalf.

As a manager, I also need to inspect what people and agents are doing, understand which uses are helpful and check whether the rules are being followed. That needs to be part of the system we ask for.

Counting conversations alone wouldn't tell me whether the company was doing better work. I'd still want to follow what came out of those conversations and what it took to get something we could use.

We stopped teaching the company rules in every chat

The clearest change came from a set of company-wide skills that taught the agent how we work, our voice and tone, brand colors, presentation templates, data analysis and reports.

Before that, we had 100 presentations in 100 different styles and voices, with variable quality and low accuracy. Afterward, we had a consistent voice, style and branding, and much more reliable quality.

People also worked faster and typed fewer instructions, because the agent had the company guidance and client history available. They could ask it to work on the project without explaining everything from the sales conversation onward.

That is the improvement I saw in our work. It doesn't mean a report no longer needs checking, and consistent branding doesn't tell you whether the analysis is right.

And when we update a shared skill, the people it is shared with get the new version, whether that is one team or the wider company.

So when the way we prepare reports changes, we can update the instructions the team uses instead of leaving each person to maintain a separate version. That gives us somewhere to put what we learn from the work, where the next person can benefit from it too.

Use the two layers to decide what to buy or build

I built because I couldn't find a system I could purchase and afford that combined the shared files, memory and permissions we needed for people to work together.

That led me to build a system that checked a lot of our boxes. It doesn't mean you need to copy our franchise structure or build all the same things, but you do need to be able to describe what working across your company requires.

I would take a recurring piece of work that passes between people, such as a client report, and sit down with the people who prepare and approve it.

Write down what the agent needs to do the job, the files, the relevant history, the instructions, the actions it needs to take and the systems it needs to reach. Include how someone will check the result.

Then work through the business layer for that same report. Which project does it belong to, who works on it, which company instructions apply, and who can read, change or approve the work?

Use that description to ask for a demonstration. Have another authorized teammate continue the job with the relevant history and instructions, and check that someone outside the permitted group cannot get that same access. That is a starting check, not a complete security review.

If a tool you can buy does the job, buying it is a valid answer. If nothing fits, you have a much clearer description of what needs building, instead of a request for an agent that somehow understands the whole company.

Either way, someone needs to own the instructions and access rules as the work changes. Whoever buys or builds the system needs people in the company who can make those decisions.

I'm also working toward an open-source release because I want this kind of AI to be more accessible to small businesses.

The agent still doesn't manage the projects by itself

The part we are still figuring out is management, having the agent proactively coordinate the next actions, tasks, communication and much of the administrative work around a project.

Helping someone prepare a report with shared instructions and history is useful today. Reliably keeping the project moving, deciding the next action and coordinating the people involved is work we are still exploring, designing and testing.

AI Can Do the Junior's Work. First, You Have to Check Everything.

Fri, 25 Sep 2026 13:00:00 GMT

AI is already doing first passes that I would otherwise need a person to do, researching competitors, gathering industry information and stats, summarizing meetings, drafting reports from client data and turning notes into documents. But when we started putting that work through AI, we checked every output.

So the draft could arrive faster while the person responsible for it had more checking to do. That was part of getting the system to work, and the checking came down as we fixed mistakes and added safeguards, not because we decided to trust it more.

I ran the AI transition in my own company, and this is a part of the work I would budget for before deciding that AI has replaced a junior. AI can take a junior's first pass before you've built the checks that make it dependable, but not before that.

The obvious read is that if AI can write the report, you no longer need the person who wrote it. I understand that calculation, but somebody still has to decide whether the report is right, and you need to know what that takes before you change the role.

At first, you check everything

And that review had to fit around work we were already responsible for. Sometimes getting back to a client had to wait, or onboarding a new client, or working with colleagues to get a project approved or finished.

Maintenance and system upkeep still needed doing too. Getting the first pass done faster did not immediately give us that time back, because we were still spending time making sure we could use what came out.

Take a report drafted from client data as an example. The writing can be clear while a number is wrong, or a sentence can cite a source that doesn't support what the report says, so somebody has to go back to the material it came from before sending it.

That checking is not your team resisting AI. If they're responsible for the answer, checking uncertain work is the responsible thing to do, and telling them to hurry doesn't make the answer safer.

You have to make room for the failed first tries and for someone to fix what caused them. Otherwise you have given the team a new production method and left them to fit the extra review around the work they already owe you.

The question I would ask at that point is, what changes after we catch a mistake? If the answer is only that the manager fixes the report, the next report still needs the same protection.

The failures become the safeguards

What we did was use the problems to change how the work ran. Sometimes we improved the prompt, the instructions we gave the AI, sometimes we added a safeguard or a separate check to catch the problem before the output reached us.

And sometimes we stopped asking the language model to do that part of the work. For data analysis, we use code that follows fixed rules instead of asking the model to think through the data and generate an answer.

That is a change in the work, not just another way of saying “be more accurate.” In a report, for example, adding up a column and explaining what the total means are different jobs, and there is no reason to give both to the same tool.

The person checking the output needs a way to get the failure back to whoever can change the system. Then the next run needs to show whether the change helped, rather than leaving the same person to correct the same kind of mistake again.

In my experience, once we fix the mistakes, usually in a month or two we start to get solid results. Review time comes down as the failure rate falls and the safeguards improve.

That is the sequence I've seen, not a deadline I can promise for any company. Waiting for two months without doing that work is not the same thing.

I've written about how review changes as an AI workflow improves, but what matters for hiring is that the amount of human checking needed at the beginning does not have to be the amount needed later. So neither the first fast draft nor the first slow review tells you what the finished job will cost.

Give each part the right kind of checker

We use several methods together, because checking whether a report follows instructions is different from checking whether its claims match the sources.

We give the AI examples of how the output should look, and we use checklists for what needs to be there. We also use separate AI checks for particular items, including whether the source supports what the report says.

We keep a list of common errors and pitfalls for the checker to look for, wrong data, invented information and problems we've already encountered. One AI agent does the work and another checks it, rather than leaving the whole job with the same agent.

In our work, that has been safer than having one agent do everything. It does not mean a second AI's approval is proof that the answer is right, which is why we checked outputs ourselves while improving those checks.

So, in the report example, code can handle the calculation, AI can write the explanation, and a separate check can compare the explanation with the source. A person still owns a decision the checks don't settle, such as whether the information is enough to recommend a change to the client.

That's different from a summary that only needs to preserve what was said in a meeting. Both produce text, but a recommendation asks you to accept a judgment, not just confirm that the notes were carried over correctly.

The research gives a reason to keep that distinction. In a study of 758 BCG consultants using GPT-4, published in 2026, researchers tested 18 tasks within what the AI could handle, and AI users completed 12.2% more tasks and produced higher-quality work than the control group. They also took 25.1% less time on average to reach the final task.

So yes, the case for a faster first pass is real for the work they tested. You don't need to dismiss that result to take checking seriously.

But on a separate brand-strategy task outside that boundary, the same study found 84.5% correct answers without AI, compared with 70.6% for GPT-4 alone and 60.0% for GPT-4 plus guidance on prompting. Those are results for one task, not a general accuracy score for AI.

The study didn't measure senior review hours or small-business staffing. What it gives us is a warning against treating a good result on one task as permission to hand over the next one.

For your business, I would ask: can we check this result without having to do the whole job again? If you can compare a summary with its source, you have something to build checks around, but if accepting a recommendation requires an experienced person to rebuild the reasoning, that person's work belongs in the cost.

What happens to entry-level jobs when AI takes the first pass?

After we fix the workflow, what I see is output that is better than a junior would be able to do by himself, and a lot faster also. That's what I've seen in our work, not a benchmark for every task or every junior.

And notice what is being compared. On one side is a junior working alone, on the other is a system with instructions, examples, source checks and known errors built into it by people who understand the work.

That is a useful result, but it doesn't compare the system with a junior using it. And in the work I've seen, the junior still has things to do once AI can produce the first pass.

Their work moves toward doing and reaching what the AI can't, connecting people and fetching information that isn't in the system. Producing a report from the information available is one task, getting the missing information from someone is another.

I've also seen that work include conveying feedback from upper management on delicate matters. Passing that feedback along is different from making the decision, so I wouldn't treat the change as automatically giving the junior the manager's authority.

So I would look at the work left around the draft before deciding what happens to the person who used to write it.

What I've seen gives me a reason to change the junior's work, not a rule that every junior role should take this shape. Someone still needs to handle the exceptions and own the client decisions.

Count the cost before changing the role

Before cutting a junior role or delaying a hire because of AI, I would take one recurring task from that role and write down what a correct result must contain. A report draft is a useful place to start if you already know what the report is for and have someone who can judge it.

For that report, name the source data, what must be included and which conclusions need a person's decision. “Looks good” is not enough to tell the person building the checks what to fix.

Then record how the task works now, including the review it already needs. Juniors need checking too, so comparing a checked AI draft with an imaginary human draft that never needs correction would give you the wrong answer.

Run the AI version with full review, and name who checks the result and who can change the system when it fails. Give them time to work together, including deciding what other work will wait while they do it, rather than expecting the review and improvements to fit into hours already committed.

Count production time and review time separately, and record whose time it is. A faster draft is not a saving if your senior has to rebuild it, while a short check against a source can still leave you with a useful gain.

Keep the time spent improving the system visible too. Building a check once is different from correcting a report every week, but both use someone's working hours and both need to be paid for.

Reduce human review where repeated results and working safeguards justify it, while keeping the judgment and exceptions assigned to a person. Please don't shorten the checking just to get the saving you hoped for.

Once the workflow is dependable, look at the remaining work with the manager who owns it. Write down who gets information that isn't in the system, who handles the communication around the task and who can approve a decision the checks don't settle.

Then decide whether the junior can do that work with the AI, what still needs a senior and whether any responsibility has been left without a person to carry it. That's the job you're making a staffing decision about, not just the first draft.

This does not answer the whole hiring question

This approach assumes recurring work, a team and someone with enough knowledge and time to judge the result. If your company cannot say what a correct result looks like, defining that comes before counting on AI to produce it.

There is also the question of where your next experienced people will come from if the work juniors used to learn on disappears. A dependable first pass doesn't settle how you will teach judgment, and that deserves its own staffing decision.

I don't have measured review hours, a documented hiring outcome or a 12-month margin result to give you for this pattern. What I've seen is the early checking, the better production after we improved the system and the work juniors still do around it, not proof that an entire role became unnecessary.

Before you cut a role or delay a hire, count the review on the task you're changing and name who will do the work that remains. If the draft is automated but someone still has to get the missing information from a colleague, put that work in the hiring decision too.

We Couldn't Afford to Review 900 Applications, So We Built an AI Interviewer

Wed, 23 Sep 2026 13:00:00 GMT

One of my companies had almost 900 applications waiting, and we could not afford a bigger team to go through them. We built an AI interview system, the prototype took two weeks, and within ten days of the prototype the queue was empty.

It costs us around $50 a month to run the system. That doesn't include the work to build it, and people still conduct the HR and department interviews, but the running cost was small enough for us to handle work we couldn't get through before.

We were growing quickly at the time, and sales, operations and marketing all needed people. Automating this process was essential for our growth because the delay in hiring was holding up work in the rest of the company.

So the question I would put beside the AI budget is, what happens to your business while that work keeps waiting? For us, the cost decision started there.

We had more applications than we could handle

The other departments were already angry that hiring was taking so long. They needed people to do the work, applications were coming in, and the queue kept getting larger because HR couldn't work through it.

That was demotivating for the team, with the queue growing while the departments waiting for hires needed the process to move faster.

You could look at that and say we needed more people in HR, and yes, we needed more capacity. But bringing new HR employees up to speed was difficult and would take a long time, and expanding the team was more than the department could afford then.

So asking the existing team to try harder wasn't going to solve it. We needed to find a way for them to handle the applications with the time and money we had, and that was our responsibility as owners.

The system we built analyzed applications, pre-screened candidates, conducted interviews and managed the candidate Kanban, basically the board showing where candidates are in the hiring process.

And when HR took over, the human interview was better. The candidate already had more information about the role and had asked some basic questions, while our interviewer knew more about the candidate before they spoke.

So the conversation was more thorough and useful to both sides, rather than simply being a faster way to move someone to the next step.

After the short interview with HR, an approved applicant moved to the department interview much sooner, already knowing more about the position, the work they would need to do and the team.

That's what I mean when I say we hire better and faster, and we received good feedback about the speed of the process. The system ran fine, while people still conducted the HR and department interviews.

The $50 didn't include the build

Those two weeks to build the prototype belong in the cost of the system, even though they don't appear in the monthly running bill. If you're considering something similar, you need to make room for that work before you can depend on the new process.

Someone has to decide what the system should do, set it up for your hiring process and try it with the people who will use what it produces. A low monthly price doesn't tell you how much of that work is included or who will do it.

And HR still needs to interview the candidate and decide whether they should meet the department. That's hiring work, not evidence that someone has to redo the AI's work.

For your budget, keep the build effort and running bill separate, then describe the work people will still do. In our case, that's the HR interview and the department interview, with better-prepared people coming into them.

I don't have a complete dollar cost or a measured payback period to give you for this system. And our two-week prototype is the time this build took, not a timetable I'm promising for yours.

Compare it with the work that stays waiting

We hadn't been paying a larger recruiting team and then stopped, so I can't count its salary as money we saved. What changed was our ability to get through applications and move people toward the departments that needed them.

A project can help your company do needed work without removing an existing expense.

If you already have someone handling the applications well and candidates reach the right interviews on time, you have a different decision to make. You would need to show how the proposed system improves that process enough to justify building or buying it.

In our case, the people waiting for those hires weren't all in HR. Sales, operations and marketing needed staff, so looking only at the recruiting budget would miss why getting through the applications mattered to the company.

That's the comparison I would want you to make in your own business. Name the work that's waiting and what it prevents other people from doing, then compare the realistic ways you could get it done.

In our case, we got through the application queue and improved the interviews that followed. That is the result I'm describing, not a claim that AI should make your final hiring decisions or that every growing company needs to build an interviewer.

Put the whole job in the budget

Before you buy or build, sit down with the person responsible for the waiting work and the person who needs its result. For a hiring process, that means understanding both what HR can handle and what the department needs before it can decide to hire someone.

Then write down which part of the work you want AI to take on and what the person taking over needs to receive. In our case, the human interview went better because both the candidate and the interviewer came into it knowing more.

Put the setup effort beside the monthly running budget, and name who will still make the decisions. If the proposal only tells you the software price, ask who will get it ready for your process and how much time your own team needs to give it.

When you try it, follow the work beyond the AI step. Look at whether candidates reach the human interviews better prepared and sooner, and whether the department gets what it needs to make a decision.

Before committing to the tool, agree with the people on both sides of that handoff what has to improve. That gives you something to judge the system by beyond a smaller queue.

You Bought Automation and Installed a Guess

Mon, 21 Sep 2026 13:00:00 GMT

Why do AI projects fail? Usually, you give a guessing system the wrong kind of job.

Sometimes the job needed the same answer every time, and ordinary software would have done it better. Other times it needed a person to make an exception, protect a relationship, or approve something you couldn't undo. The AI can be useful too, but not when you ask it to do too much at once and can't see where it went wrong.

Start with one small piece of information work, then add more only when it holds up on the real work.

A clean summary can be a damaged record

I saw this in an AI tool we built for our own proposals and reports. It was meant to replace people copying client notes into personal accounts, and it could produce a clean transcript, a written record of the conversation, and a meeting summary much faster than doing the work by hand.

One consultant needed to send information to a client that was missing from the summary, so he had to rewatch the whole meeting.

A week later, the client had questions about something they had discussed and had ideas about, but those details were not in the summary. The consultant had to rewatch the entire meeting again, which wasted a lot of time and delayed the reply. That was not the client experience we wanted.

The problem was that clean wasn't the same as complete. It lost topics from the meeting, important facts and comments, and some hard data, numbers, because it was trying to simplify the transcript and summary.

We didn't blame the consultant or abandon AI. We switched to a higher-quality transcription service, changed the template the agent had to use, and created an eval, an evaluation based on one template, to judge how well the agent would write new summaries. After those changes, the missing details and repeated client questions stopped.

That kind of failure is hard to spot when someone shows you the tool. The page looks shorter, the writing looks smoother, and nobody has to read through the whole conversation again. You only notice the missing number when somebody needs it for the proposal, and by then the person doing the work has to go back through the recording or the notes to find what disappeared.

A summary that leaves out the reason a client made a decision isn't a better summary. It's a shorter record with a hole in it.

The person who goes back to the old way isn't necessarily against using AI. They're trying to get the work out, and if the new way keeps dropping details, going back is safer.

You own the bill. You chose the tool, chose the job, and gave the team a result they had to trust without testing it against the original material.

Buying the tool didn't change the job

The easy explanation is that the team didn't use the tool. They had paid accounts, there was training, somebody showed them how it worked, and the work still looked much like it did before.

That's half right, the team needs the right information, permission to use it, connections to the other software, and a tool that fits the job. But saying the team didn't use the tool skips the decision you made about the work. You left the job, the source material, who approves it and who checks it unchanged, and hoped buying the tool would change the result.

In his February 17, 2026 speech, Federal Reserve Governor Michael Barr said that making AI useful will likely require “fundamental changes in business practices and organization.” He was talking about changing how the company works, training people again, having managers work out better ways to do the job, and paying for trial and error. That's what buying a tool leaves out.

Your team already has client work waiting, payroll to run, support requests to finish, and deadlines that don't move because a new system is learning. When the new way fails, the old one is sitting there, paid for and familiar, so going back gets the work done while hiding what the failed first try cost.

That's why a clean demo, where someone shows you the tool working, doesn't tell you enough. It doesn't prove the tool can keep the details your work needs, follow your approval steps, or produce work someone can use without doing it over.

Sometimes the work goes back to a personal account and happens out of sight, as I wrote in AI Projects Don't Fail at Your Size. They Go Underground.. Sometimes the tool is cancelled. Counting paid accounts won't tell you which happened.

Give AI information work, not the whole responsibility

Some work needs software that follows fixed rules, giving the same answer or taking the same action each time you give it the same information. A rule, formula, template, or ordinary tool that repeats the steps for you is usually the better fit. Doing a calculation, checking that a form has the required details, naming a file, or moving a record from one known place to another doesn't get better just because AI can describe it in a friendly sentence.

A user in an accounting discussion compared Claude, an AI tool, with VBA macros, small programs that repeat set steps: “Claude will not repeat a process exactly the same way everytime. VBA macros, however, will.” That's one user's experience, not a study comparing the two. But it asks the right question, does this job benefit from different answers, or does it need the same result again?

Then there's information work, and AI can help make that information useful. Finding information, writing summaries, spotting useful patterns, exploring ideas, picking out the records you need, sorting information, and studying numbers can all be useful starting points when the original material is available and the system has the right tools.

The words at the end matter. An AI system working with numbers without access to the right records or tools to do the math is still guessing about the numbers. A summary without the full source can be a damaged record. A tool taught to sort records using the wrong examples can send an item to the wrong place.

Then there's work where a person has to make the call. Someone needs to decide whether to make an exception, whether a price protects the business, whether a client needs a difficult conversation, or whether work is safe to send. AI can prepare the information for that decision, but it doesn't take care of the relationship or answer for what happens.

The right tool can still be doing the wrong part of the job

Research shows that AI can help with one part of a job and get another part wrong. The study run with BCG and published in Organization Science tested GPT-4 with 758 BCG consultants on 18 realistic consulting tasks.

On the tasks the AI could handle well, people using it completed 12.2 percent more subtasks and worked 25.1 percent faster. Beyond what it could handle well, they were 19 percent less likely to get the answer right than people without AI.

Those numbers come from selected tasks and highly skilled consultants early in their careers, using the version of GPT-4 available at the time. They don't tell you how often AI will get things right in your finance work, your customer service team, or your next proposal.

They tell you something more useful. “AI helps” and “AI belongs on this part of the job” are different decisions.

The stories from people using these tools point at the same problem, although they don't tell us how common it is. An agency owner wrote, “If your manual process is a mess, automation just makes a mess happen 10x faster.” That's what one user reported, not a measured result for the product.

If a wrong answer forces somebody to check every result, find the missing source, fix the number, and explain the mistake to the next person, the tool didn't save the work. It changed who has to do it.

Start with one small piece of the work

Pick one job your team does regularly before you pick the AI tool. Write down what finished means, from what comes in to what the client, manager, or next team actually receives.

Then split that job. Which part needs the same answer each time? Which part is finding or sorting information? Which part needs someone to decide what's good enough or what happens next?

Choose one small AI step with a clear start and finish. Don't ask it to write a summary, decide what matters, update the system, contact the client, and close the job all at once. If one part fails, you need to know which part failed.

Use the real material, not a clean example made to show the tool at its best. If the job depends on topics discussed in a meeting, test a messy written record of one, with interruptions, side comments, numbers, and decisions made out loud. If the job depends on company records, give it the records it will actually have, with the access and tools it will actually use.

Give one person responsibility for checking the result against the original material and what the business needs. That person isn't there to read every sentence forever, but somebody has to decide when the step is good enough to move forward and what happens when it's wrong.

In our case, the eval checked whether a new summary kept the information the template required. You don't need our exact setup, but you do need a repeatable check that compares the output with what the job actually needs.

Follow the work to the end. Did the finished work pass its checks sooner? Did checking take longer? Did it come back for more fixes? Did the client or the next team receive something they could use? A task finishing inside the tool isn't the same as the business finishing its work.

Write down how the work gets done now, try the small change, and compare the finished work. Measure how much work passes its checks, the time spent checking and fixing it, and whether the business got the benefit you wanted.

Then give AI more to do only when the first step works well on real work. Add the next part when you understand the information it needs, the tool it uses, the rule it follows, the person who checks it, and how it can fail.

The work gets safer as you get clearer about what AI should and shouldn't do. It gets dangerous when you hide all those decisions inside one impressive set of instructions.

Fix the AI step, replace the tool, or stop using it

A failed trial doesn't always mean the whole idea was wrong. It means you have to look at the job before you buy another tool.

Try to fix the AI step when its job is clear and limited, you can supply the missing material or access, one person can judge the result, and you can say what good work looks like in one sentence.

Replace it with software that follows fixed rules when the job needs the same answer or action each time and a rule, formula, template, or ordinary tool can repeat the work without guessing.

Keep the decision with a person when the work means making an exception, protecting a relationship, giving approval, or answering for something the system can't take responsibility for. AI can prepare the material and suggest what to do, but the business still needs somebody whose name sits beside the decision.

Stop the AI step when it keeps dropping important information, needs a person to check all the work, makes an existing mess happen faster, or leaves nobody able to say whether the final work is correct. Don't keep paying for a guess because the demo was impressive.

Take one finished piece of work and follow it back through the original material, the tool, the instructions, the person who checked it, and what happened in the end. Record whether the important details survived, whether review took longer, and whether the client got a timely answer. That will tell you more than the number of paid accounts you bought.

Where this advice stops

This only works when the business has a job it does regularly, access to the original material, a person who can judge the result, and enough time to run a small test. If nobody can say what a correct result looks like, the information can't be used safely, or nobody understands how the work gets done, keep doing it by hand or use software that follows fixed rules while you fix what's missing.

The research doesn't prove that every AI failure comes from giving a guessing tool a job that needs fixed rules. The proposal example shows one failure and one repair, not a universal law or a measured time-saving result. The user reports are individual stories and the BCG study used selected consulting tasks.

A cheaper tool is not progress when the job needed a rule. A polished guess is not finished work.

Your AI Can Find the Record. That Doesn't Make It the Answer.

Fri, 18 Sep 2026 13:00:00 GMT

Your AI can find a meeting transcript and still give you the wrong account of what the client needs. Before you let it answer for the company, decide where it should look, how it should follow what changed, and when somebody needs to ask the client instead of choosing between records.

That last part matters because two notes can describe different stages of understanding the same client. Putting them in one system helps you find them, but you still have to work out what happened between them.

We had to do that at Berry. The consultants were going back to sales recordings and transcripts because the handoff notes sometimes described the client's needs too superficially, or treated a financial problem as a sales problem, or the other way around.

So the consultant taking over the work had to read more into what the client was saying before they could be comfortable with the handoff. They had the notes, but having the notes wasn't enough to understand the job.

The conversation wasn't finished at the sales call

The salesperson got better at understanding what the client needed, but getting it right was hard at first. The consultants weren't going back through the recording just to find a date somebody had copied incorrectly, they were trying to understand what the client expected and needed from us.

Then, in the first meeting, the onboarding meeting, they asked the questions needed to get that understanding right before the work started. The original conversation helped them prepare, and the client helped them settle what it meant.

Every note and every meeting transcript went into the project management system. The agent had access to what happened on the sales call, what happened during onboarding and what happened later, which is how we keep track of things that change during client work.

I co-founded Berry and ran its AI transition myself, and this was part of the work we had to do around the tool. Giving the agent access to the history didn't remove the consultant's job of asking the client the necessary questions.

And I wouldn't read a difference between the sales notes and the onboarding notes as proof that someone recorded the wrong thing. Our understanding could have improved, and the answer needs to account for that instead of treating the earlier note as the final word.

Adding a tool can add another record

Now, getting the history into a place the agent can reach is one problem. You can create that problem without replacing any of your existing software, just by adding a transcript tool while people keep writing notes somewhere else.

Both tools may have a useful job, and neither is waiting to be switched off. So waiting until the company finishes moving to the new system won't settle where those conversations belong.

Working in two systems during a workflow switch has taken two to four weeks in my experience, maybe more if we keep redesigning the process. That's the period of learning the new way while the old way still runs.

But keeping the client history usable needs attention again when you add another tool or change where people record agreements.

And the tools can write records as well as read them. On one team I watch, a junior built a skill that read meeting transcripts, pulled out tasks and filed them in the project tool, with dates based on what the meeting agreed.

Nobody senior had asked him to build it. He knew the work well enough to see something people were copying by hand and make the tool do it.

That is useful initiative, and it doesn't make him the person who should decide who can change a client promise. If you run the company, you need to settle that with the person responsible for delivery, so whoever builds the tool has a rule to work with.

Your team can help write it, but they shouldn't have to guess which commitments the company stands behind.

Decide what supports the answer

Justin McKelvey recommends that owners running two companies with separate customer systems “declare which system is authoritative, field by field.” In everyday terms, write down where each answer should come from before the AI uses those records.

I agree with that as a starting point. Contact details can come from the customer system, the agreed scope from the signed proposal and approved changes, and delivery needs evidence that the work was sent.

But the Berry handoff is why I wouldn't stop at a list of systems. A rule saying to read the sales note wouldn't have resolved the questions the consultants asked at onboarding, and a rule saying to read only the latest note would leave out the conversation that came before it.

For the client's needs, I'd want the agent to follow the relevant history and explain what was clarified. For a commitment, I'd want it to find what was agreed and whether an approved change replaced it.

Those are different checks, even when the records live in the same place.

You might decide the responsible thing is to clean up every record before doing anything with AI. I understand the instinct, but cleaning up the notes can't decide whether a later conversation changed the agreement, somebody still has to settle that.

And bringing all the software together can become a much larger job than the work you wanted AI to do. McKelvey calls consolidating the two customer systems first “a six-month data migration wearing an AI costume”, which is his warning about making consolidation the prerequisite, not a timeline I'm giving you for your firm.

I would write the rules for the work you're about to automate, including where to look and what counts as a change. That page is my recommendation, not a fix I have measured at Berry, and it needs to be available to the people and the agent doing the work.

It's related to writing down how the process runs, but it answers a particular part of that job, what supports the answer we're about to give this client?

Follow the change, or ask

Take a deadline as an example, not a reported incident. Suppose the sales meeting records one date, then the client asks during onboarding whether the work could arrive earlier.

The later transcript records a request. It doesn't, by itself, tell you the company accepted it, so an agent shouldn't put the requested date into the next client update just because it's the newest date it found.

If the person allowed to change the commitment approved it, the agent needs the record of that approval. Your rule should say where that gets recorded and who can make the decision, rather than leave the person building the tool to choose.

If the records don't show whether the request was accepted, the agent needs a rule for stopping or asking, not encouragement to fill the gap. It should hold the answer and show the relevant records to the person responsible for delivery, who can settle the question with the client if needed.

That is the part of the page I would test with whoever builds the workflow. Give it an earlier agreement and a later request without approval, then check that it asks rather than treats the request as a promise.

A page on its own doesn't make an AI stop.

And when someone resolves the question, keep the answer with the client history so the next person doesn't have to reconstruct it again. Some disagreements need a record corrected, others need a missing decision, and the person responsible needs time to do that work.

Agreement still isn't proof of delivery

There is a limit even when you have a rule and the records agree, and we found it in a client status update at Berry. The update passed its checks because a task was marked closed, then the client said the work had never arrived.

The records agreed with each other and they were still wrong about reality.

So for a question like “was it delivered?”, I want the check to reach the file that was sent or the delivery message, including who it went to. A closed task can tell you someone finished a step internally, it doesn't by itself establish that the client received the work.

If the message shows a failed send, or the file went to the wrong person, you don't call it delivered because the project tool says closed. The evidence needs to support the claim you're making, especially when being wrong is expensive.

And if another person or AI checks the update, give that checker the underlying evidence too. Checking against the copied status that produced the answer is how you can get agreement without finding the mistake.

Start with an answer the client will use

This assumes someone owns the work and can decide what counts as an agreement or proof of completion. If those decisions still live in the owner's head, listing the software won't get them out, that conversation comes first.

And if you are replacing a system with a planned switch-off date, you still need the migration work. These rules don't move or sync your data, and access to the history doesn't guarantee the agent will understand it correctly.

I'm drawing on Berry's experience here, not a measured comparison of firms using this approach. I don't have a result to promise you from writing the page.

What I would do this week is take a client answer your AI has produced, a date, a scope, a price or a status, and follow it back with the person who owns the work. Find the record it used, check what was clarified or approved later, and look for the evidence behind anything it says was completed.

Where that leaves an unanswered question, settle it before the next answer goes out. Record the decision where the team and the agent can find it.

AI prices fell up to 22x. Our bill fell 2x. Here is where the rest went.

Wed, 16 Sep 2026 13:00:00 GMT

If you see a model get twenty times cheaper and expect your company's AI bill to fall by the same amount, that's a reasonable read of the pricing page. What happened to my company was that we used the lower prices to give the agents harder work, so we kept part of the saving and spent part of it on what they could do.

The old models were 9.1x to 22.2x more expensive than the ones we use now, and our monthly model bill fell by a little more than half. Our new software uses about ten times as many tokens across the month, these are Berry's actual monthly figures, not a comparison of the cost of one task.

But some of what we produced was so far from what people wanted that they took it to ChatGPT to summarize it themselves. They told us the meeting transcripts were too long, they weren't useful, they weren't going to use them.

We only had to change the instructions for those transcripts. That's a different kind of improvement from the extra work we were paying the agents to do, because making the output useful doesn't always mean spending more.

AI token cost and the bill move on different lines

The simple arithmetic is a price divided by twenty, multiplied by ten times the usage, which leaves you with half the original bill. That's an illustration of how the two changes work together, not an exact reconstruction of our invoices across different models over several months.

I'm talking about the tokens a language model bills you for, not crypto tokens. For that part of the bill, you multiply each type of usage by its rate and add it up.

So yes, cheaper models can give you a proportionally smaller bill if the work and the way it runs stay the same. But at Berry we changed both, because work that hadn't been worth running became affordable.

And OpenAI puts the cost distinction plainly in its July 2026 investment guide: “The lowest token price does not always produce the lowest total cost.” You still have to count the attempts and the people checking what came back.

Where the tokens went

At Berry, we started handing the agents much more complex tasks, analyzing large amounts of data, creating charts, building presentations, monitoring data, updating their own memory, joining in more often in group conversations they were already part of.

Those were things we could now afford to have the software do, including work that happened without another request from a person.

Take monitoring as an example of what that means. Asking for a report when you need one and having an agent keep reading the data so it can notice a change are different jobs, even if the person ends up reading one short message in either case.

And the memory work happens behind the answer too, the agent updating what it needs to remember doesn't have to produce another document for someone to read. More tokens can mean more work behind a smaller amount of visible output.

That is what I see at Berry, not a list of jobs every service firm should automate. And getting there took several months of changing the software, it wasn't something we got by choosing a cheaper model from a menu.

The cheaper model did not do this. The rebuild did

Over those months we redid pretty much all the code, with better rules for the model, code that prevented bugs, better system prompts, better memory, newer approaches and technologies. The system prompts are the standing instructions the model works from.

So the tenfold increase in monthly tokens came from that rebuilt software doing more work, it doesn't mean each task became ten times larger. That broader change took months, the transcript instructions were a much smaller fix inside it.

If the work you want requires that kind of rebuild, your team needs time to change the software and check it. They aren't slow to adopt because they haven't fitted months of work around their existing jobs.

The smaller monthly model bill doesn't tell us whether we've paid for those months of work. As I explained in the cost cut we couldn't call a win, you need to count work that met the standard and time spent correcting it before you can say delivery got cheaper.

And even after you've built it, you still have to find out which of those newly affordable tasks produce something people want.

People told us what they wanted to read

With the meeting summaries, people were explicit about what they didn't want. They were summarizing the summary in ChatGPT themselves, so we had left them another step to do before they could use what we sent.

And they mostly knew the format they wanted, a TLDR, a quick summary at the top, a short list of the points discussed with the times they happened, then a to-do list of what they had agreed upon and a closing summary.

That gave us something specific to put in the instructions. We didn't need to rebuild the software to make that change, and it isn't an example of spending more tokens to get a better result.

So if you've done that too, it's okay, we got it wrong as well. I would look at what the system is sending before deciding that people aren't paying enough attention to it.

We also added too many notifications about changes, and that turned into noise too. What I found was that people welcomed less output of better quality, and I felt the sweet spot was to show only what was relevant at the time it was relevant.

So before spending more, I would find out what the person actually needs to receive.

We should not build a feature just because we can.

We ran into that with reports at Berry too, producing more didn't help when nobody wanted to read them. Making the result useful comes before deciding whether it needs more work behind it.

Review time went down, not up

There were other parts of our work where the model was doing more behind the answer, including checking part of what it had done. As the models improved at Berry, we saw fewer mistakes and review time went down, even as we handed the agents harder work.

That matters because being able to afford more agents doesn't mean you can afford to watch them. If each new task adds something a person has to inspect, the model bill can stay small while the manager's week fills up.

I call that depth, work behind an output to make it more correct, better checked or better timed, and part of our extra token use went into those checks. Output is the amount we put in front of a person to read.

For example, an agent can read the records behind a report and check the figures without sending the manager another report. That is a reason to consider more work behind the answer, while making the meeting transcript longer gave people more to read without giving them what they wanted.

I don't have a clean before-and-after number for time spent reviewing to give you. This is the direction I observed in our work, not a measured ratio you should put in your own budget.

And a model checking itself doesn't remove the need for a person to own the standard. Keep model cost and review cost together, and check whether the finished work passes, rather than treating an extra AI check as proof that it does.

How much work we assign matters more now

Earlier at Berry, we were paying for more intelligence than some of the work needed, so the model choice was the first cost setting I would look at.

But by September 2026, at Berry, we were using one policy for pretty much everything. Models got so good that even the cheap ones were enough for most of our workflows, so we no longer needed to spend most of our attention on that choice.

The larger decision became scope, how much work we handed the agents, how many steps they took, how much background information they read, what they remembered and what they kept monitoring. Adding another recurring monitoring job changes usage even when nobody changes the model.

That doesn't mean you should put every task on the same model because we mostly do. A mistake in a draft and a mistake in a price sent to a client still carry different consequences, so sort the work by what getting it wrong costs, and keep the stronger model and extra check where the work needs them.

Decide where the cut goes before it arrives

Before adopting the next cheaper model, sit down with whoever owns the system and the person who uses its output. Start with what that person needs to get from it, rather than how much more the agent can now afford to do.

For every proposed task that sends something to a person, answer “who reads this, and when?” If the answer is a manager before the weekly meeting, that gives you a reason to choose that timing instead of sending every change as it happens.

Then look at the simplest change that could deliver it. If people can describe the format they need, put that in the instructions and have them look at what comes back before planning a larger rebuild.

For background work, name the result it improves instead, a memory update doesn't need its own reader. But somebody should be able to explain which later answer needs that memory.

Where the proposed work does need more steps, more checking or new software, ask whoever maintains the system what that change requires. Put the work of building and checking it beside the added running cost, so the cheaper model doesn't hide the larger commitment.

Now you can decide where the saving should go. You can keep it as margin once the full costs support it, spend it on depth, add new scope, or pay to get work finished sooner, but the decision should name the work and the result you expect from it.

At Berry, the model bill ended up less than half its old size while we spent more on scope and depth, and some of that scope turned out to be noise. Those figures tell you where we ended up, they don't tell you that we planned that exact split or that profit went up after paying for the rebuild.

Keep counting accepted tasks, the ones that meet your standard, as you expand, with failed attempts and correction time still in the cost. Otherwise the new work can look cheap because you're counting everything the agent attempted as something useful it finished.

This is the question in the Four Numbers, where did the freed capacity go? It applies to cheaper model usage for the same reason it applies to the extra time AI buys your team, someone needs to assign what became available and check what it produced.

This advice assumes agents already run inside real workflows with an acceptance check, the move from Stage 2 toward Stage 3 on the Delivery Model Ladder. If people are only using a fixed-price chat subscription, a lower token price doesn't automatically lower that subscription or give you a usage budget to redirect.

And someone has to be able to change the software, inside your firm or through whoever maintains it. A lower rate can reduce the bill for unchanged usage, but the new capability we got took months of rebuilding.

You don't control when the next price cut arrives, but you can decide what work it will pay for before you adopt it.

Decide before the invoice does.

Making the same work faster is not enough

Mon, 14 Sep 2026 13:00:00 GMT

Making the same work faster is not enough if your team still has to work the old way afterward. We ran into that at Berry when AI evaluated more than two hundred sales meetings a month, but nobody wanted to read all the reports, so managers kept using sales numbers to decide who needed help.

We had made the evaluations faster without changing how managers used them. The bigger gain came from deciding what work they could stop doing and what we still needed them to do with the salesperson.

The reports were done. The manager's work wasn't.

The first version did what we asked it to do. AI read the sales call transcripts and scored each one against a rubric with roughly twenty-five points. By the end of the month we had so much information that it was hard to see who was doing well and who was not.

So managers were still looking at sales numbers, finding the lowest performers, and working with them first. That was our previous method, and it took too long to fix problems because we were finding them through the sales results.

I would not call that resistance to AI. We were asking managers to read all those reports and work out who needed their attention, and the system had not made that part useful yet.

Being able to evaluate all those calls was useful, of course. But we still needed to turn the evaluations into something the manager could act on, otherwise we had done one part faster and left them with all the work that came after it.

If you are the owner, that part is yours to work out. At Berry, we had to change what the manager received and what they did with it, because asking managers to read more reports was not going to solve the problem we had created.

We changed what the manager received.

We did not throw away the detailed analysis. The rubric still ran on the calls, and those evaluations stayed in the system as input.

What changed was the next step. We had AI read through the detailed reports and pull out a short coaching list: which salesperson the manager should work with, and which points to work on with each one. The opportunities that looked easiest to get results from sat at the top, highest gain first, in the order we cared about.

The manager no longer had to start with the whole pile and hunt for priorities. And instead of waiting for low sales numbers to tell us someone needed help, we could catch what they were doing in the calls much sooner. With AI, the feedback was almost real-time.

For example, we had a series of qualification questions salespeople were supposed to ask. Some were not asking them properly or in the right sequence, so they were losing the script and the ability to take the potential client through the conversation the way we intended. That hurt their ability to close the sale.

We could catch that much faster and help them practice the questions. A low sales number told the manager who was struggling, but this gave them a specific part of the conversation to work on.

Getting to that useful list took trial and error. We still had to work out whether the suggestions were right before asking managers to rely on them.

Checking was part of getting there, not the final job.

For a while the managers still checked. They took the first ten results on the list and went through the suggestions with each salesperson involved. Is this correct? Did this really happen? People's feedback helped us refine the process, and we adjusted from what we heard.

In the end they pretty much stopped checking on their own. The evaluations were correct ninety-nine percent of the time, and the managers used the list to start conversations and run coaching from there. It became very useful.

If we had kept asking managers to check every evaluation, we would still have left them with a lot of the work we were trying to take away. As the evaluations became dependable, that part of their job largely went away.

The manager still had to help the person improve.

Even after the list was trusted, the manager's job did not disappear. One thing is knowing what went right or wrong in sales technique. Another thing is connecting that finding to our way of working at Berry, and then communicating it in a way that helps and motivates that salesperson instead of causing more problems or hitting the wrong spot.

That was the hardest part, and it stayed with the manager. Knowing that someone had missed qualification questions gave us a place to start, but we still had to help them use those questions properly in a conversation.

We used simulations and role-play, and we gave salespeople a script so they could practice with each other. The AI finding could lead to someone practicing the part of the call they needed to improve, rather than another report for the manager to read.

That is where we drew the line in this process. We largely stopped asking managers to repeat the evaluation, and kept them involved in helping the person change how they worked.

Decide what people will stop doing.

If you have introduced AI into a process, ask the person receiving its output to walk you through what they do next. Are they using it to act sooner, or are they still doing the old work and now have an extra report to read?

At first, our managers still depended on the sales numbers to figure out who needed help. The evaluations existed, but they had not replaced that slower way of finding problems. That is the difference I would look for before asking the system to produce more.

And this took validation and refinement. If people still need to correct the evaluations, you cannot simply take checking out of their job, and a different kind of work may need continued review. Working out that balance is still hard.

So work through the change with the person who has to use the result. Decide what they can stop reading or rechecking once it is dependable, and what you need them to do with the information instead. In a coaching process like ours, that includes making room for the conversation and the practice, because finding a mistake earlier only helps if someone works on it.

You Can Build Your Own Software Now. Buy the Cheap Tool Anyway.

Fri, 11 Sep 2026 13:00:00 GMT

Replit sells software, and in 2026 it dropped a seven-figure software contract because an app its own people built with its agent was better than the thing it was paying for. That is the loud version of the story, and Amjad Masad, the CEO, told it in a post on Replit's blog and again in an interview with Platformer.

Here is the quiet version, and it is mine. Berry is a service company, not a software company, and today it runs on a CRM, a project management system, an AI interview tool, an internal chat, and AI agents, all built by us. Five years ago none of that would have made sense for a company like ours.

Now look at your own firm for a second. You are paying for a dozen tools, you use maybe half of them the way you meant to, and somewhere in the building somebody has already built a little thing with an AI coding tool that is quietly in the path of client work.

So the flip is real. Building your own software is open to a firm your size now, and it was not before.

And it still does not mean you should start building. Buy the cheap tool first. Build when nothing fits, and know before you start that the first version will hurt.

Masad is half right. Maintaining software did get cheaper. What it did not get is free, and who pays for it is the whole question.

The reason you bought software was never the features

Think about what you were paying a vendor for. Not the features, the features were the sales pitch. You were paying them to carry the forever cost, the bug that shows up on a Sunday, the hosting, the other system that changes its connection and breaks yours, the person who built it and then left.

CPA.com, an affiliate of the AICPA, the accountants' association, put out a short guide on this in June 2026 and they say it in one line: the real cost of software is not creating it, it's maintaining it forever. I like having a CPA body say that out loud, because it is the part every demo skips.

Now look at what Replit is claiming. They say their internal agent now beats the market-leading products they test, and that the more they build, the less they need to buy. What I read in that is that the forever cost got cheaper for them, because the agent carries it, and that is aimed at the exact thing you were paying the vendor for. That is why the flip matters to you and not only to a startup full of engineers.

What they report, and this is company-reported, nobody outside audited it, is that they dropped that seven-figure contract, and that vendor tools for sorting system alerts and for security testing cost about ten times what running the same job on their own agent did.

The question you should be asking is whether any of that holds for a service firm, or only for a company made of programmers. I can answer that one from my own chair, because we did it, and it was not clean.

What we built at Berry, and what it cost us

We did not set out to build our own CRM. We went looking for one, the same as you would. We tried the popular ones, Pipedrive, even ClickUp, not the big ones like Salesforce, and in the end we went with the smallest and cheapest, a couple of local CRM services, because that is our rule.

They did not work the way we expected. A lot of what we needed just was not there. They did not connect well to our marketing and our data, the handoff from a closed sale to project management was poor, so the link to payments and to the services we deliver was bad too, and we are a franchise, so a sale also has to hand off to a franchisee, and nothing on the market understood that at all.

So all of those gaps together drove us to build our own CRM, and later the project management system, the AI interview tool, the internal chat, and the agents that now sit inside all of it.

And a lot went wrong. The first versions we built did not work properly. There were a lot of bugs, there was wrong data, and it caused real stress and real problems inside the company, people working from a system they could not fully trust while we fixed it.

Once we got the problems fixed, it was a much better tool than anything we had found in the market, we put AI inside it, and we streamlined a lot of the work with it. It was impossible to buy what we built.

I will say it plainly, because I want you to hear the cost and not just the ending. It was a very complicated and dangerous strategic decision. It got us a level of speed and optimization that an off-the-shelf tool would not have given us, and it also gave us months of a system that was wrong in ways we had to find one by one.

Different seat from Replit, same decision. I did not read about this in a startup interview, I made the call in my own service company, as the CTO and the owner, and I paid for it.

And the rule works from the other side too. A separate franchise sales team at Berry tried HubSpot for their CRM. They ended up leaving it because the cost was way too high, and they came over to the CRM we built. Same rule, run by a different team, landing in the same place.

So is the answer just build? No. Here is the rule we actually run, and it is less clever than the frameworks.

The rule we actually use: buy cheap first, build when nothing fits

First, we look for a tool that solves the specific problem, at a price we can pay.

Second, we buy the cheapest one that does it, or the one that has the connections to our other systems and the AI we want inside it. Cheapest that fits, not best on paper.

Third, and only if nothing fits, we build it ourselves, because we want it shaped to our workflow and built in a streamlined way, without the twenty features we will never touch.

That is our whole build vs buy rule. It has not changed since before AI, and the CRM story above is just the rule running all the way to step three.

The obvious read of the Replit story is the opposite, build everything now, the vendor is dead. I understand why people read it that way, the seven-figure number is right there. The price of that read is that every tool you build is a tool you now maintain, and the vendor was carrying that for you, and most of the time they were carrying it for less than it would cost you to do it yourself.

So what does "nothing fits" actually mean in a service firm? It means the tool exists but the price is wrong for your size, it wants a per-seat contract built for a company ten times yours, which is exactly what our sales team hit with HubSpot. Or it does not talk to the systems you already run, so your team ends up typing the same thing twice. Or it does not carry the AI you wanted, and the vendor is still bolting a chatbot onto the side. Or it makes your team work the tool's way instead of yours, and you can feel the friction in every handoff.

When you hit one of those, you used to be stuck. You paid for the wrong tool or you paid a dev shop a fortune to build the right one.

That third step is what opened up. That is the flip, and that is all that changed.

Who owns it in three years

CPA.com's guide has a six-question test, and most of it is sensible. The sharpest question in it is this one: if we build it, who owns it in three years? Who maintains it, supports the people using it, patches the security, handles it when the model underneath changes? Their answer is that if you say "we haven't thought about that," you define it now or you buy.

They are right about the question, and I want to sit on it for a minute, because I disagree with where their answer leans.

Picture the person in your firm who built the little CSV fixer on a Friday afternoon, the one that reformats the export from that one client's system so it drops into yours. They were not being reckless. They solved a problem that was eating an hour a month, with a tool that took them an afternoon, and it works.

The risk did not come from them. It came from the owner who never asked who keeps it running, and what happens the month the client's system changes its export format, and what happens the year that person takes another job.

At Berry the answer to the three-year question is our internal dev team, and from what I have seen, most firms between one and twenty million do not have one. Your honest answer is a person, one person, and CPA.com's warning is aimed at exactly that: when the builder leaves, the tool often leaves with them.

Here is what I would actually tell you, if you sat across from me with no developers and one person who likes the tools. It is risky, yes. So weigh whether the thing helps the company in a strategic way. If that tool gets you a lot of hours back, or lets you deliver a lot more to your clients, I would build it.

Because look at the other side of it. It is not that hard to find someone later on who can fix the tool, improve it, update it, and the whole time you are still collecting the benefit. But if it is something important and you do not build it, you never get the benefit at all, and that is usually the worse strategy. You can buy the benefit from a vendor, fine, do that when you can. When you cannot, and you can see how AI could help your process and the tool is just not out there, it is worth building.

And today the first version does not need a developer. Something like Lovable, or a coding agent like Claude Code or Codex, gets a person who knows the work to a working tool, and keeping that alive later is not the wall it used to be. Take the chance, improve your workflow, and yes, your company will have something to deal with down the road. You will have collected the improvements the whole way there.

One more thing the guide underplays, and it is the thing Replit has that you might not. A built tool drifts. The model changes under it, the answers get a little different, and nobody notices for weeks because nothing crashed. Replit can afford to build because they have a review system that catches that kind of drift, and if you do not have one yet, I wrote about the four stages of reviewing AI work and that is where that argument lives.

CPA.com draws the rest as an iceberg, and their line for it is that AI changed the economics of experimentation, not the economics of operational durability. In plain words, the demo got cheap, and running the thing for three years with real client data did not.

Two of the failure patterns they list matter most for a firm like yours. One is pricing whiplash, vendors moving from per-seat to per-token, so the price you signed at is not the price eighteen months later, and that one hits the buy side as hard as the build side. The other is the model pulling one client's data into another client's work, which they call the failure mode most firms underestimate, and I agree with them.

How to run the rule this quarter

Here is how I would run it, at the size of the decision, not as a slogan.

Write the problem down in one sentence, and next to it the price you can pay per month. If you cannot write both, you are not ready to buy or to build, you are ready to look.

Then go find the cheapest tool that solves it, or one that carries the connections and the AI you want. Give that search real time, a couple of weeks of somebody actually trying tools, before you let anyone open a code editor. Most of the time this step ends the question.

If nothing fits, weigh the benefit honestly. A lot of hours back, or a lot more delivered to clients, and you build. A small convenience, and you live with the gap or the imperfect tool.

If you build, build the smallest version that does the job, and before it goes live write down who owns it in three years, with a name on it. If you have no developers, the name is the person who will go find help when it breaks, and that is a real answer.

If the tool touches sensitive client data or regulated work, tax filings, anything with a client's personal details, buy it from a vendor who has already built the security, unless your builders can prove they have. That is CPA.com's sixth question and I would not argue with it.

Price the maintenance now, not later. The model changing, the connections breaking, the tokens it burns each month. If nobody in the room can estimate it, that is your estimate, and it should worry you a little.

And the Friday CSV fixer is fine. CPA.com says to treat a one-off like that as learning, not infrastructure, and that is the right way to hold it. A tool you can throw away next month is the safest thing you will ever build.

Where this stops

Two conditions, and I will state them as facts.

First, the build branch costs you a stretch of bugs and wrong data before it pays. Ours did, and we had a team to fix it. Without a team that stretch is longer and you are collecting help as you go, so it only makes sense when the benefit on the other side is real, hours back or more delivered. A tool that gives you neither is not worth that stretch.

Second, regulated work and sensitive client data sit outside this rule. There you buy from a vendor who already carries the security and the audit trail, and you build around them, on top of them, not instead of them.

And the edge of what I have seen. I have not yet built something I wished I had bought, and I have not yet watched one of our tools go stale because its builder left. So the leaving-builder side of this is CPA.com's warning plus my reasoning, not my measured case, and I would rather tell you that than pretend.

The frameworks got longer this year, and the rule got shorter. Buy the cheap tool first, and build the day nothing fits.

Don't Pick Your First AI Pilot by Performance Alone

Wed, 09 Sep 2026 13:00:00 GMT

When you bring an AI tool into a service firm, the instinct is to hand it to the person you trust most with a client, the senior, the best performer on the team.

That instinct is half right. You do want the tool near real work, but being good at the job doesn't tell you whether someone wants to help work out a new way of doing it.

At Berry, I never picked people for a pilot by who was best. I picked by who wanted it. If your best person wants to try it, include them, the mistake is picking them just because they're your best.

And by enthusiasm, I mean willingness to try a change and help get it working, not just liking AI. Let me tell you what that looked like in our sales-to-consultant handoff.

At Berry, I started with the people who wanted it

The handoff was supposed to tell the consultant what the client needed and the objective of the work. But the notes weren't doing that well, and there were two ways that played out.

In the worst case, the consultant trusted what was written, went into the first onboarding call with the client, and led the work in the wrong direction. The person taking over was working from a bad account of what the client needed.

Or the consultant went back to the sales conversation to understand it for themselves. They started watching the entire sales meeting, which sometimes ran over an hour, or reading the transcript so they didn't have to depend on the handoff.

So either the bad notes shaped the work, or somebody had to reconstruct the conversation before they could use it. That wasn't a consultant failing to care about the client, we were leaving them with a handoff they couldn't rely on.

The AI enthusiasts noticed that problem themselves. They created a template in ChatGPT, tested it, found that it worked, and spread it to the rest of the team.

The AI would read the sales call transcript, analyze the points they had specified in the template, and generate a standard response based on it. So the handoff had a format to follow, rather than depending on whatever somebody happened to put in the notes.

That standard improved the work. They were changing the handoff, not just trying to write the same notes faster.

Those people had already been trying AI tools and seeing better output in their own work. They gave fast feedback and were willing to reorganize how they worked, which helped us move from trying a tool to using it in the process.

That's the help I want in a first pilot, because an implementation often doesn't work at first. You have to try it, see what broke, and work on it for a while before you get real results.

What I've seen is that people who don't see the improvement or don't understand the technology go back to their old workflows more easily. That doesn't make them stubborn, they still have a job to finish, and if you want them to help test a new way of doing it, you have to make room for that work too.

Strong performance doesn't guarantee a benefit

The research gives you a reason not to assume your best people will benefit most, but it answers a different question from the one I answered at Berry.

A preprint about Alibaba's Taobao after-sales support followed 5,940 agents for four weeks, randomly giving some access to an AI assistant and keeping the others as a comparison group. On average, agents identified issues faster and customer ratings improved.

But when the researchers split agents by their customer ratings before the experiment, the bottom fifth gained 0.812 points on a five-point scale, while the top fifth lost 0.283 points. Those are effects of access compared with agents in the same performance group who weren't given it.

The top group also had a higher rate of customers coming back with the same issue within three days. And they got faster at identifying the issue, so looking only at that part of the job would have missed the worse result for the customer.

The easy read is that the strongest people got lazy and trusted the AI. But they used it less, and a later survey found more skepticism among high performers. The authors found evidence against over-trust and harder cases explaining the decline.

Their analysis points toward a problem with attention, the top group spent more time away from the current chat and answered more slowly while resolving the problem. That's a possible explanation, not a proven cause, because the researchers didn't randomly assign how agents divided their attention.

A separate study by Brynjolfsson, Li, and Raymond, published in the Quarterly Journal of Economics, found a 15% average increase in issues resolved per hour across 5,172 support agents. The most skilled workers had no productivity gain, alongside small but statistically significant decreases in resolution rates and customer satisfaction.

Neither result means strong people are the wrong people to include. And giving agents access at random in the Taobao experiment didn't test whether starting with enthusiasts works better, or show that unwillingness caused the harm. My reason for starting with enthusiasts comes from running the transition at Berry, not from a comparison those researchers made.

Check how the work feels and how it turns out

Even with people who want to try it, the transition can look worse before it looks better. What I've seen is that sometimes you work on two systems at the same time, you're still learning the new workflow, and the work takes longer during that switch.

That has taken two to four weeks in my experience, maybe more if we keep redesigning the process. I haven't seen strong performers get worse in the way the Taobao paper describes, what I'm describing is the transition mess, not a reason to assume its quality decline would disappear with more time.

So a bad second week doesn't have to be the final verdict. But learning a new process and sending worse work to a client are different problems, and you can't ask the client to accept the second because you're still doing the first.

I use two signals. The person's own feedback, and the hard numbers.

Ask whether the new way makes their day easier, and look at how long the whole task takes, whether quality improved, how much work came back to be done again. A faster step doesn't tell you whether the finished work is better, which is the distinction I make in The Extra Time AI Buys You Is Already Gone.

And the person's feeling isn't enough on its own either. In METR's 2025 study, 16 experienced open-source developers believed afterward that AI had cut their completion time by 20%, but the measured result was 19% longer.

METR's 2026 update weakly suggests a speedup with later tools, though changes in which developers and tasks entered the study make that estimate unreliable. The earlier slowdown isn't a verdict on today's tools, but the gap between how the work felt and how long it took is a reason to check both.

When feedback and the finished work improve together, or start moving that way, I take that as a reason to keep going. If people say work is getting harder, keep switching back to the old system, or aren't seeing their day improve, quit it or redesign or try a different approach.

Ask why they went back before treating it as a training problem. Running both systems can be part of learning, but if they still need the old one to get the job done, the switch isn't finished.

What to do in the first month

Start by asking who is already trying AI and wants to help test a change in the work. Keep people with a working method and no appetite for that testing out of round one, not forever, out of the prototype.

Before you start, write down how the work is going now. Pick measures you can compare later, time for the whole task, rework or comebacks, and a sign of quality the client would notice, rather than trying to remember the old process after you've changed it.

Then have a conversation and look at the finished work every week. Keep the results visible for each person, because a better group average can hide someone whose work got worse.

Use those checks to decide whether to widen the group, change the process, or stop. Don't make expansion automatic at the end of the month, and don't leave clients with worse work while you wait for it to end.

Where this stops

The Alibaba agents all had under one year on the job and handled several chats at once under fixed procedures. Being the best in that group isn't the same as being a fifteen-year veteran, and a firm where one person owns a client end to end has a different working day.

A review of human-AI experiments by Vaccaro, Almaatouq, and Malone also found that, on average, the combination beat either working alone when humans performed better than AI alone. That compares humans with AI, not employees with one another, so it doesn't settle what happened at Taobao or support a rule against including experts.

Two to four weeks is my experience of the transition, not a deadline by which your pilot has to work. And picking enthusiasts is how I started at Berry, not a guarantee that their results will carry over to everyone else.

If nobody is trying AI on their own, ask what would let a willing person start. If the missing piece is time, give them hours to learn inside the working week before expecting them to help redesign the job.

Nobody Wanted to Write the Meeting Summary

Tue, 08 Sep 2026 10:54:01 GMT

After a client call in Google Meet, somebody had to write down what we talked about, what we agreed to do and what needed following up. Nobody liked doing it, so the summaries came late, with information missing, tasks missing, and sometimes very little that anyone could use.

People didn't create them because they didn't have the time and it was a pain to do it. If you have six meetings lined up in a day and fifteen minutes between them, you're not going to fill a template.

You have a lot of meetings to attend to and a lot of work to do, and those short gaps are what you need to prepare for the next client, not to sit down and write up the last one.

And if you're trying to work out what tasks to automate with AI in your company, I would look for your version of that, a piece of work people keep putting off even though somebody needs the result.

When the notes didn't get written, the cost didn't disappear. If you needed something from a sixty-minute meeting and it wasn't in the notes, you had to go back to the recording, remember roughly when the subject came up, watch again and write it down.

That could take from ten minutes to sixty minutes re-watching and taking notes. That was the hassle we had, not a measured saving I'm claiming for every summary.

We knew AI could help us with that, so we went through three versions in a week before we got something the consultants and clients liked, and those summaries are still in use.

AI could read the transcript and write the summary instead of leaving the consultant to do it. But getting that to work also meant figuring out what a good summary should contain, and we hadn't properly done that before.

Think about what happens with work like this in your own firm. Someone writes up the call, closes the task and moves on, so as far as the system is concerned, the work is done.

But that doesn't tell you whether the things people agreed to do actually made it into the write-up. A summary can exist and still leave the next person without the information they need to do their job.

That's the problem we had. And I don't think blaming the people writing them would have helped, because we hadn't given them a clear enough idea of what we expected either.

They were doing work they didn't enjoy, alongside the client work they still had to finish, and nobody had properly decided what a useful summary looked like. I say that as the owner, this was something we needed to sort out.

I've written about where AI projects get stuck between a working demo and daily use. With our summaries, checking that the system produced text wasn't enough, we needed to know whether that text helped the person receiving it.

Now, there's a reason this kind of work can be harder to automate than you expect, and it helps to separate two jobs.

Sometimes you already do the work well. You have a report people use, someone knows what belongs in it, and you can show the AI what you're trying to produce. You're asking it to follow a pattern you already understand, faster or better.

Other times you're trying to produce something you haven't worked out how to do properly yet. You can explain what it's for, but once you see a first version, you start realizing what should be different.

That's much closer to what happened with our summaries. We had people writing them, but we didn't have a good enough example that we could point to and say, make it like this.

So we had to try things, look at what came back and work out what would actually help the people using it. That takes more thought than handing over an existing process.

I've told people to document the process before giving the work to an agent, and I stated that too strictly. It assumes you already have a process worth following.

If the way you're doing the work now produces a poor result, writing it all down doesn't solve that. In our case, we needed to improve what the summary was supposed to be, and trying an early version helped us make those decisions.

And when I say a template wouldn't have solved it, I don't mean defining the output was useless. I mean a better form still leaves someone filling it in during the minutes they need for something else.

Nobody wanted to do that, it felt like a waste of time. Having AI read the transcript and draft the summary is a much better solution than having someone fill a form when they have minutes to prepare for the next client.

The first summary version gave us pages of text. It was too complicated, and even though it contained a lot of information, people didn't want to read it.

So we made it simpler, and then we went too far. The second version was missing the work that was agreed, the next steps and the next tasks. We had made it easier to read without making it useful enough.

We needed those tasks in a short list, with enough detail that someone could scan it and understand what needed doing without reading a long account of the meeting. Making the summary shorter wasn't enough if the agreed work disappeared with the text.

The summaries we ended up with were used to create follow-up tasks, help with client planning and keep a history of the project.

We had very few problems with the AI making things up in this case. Most of the work was on how the information was presented and how much of it belonged there.

That doesn't mean accuracy is usually easy, I'm telling you what happened with this particular job. If we'd only checked whether the statements were correct, we would have missed most of what people disliked about the output.

And we had a similar problem with a system that read sales meeting transcripts to help a supervisor give feedback. It produced so much text that the supervisor wasn't getting much use from it, so we replaced the reports with scores that showed who needed help first.

I explained that case in the AI enablement article. In both cases, looking at what people actually used told us something we couldn't learn just by looking at whether the system ran properly.

With the meeting summaries, three versions in one week got us to something everyone liked. But please keep the conditions around that result, because I was the person making the changes, I was involved in the deployment and I responded quickly when something needed fixing.

If nobody in your company has time to do that, you shouldn't expect the same week. The team can tell you what's wrong, but someone still has to make the change and get it back to them while they're willing to keep trying.

I haven't measured whether it improved retention, project outcomes or anyone's hours. What I know is that the summaries became useful enough for people to keep using them in their work.

So don't stop at how quickly the AI wrote it, check whether the follow-up tasks are getting created and whether the summary helps people plan the next piece of client work.

This also puts a boundary on something else I've written. In The Extra Time AI Buys You Is Already Gone, I said to decide what saved time will be used for before the rollout. That rule was too strict as well.

It applies when you're expecting to free up time. You should still count the checking and rework, and decide what the team will do if those hours become available.

But if you're starting with work that was being done badly, getting a useful result can be the reason to try it. Removing the manual writing matters too, but you don't need a measured hours-saving claim to explain why a better project record is worth testing.

You will still need to look at what it costs, including the time spent building and maintaining it. The Four Numbers can help you work through that, but don't turn continued use into a financial return you haven't measured.

Now, I want to be careful about which work you choose, because people disliking a task tells you nothing about how much harm a mistake could do.

Our summaries were client-facing from the start, used for planning and kept as project history, so a mistake could affect work beyond the summary itself.

They were always checked. The summary was saved in our system, the consultant would read it and then he could share it with the client.

So they weren't sent automatically without a check, and a wrong statement wasn't harmless just because I could fix the next version quickly.

That is why I would ask two questions together, how far can a mistake go before someone notices, and how quickly can we deal with it?

I've written about sorting AI work by what a mistake could cost, and that still applies. Starting with a client-facing task in our company isn't a recommendation for every firm to do the same.

So when you look for your first piece of work, ask the team what keeps getting put off, what came back late last week, what was finished but wasn't much use to the next person.

You're looking for something that repeats, with someone who needs the result and can look at an early version with you. A handoff note or a meeting write-up might give you somewhere to start, but you still need to check what could go wrong in your own situation.

Then write down what you think a useful result should contain. It doesn't need to be a long document, it needs to be clear enough that you can put a first version in front of someone and talk about what should change.

Expect to learn something from that conversation. We needed to see a version that was too long and another that was too thin before we got the summary into a shape people wanted.

And name the person who will make those changes before you ask the team to try it. They need to understand the system well enough to fix it, and they need time available to do that work.

From the user's side, reporting a problem takes time too. If they tell you what's wrong and nothing happens, they still have a client waiting, so going back to the old way can be a reasonable decision.

I've seen that happen. In one rollout, a user had trouble importing a couple of Google Meet recordings and went back to the older system without reporting it. He still needed to finish the work, and the import failures gave him a reason to use the system he knew.

So don't assume that silence means it's going well. Go back to the people who tried it, ask whether they're still using it and look at what they're doing with the result. Let them try it before you assume that wanting relief from the work means they'll trust your solution.

Starting with work people avoid is where I would look for candidates, based on what we experienced. Whether your choice works depends on what the output needs to do, what happens when it's wrong and whether someone keeps improving it after the first try.

And once it is useful, you may find that the next thing slowing the work down is checking it. We got summaries people could use, we didn't finish improving the whole company.

Before you buy another tool, ask your team for one piece of work that keeps arriving late or incomplete, and sit down with the person who needs it. Work out what would make it useful, then decide whether AI is a sensible way to get there.

AI Enablement Is a Loop, Not a Roadmap

Mon, 24 Aug 2026 13:00:00 GMT

You can give everyone in your company an AI tool, teach them how to use it, and still find that very little changed in the business.

And if that has happened in your firm, I would look at what happened after the training before deciding your people weren't interested. We have built tools that worked, did what we asked them to do, and still weren't something a person could use in their actual week.

That is the work I mean when I say AI enablement, getting the data into a usable form, changing the process, helping people work differently, and building or trying tools until the business gets a real result. You keep going around that loop because buying the tool doesn't tell you which part you got wrong.

Let me give you one of ours, because it explains this better than a definition does.

We built a tool that read sales meeting transcripts and scored the salesperson against a rubric, basically a written standard for what a good call should include. The supervisor could use that assessment to give feedback with something behind it, instead of relying on whichever calls he happened to hear.

The model read the transcripts, applied the standard and wrote the reports, so from the technical side it worked.

But the reports had far too much text, pages of assessment that the supervisor would have to read before deciding who needed help. We had given him more information without making it easier to do his job.

So we killed the reports and kept the scoring, with the low scores shown first. Now he could open the tool and see where to spend his attention, rather than read through everyone to find that out.

The first version wasn't completely wasted, the useful part survived. We had to put it in front of someone doing the work before we understood what to take away.

That is the loop, create something, people use it, adapt until it's useful.

And please don't hear one useful example and assume the rest came easily. We had over ten prototypes, roughly 100 hours of engineering and over 200 billion tokens spent on systems that never reached production adoption.

Those are our numbers, not a failure rate you should budget against. When we got things right, we had over 100 consultants using the tool daily and getting real improvements, but I don't have a measured performance percentage to attach to that.

The failed builds matter because they are part of what it cost to find something people would use. If your plan has money for software and training but nothing for those attempts, part of the job is missing from the plan.

When I looked at definitions of AI enablement, most of the emphasis was on getting the company ready. The Hackett Group says it “refers to preparing an organization to adopt and scale artificial intelligence as an integrated part of business operations.”

Upland Software calls it “the process of equipping organizations with the right technology, infrastructure, and connectivity to leverage AI effectively across their business processes.” And Straive calls it “the discipline of preparing every layer of an enterprise to deploy and sustain AI reliably.”

None of that is wrong, and the pages go beyond those opening definitions. Hackett discusses putting AI into workflows and performance management, Upland talks about tangible outcomes, and Straive says, “Adoption is signing the contract. Enablement is what makes the model useful.”

So my disagreement isn't that they forgot results existed. It is that an owner still needs to decide what result ends the work, otherwise getting ready can go on for as long as you're willing to pay for it.

A roadmap can name an assessment phase, a foundation phase and a pilot phase, and all three can finish without the work becoming better. My test is whether something useful changed in the business, and whether we can point to it.

That is harder to promise in advance. You don't know which version will work, so you need a plan that can change when the first one doesn't, not just a date when the program ends.

I'm talking about enabling AI across the company here, not sales enablement software, which is a different use of the word.

The confusion is real. In a Reddit discussion about AI enablement, someone asked how organizations define it and whether enablement leads help, and one reply was, “It seems like a complete waste of funds.”

I wouldn't use that comment to judge a job, but I understand the question behind it. If you can't say what the work changes, how does an owner know whether to keep paying for it?

The first explanation I hear when adoption stalls is often about the team, people aren't skilled enough, they aren't curious, they like the old way. What I have seen is that people have rarely been the main problem, most want the tools and are willing to learn.

Many are already trying. In Microsoft and LinkedIn's 2024 Work Trend Index, 78% of AI users were bringing their own tools to work, rising to 80% at small and medium-sized companies.

That is the shadow AI problem from another side, people didn't wait for the company to decide how this would work. The survey covered 31,000 people across 31 countries, it wasn't a study of firms exactly like yours.

Permission matters too. Slack's 2024 research found desk workers at companies with established permission to use AI were nearly six times as likely to have experimented, while a separate survey that year found 45% didn't have explicit permission.

Those are survey relationships, not proof that saying yes produces six times the adoption. But if your people are unsure whether they are allowed to use a tool on client work, that is something management needs to settle.

Now, wanting the tool and wanting your workflow changed are different things, and I see both sides of that. People can be happy to try AI and still dislike having to learn a different way of doing a job they already know.

Gallup's February 2026 survey gives that objection a number, 46% of non-users in organizations where AI was available said they preferred to keep doing the work the current way. The full survey covered 23,717 U.S. employees, not just service firms where someone was guiding a rollout.

So I am not saying resistance never happens. I am saying that giving people a tool and asking them to work differently creates a management job, and calling the team resistant doesn't do that job for you.

The four jobs inside AI enablement

The first is data design, which sounds more technical than it needs to. AI needs access to the information the work depends on, including the checks, exceptions and decisions that currently live in someone's head.

If a manager knows when a customer needs a different response but has never written it down, the tool doesn't inherit that knowledge because you connected it to the inbox. Documenting the process is part of making the information usable, not a separate exercise in tidiness.

Gallup found frequent AI use among 88% of employees who strongly agreed that AI fitted their systems and processes, compared with 55% of those who did not strongly agree, within organizations that made AI available. That doesn't prove integration caused the difference, but it is another reason to look beyond whether everyone has a login.

The second job is process redesign, deciding how the work should run now that AI can do part of it. Putting a faster tool into every old step can leave you with the same old process and one faster step.

In Microsoft's 2026 Work Trend Index, 45% of AI users said it felt safer to focus on current goals than to redesign work with AI. I understand that choice, because people still have work due while you're asking them to try a new way.

The third job is helping people through that change. They need time to learn, clear permission and boundaries, and a plan for what they should do with any time the tool frees.

That last part gets missed. If the report takes less time, should they take on more client work, fix a recurring problem, spend more time with existing clients? Somebody has to name the work, or the work around it takes the time back.

The fourth job is prototyping and testing tools, built or bought, on the work people actually have. You learn something from the attempt that you couldn't learn from a demonstration.

An interview study of ten experienced U.S. professionals using M365 Copilot found none named formal training as their main way of learning, eight learned through trial and error and six through tips from colleagues. It is a small exploratory study, not evidence that training is useless, but it describes why a course cannot do all the learning for you.

Across our unsuccessful builds, the problems were missing foundational data, solving the wrong problem, output people wouldn't use, and unreliable results. Those are different failures, and buying a stronger model doesn't answer all of them.

Missing data deserves particular care, because it can sound like a reason to spend months preparing everything before you try anything. The question is which data this particular job needs, and building a small version helps you find that out.

You still need to protect client information and understand the process before testing. But you don't need to make the whole company ready in the abstract before learning whether one supervisor can use the report you're proposing.

All four jobs need leadership behind them. That doesn't mean you personally write every instruction or fix every bug, it means somebody has the hours, the authority and the budget to keep working when the first version disappoints.

In the Production Gap, that missing authority is the Owner Ceiling. An employee can be very good with the tools and still be unable to change what the team is expected to deliver this week.

Who owns the loop

This is why AI enablement is bigger than training. Training can finish when the course finishes, the work of getting a business result cannot.

And I wouldn't take that as permission to buy less training. The 2024 Microsoft and LinkedIn survey found only 39% of people globally who used AI at work had received AI training from their company, so there was a real training gap too.

Gallup's May 2026 figures showed nearly half of U.S. employees saying their organization had integrated AI, while only 30% reported using it regularly. The page didn't state the sample size, and these weren't counts of purchased seats versus active seats.

The practical distinction is simpler than the surveys, someone finishing a course tells you they attended, not whether your delivery process improved.

Darlene Newman makes a useful argument that stopping at tool training leaves out the work of defining workflows, decisions and handoffs. Her line is, “Traditional enablement helps humans learn software. AI enablement helps software learn the business.”

I agree with the work she names. Where I would be careful in a small firm is turning each part into a separate role before you've worked out what needs doing.

In a 25-person firm, those jobs may fall to the same couple of people, including you. Hiring someone to run approvals won't replace having someone who can actually help the team when a tool breaks.

In the firms I've watched get this right, an existing employee often starts helping colleagues, sharing instructions and building small tools. I call them AI enablers, and I would look for that person before assuming you need a new title.

But they have to be ahead of the users and reachable. My team tells me what they tried and what went wrong because they know I can help fix it, and that gives me both a problem to solve and an idea of what they wanted the tool to do.

Without that response, reporting a problem becomes more work with no clear benefit. People go back to the old tool, and you may never hear why.

If nobody in your company can provide that help, close the gap, whether through learning, outside help or a hire. Don't pretend an enthusiast can carry a job they don't have the knowledge or authority to do.

Start with one piece of work

Pick a workflow where you can name the result you want, the hours a recurring task takes, the cost of delivering a service, the turnaround time a client keeps asking about. If you cannot name the result yet, deciding that is the first part of the work.

Then write down what the people doing that workflow know, the checks they make, the exceptions they handle, what tells them something is finished. Keep this about that workflow, not a project to document the entire company.

Build or buy the smallest version that could help and put it in front of someone on real work, with the checks that work needs. Give them a way to tell you what they tried and what broke, and make sure someone is responsible for answering.

When the feedback arrives, use it. Maybe you need better data, maybe the output is too long, maybe you aimed at the wrong problem, like we did when we gave the supervisor more reading instead of a way to find who needed him.

Adapt it and hand it back, then check whether the result you named is improving. A version people use is progress, but it isn't the whole result if the rest of the process takes back the saving.

On the Delivery Model Ladder, this is the work between adding AI to someone's existing job and rebuilding the workflow around it, Stage 1, Enhanced, toward Stage 2, Augmented. One of the Four Numbers asks what share of the hours AI freed has a named use, because the business needs that decision too.

This is hard and it can be expensive, you're changing tools, information, people's jobs and your own view of the business together. I don't have a formula that tells you which attempt will work, and my experience isn't a controlled comparison against firms that did it another way.

The loop needs enough repeated work to improve, somebody with authority to change it, and a result you can check. If the company is you and two other people, you're dealing with a different problem, how to divide your own work with AI.

And even in a larger firm, the person who carries the tools cannot carry the authority for you. Before you approve the next rollout, decide who can change the work when the first version teaches you something you didn't expect.

AI-Native Without Starting Over

Fri, 21 Aug 2026 15:06:30 GMT

You don't have to start a new company to make AI part of how your business runs. But you do have to pay for the part where the new way doesn't work very well yet, and that is where I see a lot of existing firms get stuck.

People try a tool, it fails on something they need, and they go back to the old system because the client is still waiting. The work gets done, so from your side nothing looks broken, except the tool you bought isn't being used anymore.

We had that happen with a tool we built, and we found out almost by accident.

It was connected to our project software and could pull notes from a customer's past engagements, so the answers were about that customer rather than whatever you could fit into a fresh chat. It gave us better answers and better material to work with.

Then one user hit a problem with a couple of Google Meet recordings, their transcripts didn't import correctly. He went back to the old system, which wasn't connected to the project records, and carried on working without telling us.

A few days later he mentioned a problem with the old system. Someone asked what he was doing when it happened, and that was when he casually said he'd stopped using the new tool because he'd run into a couple of problems.

He wasn't hiding it and he wasn't trying to resist the rollout. From his side a tool hadn't worked, so he'd used the one that did, and the client work still went out.

Think about what had to happen for us to find out, the old tool had to give him a problem too, and somebody had to ask the right follow-up question. If it had kept working, we might not have learned about the switch at all.

That is why I would look at where the work actually went, the files people created and the systems they used, rather than rely only on complaints or a question about whether the rollout is going well. A person who found a way to finish their work may not think they have a problem to report.

Now, there is advice coming from the startup world that can make this sound like a reason to start over. In Diana Hu's April 2026 Y Combinator talk, she describes an AI-native company, where AI is part of how the work runs, rather than a tool sitting beside it.

And in Charlie Warren's June 2026 talk about AI-native service companies, he warns against buying an existing services business and adding AI on top, calling that “generally a trap.”

He is half right. If you buy the firm, buy some licenses and leave the way it delivers work alone, the acquisition doesn't do the hard part for you.

But buying an existing firm and changing your own existing firm are not the same decision. His advice is aimed at people starting a company, and my question is what you do when you already have people, clients and a business worth keeping.

Hu does allow for existing companies building new systems through small internal teams, so I wouldn't say either talk proves that every established firm has to disappear. What the startup advice doesn't give your team is time to try the new way while the old commitments are still due.

A founder starting from nothing has far less old work to protect. In your company the old system is already there, people know it, and going back to it has no cost anyone is recording.

Trying the new tool does have a cost, the work done twice, the time spent asking for a fix, the risk of being late while you figure it out. If experimenting was never made part of the job, delivery is going to win that choice.

The user who went back wasn't stubborn, he was busy. We hadn't made the failed first tries a normal part of the plan, so we shouldn't have expected him to pay for them out of his own day.

This is the part you own, deciding how much room the company has to learn and what work will move to create that room. Your team can help you find the right tools, but they cannot quietly give themselves fewer client commitments.

Across the 150+ franchise units I watch through the network's delivery data, the picture recorded for this article was roughly 80% using chatbots, 15% using rigid workflows that run on triggers, and 5% using autonomous agents defined by conditions.

That tells you where those firms were, not how quickly they moved. I haven't measured the same firms moving between those groups over time, so I am not using that split as proof that everybody is making the climb.

Most were early, and that is okay. What I can tell you in more detail is what moving one task took, because we paid for it.

Meeting summaries were one of the first. Senior people read every summary, checking that the system hadn't made up a fact or changed what had been said, and we kept doing that for a few weeks.

Eventually those reviewers were convinced it was reliable enough and we stopped the full human read. That was the decision as it happened, senior people gaining confidence from reading the work, not a formal accuracy threshold that I can hand you.

I'm telling you what we did, not saying that confidence alone is enough for every task. A summary and a price you promise a client don't carry the same consequence if they're wrong.

Across the tuning work, we estimated as much as 200 hours of senior people's time over six months, based on material marked as reworked. It was small next to the manual labor the system removed, but it was real time from capable people and it hadn't been in the budget.

And the models improved while we were doing it. The larger models became more reliable during those same months, so I cannot give you a clean result where our tuning caused all of the improvement.

Some of what we got better at was our own process, and some of the improvement came from the tools getting better underneath us. Both helped, and the record doesn't separate them.

Other work followed, research review matching quotes to sources, data analysis moving from heavy human checking to agent reviewers, then competitor analysis and content creation. The four stages of reviewing AI work describes that progression, from being impressed, through checking everything, to a written standard and a more mature checking layer.

That is a practical answer to Warren's warning that customers will fire a company for inconsistent work faster than for being a little slower or more expensive. If the report is good one week and wrong the next, your client has to start checking you, and the service stops being what they bought.

We didn't replace the whole company at once. We learned what one task needed, then carried that learning into the next one.

I do think this gets harder as the firm gets bigger. There are more old systems to return to, more handoffs and more commitments competing for the time to experiment, and I haven't mapped a size-to-timeline rule that would tell you how much longer to allow.

So I would plan for the slow stretch rather than promise your team that a larger rollout will follow the same schedule as a small one.

Two parts of Hu's advice do carry over directly, and they are worth doing before you worry about whether your company deserves the AI-native label.

The first is to make the company's knowledge something AI can reach. Meeting transcripts, client notes, phone calls, WhatsApp messages, project files, decisions someone made out loud, those are the things your people use to understand a client, and a lot of them aren't in a usable shared record.

Write the process down, including the decisions and exceptions, instead of expecting an agent to discover what only your most experienced person knows. That is part of what makes a service business AI-native, and you can start without buying another license.

The second is to close the loop, which means the people using the system tell you what went wrong and somebody changes it. Sometimes the fix is a better instruction, sometimes a new tool, sometimes the company process needs to change.

But check the finished work, not just the system's account of what it did. We had a client status update pass our checks because a task was marked closed, then the client told us the work hadn't been delivered.

The records agreed with each other and they were still wrong about reality. The check needed the actual file or sent message, whatever delivery meant for that job, and that distinction matters before you give the system more freedom.

Hu also talks about removing the people whose job is passing information around. I have covered the important distinction in Fewer Managers, More Managing, because taking away tracking work doesn't take away the need for feedback, judgment and someone guiding the team.

Do those jobs well and Stage 3, AI-native, on the Delivery Model Ladder becomes a change you can work toward from inside the company you already have. It isn't something a new name or a bigger model bill gives you.

The bill is worth talking about, because some of the advice makes expensive usage sound like proof you're doing this properly.

Hu tells founders to be willing to run an uncomfortably high bill. StrongDM's software factory says that if you haven't spent at least $1,000 on tokens in a day per human engineer, there is room for improvement, while a16z's March 2026 article calls $1,000 per engineer per month “close to table stakes.”

Those are recommendations about software businesses, and the amounts aren't even on the same time scale. They aren't a budget for a service firm's workflow.

In April 2026, Pragmatic Engineer reported that Meta had removed its internal token leaderboard after a backlash. Shopify had renamed its leaderboard a usage dashboard and added circuit breakers to stop unexpected spending spikes from runaway agents.

You can see why that needed changing, spending is an input, not evidence that the work was worth doing. I wouldn't judge a consultant's report by how many pages they managed to produce either.

From our own delivery work, cheaper model tiers have run for under $500 a month in model costs while generating hundreds of client artifacts and deliverables. That is the model bill in that setup, not the total cost of running AI and not a promise that your work will fit the same budget.

Try the cheapest model that can do the task, compare it with a stronger model on the same work, and look at what people actually accept. We had a model bill fall about 23 times and still couldn't call the switch a win because we hadn't recorded equivalent quality or the human correction time.

The number you want is cost per accepted task, and the model rate card is one part of that. Failed attempts and the person fixing the result stay in the cost even when the API bill looks good.

Now let me take the objection I think an owner should make here. If the models got better while we were tuning, why not wait and buy the better version later?

You might avoid some of the rework, keep serving the clients who already trust you, and start when the tools need less attention. That isn't a foolish position, I just told you that some of our improvement arrived through better models.

But a better model isn't going to buy you a culture. It doesn't give your people practice in changing a workflow, reporting what broke, trying again and learning which parts of the work need a person.

That was part of what those weeks of checking bought us, people who had been through the change and had seen the work improve. They had a reason to stay with the next attempt instead of deciding that the first failure settled the question.

I don't have a settled management system you can adopt and have the whole firm understand by Friday. We are still learning how to organize this work, and waiting for the tools doesn't do that learning for you.

The experience and trust you already have are real advantages. You know the clients, you know the work, and you have relationships that a new firm doesn't get on its first day.

I haven't watched an AI-native newcomer take clients from an established firm in my network yet, so what follows is my forecast, not a measured case. I expect strong technology combined with real delivered value and competitive pricing to put pressure on those relationships.

Warren describes traditional services margins around 30% and the AI-native ambition as 50% plus. That is his investment thesis, not a measured margin promise, but you can see what a genuine cost advantage could pay for, lower prices or more work on the client's behalf.

Your history gives you time to respond, it doesn't remove the need to keep earning the relationship. I would treat that trust as a runway for the transition, including the training, the failed attempts and the waiting where a tool genuinely isn't ready.

Give the team room to make the change

Start by finding the people who already try tools and help colleagues, then give them a real hour a week on the clock for that work. That hour is a starting proposal, not a research-backed dose, and it needs to be booked like client work rather than stolen from the evening.

For the pilots that stuck in the franchise network's delivery data, training was 8 to 10 hours spread over about three weeks, with video courses, in-person sessions, Q&A and live technical help. That is what worked there, not a minimum I am promising will work everywhere.

Fund those hours and tell the team what the slow stretch is for before it starts. In the rollouts I've watched, getting to a checking layer people could trust took weeks to months, and some teams ran slower while they learned.

Don't call every slow week a failure, but don't ask people to keep going on faith either. Look at what is breaking, whether the fixes are helping and what the whole job now costs, including review.

And learn enough about the tools yourself to support the person leading the work. You don't have to write every integration, but you do need to understand the problems well enough to make decisions when the team brings them to you.

This needs some room in the business, money and hours, however small, and someone in leadership who owns the transition. If nobody can change the workload, the enthusiastic employee is still trying to do it around the job they already have.

They can carry the tools. They cannot carry the authority.

You can make this climb without starting over, I have watched firms do it. Just don't spend the runway waiting for the learning to do itself.

You Can Afford More Agents. You Can't Afford to Watch Them.

Wed, 12 Aug 2026 13:00:00 GMT

I have room to run more AI agents, the subscription has tokens left, the computer has spare capacity, and there is plenty of work I would like to get done. What I don't have is enough attention to keep following all of them.

That is a strange place to be, because everything on the screen looks like progress. Work is happening in several places at once, but I keep having to stop what I'm doing to decide what happens next somewhere else.

In the weeks leading up to August 6, 2026, I kept notes on how often I lost track of what I was doing. It happened about four times a day on average, usually while I was juggling more than ten tasks across projects, writing, debugging, messages and agents.

Not ten agents, ten tasks, and that distinction matters because the agent isn't the only thing asking for attention.

On a heavy day I might have terminals open across four projects. I open one to start something, another flashes because an agent needs me, and I go over there to deal with it.

When I come back, I can't remember what I opened the first terminal to do. So I pick up the next task and hope the missing one comes back to me.

Honestly, it is a little embarrassing to write that down. I first took it as a sign that I was getting bad at managing my own work, because the tools could clearly do more and I was the person slowing everything down.

But I noticed it as the number of parallel tasks grew, and I felt more mentally tired after those days too. My notes don't prove the extra tasks caused either thing, the lost threads were self-tracked and the tiredness was something I felt, not something I measured.

In conversations across a franchise network, operators reported a similar sharp rise in mental load as they used more agents. Those were conversations, not results pulled from delivery records, so I can't tell you how common it is or put a percentage on it.

What I can say is that buying more capacity would not address the problem I could see in my own setup. I needed fewer things waiting for my attention, or a way for some of them to finish safely without it.

The tools encourage parallel work, and there are good reasons for that. OpenAI's Codex launch post describes running many tasks in parallel, Claude Code's documentation describes separate worktree sessions, which let agents work on separate copies of a project, and Cursor's advice includes notifications so you know when an agent finishes.

None of that tells you how many unfinished tasks you can personally supervise well. The software can keep another task running without knowing whether you have room to think about its result.

And the same vendors say review still matters. Cursor puts it plainly, “The faster the agent works, the more important your review process becomes.” OpenAI's launch guidance says users still need to manually review and validate agent-generated code.

So the extra work doesn't end at generation, it comes back to someone. If you're that person, your attention belongs in the capacity plan as much as the computer does.

There is research that helps explain why this can be difficult, but I want to be careful about what it actually measured. None of the studies in this article gives us a safe number of AI agents for one person.

Sophie Leroy's 2009 work on attention residue describes how some of your attention stays with an unfinished task after you switch to another. You can move to the next window before your thinking has fully moved with you.

That is the part I recognize when a flashing terminal pulls me away. I dealt with the interruption, but the task I left was still unfinished and I had to work out where I was when I returned.

Nelson Cowan's working-memory research puts the central store at roughly three to five meaningful items in young adults under specific test conditions. It is a small amount of information to hold in mind at once.

But a memory item isn't an agent session, and a terminal isn't a fixed amount of thought. You cannot take that result and conclude that five agents are safe or that ten terminals are twice what a brain can handle.

The switching costs show up in work studies too. Gloria Mark and her colleagues found that interrupted work resumed the same day took an average of 25 minutes and 26 seconds to resume, with 2.26 other working spheres handled in between.

That is elapsed time before returning to the work, not 25 minutes of being unable to think. The distinction matters, because people were doing other work during the gap, just as I was answering an agent instead of doing the task I had opened the terminal for.

And in 10,000 recorded sessions from 86 programmers, only 10% had programming activity resume within a minute after an interruption. That doesn't mean the others were wasting time, it tells you that returning isn't always immediate.

The closest comparison in the sources is from supervising autonomous vehicles rather than software. In a 2007 study by Cummings and Guerlain, 42 U.S. Navy personnel supervised simulated missile strikes, and performance and awareness of the situation degraded at 16 vehicles.

The paper also discussed air-traffic-control work where performance declined at 17 aircraft compared with 10 or 11. It suggested 70% operator busy time as a useful threshold for predicting performance decline in that setting.

That isn't 70% of the day making decisions, it is total busy time, and missiles and aircraft aren't coding agents. I would not turn any of those figures into a rule for your company.

What carries over is the question, how much of the supervisor's time does each additional system demand? If a better tool reduces how often you have to step in, it can change how much you can supervise, which is why the number of windows alone won't give us the answer.

I also don't think the feeling of speed is enough to tell us whether the setup is working. Several tasks moving at once feels very productive, especially compared with waiting for one to finish.

In METR's early-2025 randomized trial, 16 experienced open-source developers worked on 246 issues in repositories they knew. With AI tools they took 19% longer, while afterward they believed AI had made them about 20% faster.

That is a historical result, not a verdict on today's tools. METR's February 2026 update said its later experiment couldn't give a reliable current estimate, in part because people who didn't want to work without AI were selecting themselves out.

So I am not saying AI makes developers slower. The useful point for this problem is that the feeling and the completed-work measurement can disagree, and I don't want to use one as a substitute for the other.

My dashboards didn't show the task I forgot to start. They showed the work that was running, which meant I had to count the dropped threads myself to see that part of the cost.

There is another part I worry about, the decisions. I catch myself handing more thinking to an agent when I already have too many things to follow, because accepting its suggestion is easier than rebuilding the whole problem in my head.

That is my experience, not a measured decline in decision quality. I haven't tested whether my decisions got worse or whether I lost any ability to solve difficult problems, and I don't want to turn that worry into a fact.

But I do want to separate two reasons for delegating a decision. One is that the agent can handle it within a boundary you've chosen, the other is that you don't have the attention left to think about it, and those are not the same reason.

Decide what still needs you

I see two possible directions, get better at following more things, or make more of the work able to run without constant intervention and keep fewer, more important decisions yourself.

Practice can make a workflow familiar, but task-switching research found costs that persisted even with preparation time. That doesn't establish an agent limit either, it just gives me no reason to assume I can practice my way out of every interruption.

My bet is on changing the work around the agent. An orchestrator assigns a task, a creator does it, and a validator checks the result, then the creator fixes what was rejected until it passes or reaches an attempt limit.

The useful part is that the task can reach a checked piece of work before it comes back to me. It doesn't need me to watch every intermediate step, provided the checking is good enough for that task and there is a clear point where it stops and asks for help.

That is not permission to let everything run on its own. Checkability and the cost of undoing a mistake help decide how much to delegate, and the cost of an error that escapes tells you where that freedom needs a stronger boundary.

A task waiting for my approval still belongs in the work I have to follow. A task that can run to a checked result without asking me for a decision doesn't need the same active attention, although somebody still needs to own failures and exceptions.

That is an operating distinction, not a claim that a background task takes up zero working memory. It is how I would decide what counts toward the active set.

On the Delivery Model Ladder, a human holding most of the review is a Stage 2 constraint. The four stages of reviewing AI work describes how that checking layer can change before you move toward Stage 3.

Use a cap while that layer is missing

I don't have this solved. I capped the amount of work I run at once because I could see myself losing the thread, and I didn't want to keep adding tasks just because the infrastructure could handle them.

Three to five open threads is a conservative first test I would consider, not a limit established by the research. Your jobs may demand very different amounts of attention, so the number needs to come from what you can actually follow.

Before changing it, count dropped threads for a week and note what was open when they happened. Then keep counting after you change the cap, because that is the part I failed to do.

I stopped counting after I imposed mine, so I don't have a before-and-after result. I also never measured my percentage busy time, and I can't claim the cap reduced mistakes or improved my decisions.

It gives me a smaller active set to watch, which is the direct effect of running fewer things. Whether it improved the work is a separate question that needs the measurement I didn't keep.

If you lead a team, I would ask the same question about the person reviewing your agents' work. The AI readiness assessment includes review capacity for that reason, because the company can buy more production than one reviewer can keep up with.

This advice applies where a person is still following the work and making the calls, not to every agent running quietly in the background. Better checks and fewer interruptions could let that person supervise more, and the sources here don't tell us how far that can go.

For now, before I start another agent, I want to know whether I'm adding work the system can finish or another decision that will come back to me. Spare tokens don't answer that question.

The 23× AI Cost Cut We Couldn't Call a Win

Mon, 10 Aug 2026 13:00:00 GMT

I moved one of our AI workflows to a cheaper model, the model bill fell by about 23 times, and I still couldn't tell you whether we had made the work cheaper to deliver.

Every run finished, the dashboard stayed green, and the saving was real. But we hadn't recorded whether a person accepted the work without fixing it, or how much time those fixes took, so the part that could have changed the answer wasn't in the record.

That is the mistake I want you to avoid before you switch a whole team to a cheaper model. You need to compare what it costs to get work you can use, not just what it costs to make the model finish a run.

Our example was one recurring, rule-bound email-to-task workflow. The average model cost per attempt went from $1.5474 to $0.0659, and those numbers came from a live production database on August 5, 2026.

The earlier model completed all 11 recorded attempts and the cheaper one completed all ten. Neither period recorded a failed attempt, retry or regeneration, so if you were only watching for technical errors, the switch looked finished.

Here is the full comparison, because the unknowns matter as much as the numbers.

Measure	Before	After
Model	`gemini-3.5-flash`	`gemini-3.1-flash-lite`
Period observed	July 7–21, 2026	July 22–August 4, 2026
Workflow attempts	11	10
Average model cost per attempt	$1.5474	$0.0659
Cost range per attempt	$0.0975–$3.2411	$0.0039–$0.1277
Average LLM calls per attempt	12.82	7.50
Failed attempts	0	0
Recorded retries or regenerations	0	0
First-pass technical completion	11/11	10/10
First-pass human acceptance	Unknown	Unknown
Human review or correction time	Unknown	Unknown

Calls per attempt fell too, which was another reason to look more closely. But the last two rows stop me from saying the cheaper model delivered the same quality or saved us money across the whole job.

A system finishing without an error means it reached the end of its instructions without reporting a problem. It doesn't mean it created everything the person needed, and it doesn't mean the output was correct.

Think about a report with a required section missing, or an email draft with a claim that nobody can support. The AI workflow can finish while a person still has to repair the result before it goes to a client.

That repair is work your firm pays for. If the cheaper model leaves more of it behind, you can lower the AI token cost and move the saving into a senior person's calendar without noticing.

And I am not saying that happened in this comparison. We didn't record the time, so I can't honestly say whether review got better, worse or stayed the same.

Reviewing AI work needs to be in the cost either way. The client doesn't get a lower standard because the model was cheaper, and the person doing the correction doesn't become free because their salary was already in the budget.

OpenAI makes the same distinction in its July 2026 guidance on cost per accepted outcome, a lower-priced model can need more attempts, correction or human review. Its separate AI scorecard includes employee time, review, retries and rework in the full cost of successful work.

The calculation I would use is the whole cost of the workflow divided by the number of tasks that met the written standard. Model usage, tools, infrastructure, review and correction all go in, including the cost of failed attempts.

In a sheet, that is:

Cost per accepted task = total model, tool, infrastructure, retry, review and correction cost / accepted tasks

Count each cost once, so if your model total already includes retries, don't add those model charges again under another column. You want the actual bill for the work, not a formula that accidentally counts part of it twice.

An accepted task has met the standard. First-pass acceptance means it got there without a person correcting it, which is useful to track separately because it tells you how much repair the model leaves behind.

If a task passes after correction, it can enter the accepted count, but the correction time stays in the cost. If it never passes, it stays out of the accepted count while everything spent on it stays in the total.

That is how you avoid making a weak workflow look cheap by counting all the attempts as useful work.

There was another problem with our comparison, the two models hadn't done the same jobs. Each daily run processed different emails and different amounts of work.

One run could contain a short email, another could contain several with many actions to create. So the averages included both the model change and whatever work arrived in each period.

The earlier model also wasn't judged with the same acceptance test. Two different sets of production days, with no human acceptance or correction time, cannot tell us whether the quality held.

Our records weren't useless, they did the job they were built for, showing whether the workflow ran, how many calls it made and what those calls cost. We were asking them a different question when we tried to use them to choose a model.

So I would keep the saving as a reason to test the switch, not as proof that the decision was already made.

Put both models on the same work

I would save ten jobs from this workflow, enough to include ordinary work and the edge cases it already has to handle. Ten is a practical first comparison for this repeated task, not a sample that proves the model is safe on everything.

Use saved copies, and remove identifying details where needed without changing the rules or difficulty of the job. Running the comparison on new live work would give each model a different day again, and you don't need that confusion in the test.

Run both models on every saved input with the same prompt, tools, context, limits and workflow version. Then mix the outputs and hide the model names from the person reviewing them, so the reviewer doesn't know which result is supposed to be the cheap one.

Write the acceptance checklist before either model runs. Otherwise a missing output can start looking like a small problem after you see an otherwise impressive result, and the standard changes around the work you wanted to like.

For this kind of rule-bound workflow, the first-pass rule is strict, follow all the input and exclusion rules, create every required output, add nothing incorrect or unsupported, and need no human correction.

The standard should describe the job, not how polished the result looks. A well-written draft doesn't compensate for a required project that was never created.

For every attempt, record what the model cost, how many calls it made, whether it retried and why it stopped. Then record whether the work passed on the first try, what was missing or wrong, how long review took and how long correction took.

Keep elapsed time too, because a result can meet the standard and still arrive after the team needed it. A model that is cheap overnight may not fit a job that needs an answer while the client is waiting.

Keep the record small enough to use

You don't need to build a reporting system before making this decision. Ten saved jobs run on two models gives you twenty rows, and a sheet is enough to hold them.

Each row needs the job and model, model cost, tool and infrastructure costs, calls, retries, stop reason, technical completion, first-pass acceptance, acceptance after correction, review minutes, correction minutes, missing or incorrect work, elapsed time and checklist version.

That sounds like a lot when I say it all together, but it is one record of what happened to one job. Most of the fields describe either the system's work or the person's work, and you need both to compare delivery cost.

Use one hourly labor cost that includes pay and employer costs, and keep the labor amount separate from the model bill. You will be able to see whether the cheaper model saved money or simply handed more work to the reviewer.

Don't build a permanent ledger just because you can. Keep this as a small comparison for the decision in front of you, and add the fields to regular reporting when model changes happen often enough to make that useful.

Then compare acceptance before comparing price. If one model misses a requirement, the lower bill doesn't make the requirement go away.

When both meet the same standard, compare total cost per accepted task and whether they finished in time. Set that decision rule before looking at which model won the cheaper column.

If the cheaper model doesn't meet the bar, you have more than one option. Keep the stronger model, fix the weak part of the workflow, or use the cheaper one only on a narrower task you can check properly.

The test is allowed to end without a switch. Its job is to help you make the decision, not to justify the saving you hoped to get.

A stronger model can cost more and leave less work for a person, while a cheaper one can be the better choice on a bounded job. That balance belongs to each workflow on your model rate card, not to one claim about the cheapest option for the whole company.

This method needs repeated work you can save safely and a standard someone can write down. Ten jobs won't settle a rare, high-consequence decision or work that depends on broad judgment, and I would keep human approval on those tasks.

For this workflow, the next move is still the same, save the ten jobs, write the standard, run both models blind and count the human work. Until that is done, the 23-times drop is a model-cost result, not a delivery-cost win.

Cheap Mistakes Go to AI. Expensive Ones Wait.

Fri, 07 Aug 2026 13:00:00 GMT

The task I would worry about first isn't always the difficult one. Sometimes it is the routine job that everyone agreed was safe to automate, because nobody is looking at it closely anymore.

A complaint about service gets tagged as a billing question, the system sends it to the wrong queue, and the people responsible for the account never see it. That sounds easy to correct, until you ask how anyone would know it needed correcting.

I have seen that happen in the franchise network's delivery data. A complaint from a major account sat unseen by the people who needed to act for 11 days, then the client called the consultant directly, asked to cancel and subsequently left.

I cannot say the delay was the only reason they left. I can say the complaint was missed for 11 days and cancellation followed, which was enough to change how that kind of message was handled.

Within 24 hours, cancellation language, threats to leave and strategic accounts were set to bypass normal classification. Ordinary billing questions kept going through the automation, because the fix wasn't to put every message back in front of a person.

The part we had priced badly was the exception, a message that looked routine to the classifier and mattered a great deal to the client.

That is how I would decide which tasks to give AI, look at the thinking the work needs and the worst realistic consequence if a wrong result gets through. Then look at the checks, how likely they are to catch it and how long the mistake could live if they don't.

Before automation, a person doing a simple task often noticed other things while they were there. The consultant writing a follow-up could notice that nobody had created the project, the account manager reading a message could see that the customer was getting ready to leave.

Those checks weren't necessarily written into the process, they happened because a person was already reading. When you automate the task, that person may no longer be there to notice.

And the system can look healthy while the work is wrong. In one recurring, rule-bound email-to-task workflow, ten consecutive runs recorded zero failed attempts and 10 out of 10 first-pass technical completions.

An automated reviewer checked three of those runs. One had processed an email outside its allowed time window, missed a required project, and left no evidence of a requested draft, while the other seven runs hadn't been reviewed at all.

That is not a measured failure rate for the ten runs, because we don't know what was in the seven unchecked ones. It is a concrete example of a run finishing successfully in the system while failing to do the whole job.

The check now looks for the expected project, tasks and drafts after each meeting and compares them with what was promised. A draft doesn't pass just because something called a draft exists, it has to be the draft the meeting called for.

We had a harder version of this with a client status update. The creator saw a closed task and treated it as completed work, then the validator checked the message against the task system and approved it.

Both agents agreed with the record, and then the client replied, “This hasn’t been delivered.”

So the check had to move beyond whether the task was closed. It needed the delivered file, sent message, published item, whatever actual completion meant for that work, and without that evidence the status stayed unresolved.

A second AI agreeing with the first didn't solve a bad definition of done. We had to change what counted as proof.

Most owners start with a different test, can I undo the mistake? That is a useful question, and Amazon's one-way and two-way doors make the same distinction, reversible decisions can have a lighter process because you can correct them quickly.

But correcting quickly requires knowing something went wrong. The complaint could have been moved out of the billing queue on any of those 11 days, the problem was that nobody responsible knew it was there.

So I would keep the undo question and add the one it doesn't answer, what tells us we need to undo it?

Across the cases I've watched get pulled back from automation, three things kept showing up. The failure was silent, the ordinary case hid a much more expensive exception, or a judgment call was buried inside what looked like routine work.

A payment reminder is a good example of the second one. The amount can be small, but if the message goes to a strategic account that already paid, the cost is in the relationship rather than the invoice.

And the status update shows the third, pulling data and writing a message sounds mechanical until someone has to decide whether the closed task means the work was delivered. That decision was inside the job even though we hadn't named it.

Those are observed patterns, not a complete list of everything that can go wrong. They are enough to show why I wouldn't sort work by the average mistake alone.

The cost can change after the workflow is running too. Meeting summaries started as a convenient way to skim a call, then people began opening the summary instead of the recording, proposals quoted it and scopes relied on it.

The summary had become evidence for other work without anyone changing the task that produced it. You need to look at the risk again when that happens, because a wrong sentence now travels further than it used to.

Sort the thinking and the consequence separately

The first question is whether the task mostly follows rules or needs experience and judgment. Sequoia's Julien Bek uses the terms intelligence and judgment for that distinction, with writing code to a specification, testing and debugging on one side, and deciding what to build or when to ship on the other.

That is an investor's way of framing the work, not a measured boundary. Applied to a service firm, I would put tagging, matching quotes to sources and some summary work on the rules-heavy side, while pricing, choosing a direction or deciding what quality to put your name on needs judgment.

The second question is what happens if a wrong result escapes the normal checks. A job can be easy for AI to perform and still be expensive to get wrong.

If it is rules-heavy and the consequence is low, let the system run and sample the results. Internal drafts and routine tagging can fit there, provided they aren't quietly becoming evidence for something more important.

If the rules are clear but the consequence is high, let AI do the work and require proof or approval before it leaves. Invoices, quotes, client messages and status updates need a check that matches what could go wrong.

Where judgment matters but the consequence is low, AI can give you options, shortlists or a first pass at a plan, and you choose. Where both judgment and consequence are high, you decide and AI prepares the brief, as with pricing or ending a client relationship.

Better checks can earn more freedom for the system, but they don't make the underlying mistake harmless. A false invoice doesn't become cheap because a validator is good at catching it, the validator changes how often the false invoice gets through.

That is why I keep consequence separate from the quality of the controls. Otherwise we can start calling dangerous work safe because we've forgotten the condition that was keeping it safe.

An earlier piece uses checkability and undo cost to choose how much freedom to give an agent inside one task. Jina Yoon's autonomy levels at PostHog use those same two tests.

This sort comes before that, across the company's task list, what thinking does the work need and what happens if an error gets through? Once you know that, you can design the check and decide how much the agent may do on its own.

Make the check earn its place

I have watched meeting summaries move from human review to agent review, research checks start matching quotes to references automatically, and data analysis move away from heavy human checking. Competitor analysis and content creation followed a similar path as the checking layer improved.

That doesn't mean errors became impossible. It means the work no longer needed the same full human read to be useful, and the checks had taken over part of that job.

The strongest implementation I have seen uses three roles, an orchestrator assigning work, a creator producing it and a validator checking it. The creator fixes what the validator rejects, and the loop runs until the work passes or an attempt limit stops it.

But remember the status update, that loop can miss two agents agreeing with a bad source. The correction had to demand evidence of delivery, not another opinion about the same closed task.

Attempt limits are useful for another reason, they show you where the work repeatedly fails to settle. If a task keeps reaching its limit, the inputs may be broken or there may be a judgment call nobody wrote down.

Fix the input and the task may stay automated. Find a judgment call and the better job for AI may be preparing the information for a person rather than trying repeatedly to make the decision.

I don't have a universal acceptable hit rate to give you. The pattern is a reason to investigate, not a percentage another firm should copy.

And building these checks costs real time. We estimated as much as 200 hours of senior people's rework over six months, using material marked as reworked, while the system was being tuned.

That cost was small next to the manual labor removed, but it wasn't zero and it wasn't a standard budget for every firm. The time to build the checking belongs beside the time it eventually saves.

Putting a senior person in front of every output can be necessary while you learn what fails, but it isn't a free permanent answer. At volume, you either stop doing the full review or turn your senior people into proofreaders.

The work with serious consequences keeps the proof or human signoff it needs. Routine work needs a less expensive way to discover what passed through incorrectly.

Check work the system says is finished

If you only count reported failures, you're counting what somebody happened to notice. You don't know what is still out there looking successful.

The approach is to audit a random sample of completed outputs every week, comparing them with the source material and what actually happened. An escape is an incorrect result that passed all the normal checks before the audit found it.

Then keep two numbers, sampled escape rate and time to detection. The sampled escape rate is the incorrect outputs that escaped divided by the number you audited, not divided by everything the system produced.

Time to detection is how long each escaped error lived before somebody found it. A wrong update found before the client acts on it and the same update found after other work relies on it can have very different costs.

The first number tells you what passed through in the sample, the second tells you how long it had to cause trouble. Neither makes the unchecked work known, and a small clean sample doesn't prove that every output was correct.

Start with one weekly sample and follow the work all the way to reality. A status update needs delivery evidence, a meeting follow-up needs the project, tasks and draft it promised, and a quote needs the current cost table.

When you find an escape, add the smallest check that would have caught that kind of error, then keep sampling. Your normal checks cover the mistakes you know about, the audit gives you a chance to find the ones you haven't named yet.

And change the route for the expensive exception rather than assuming the entire task must go back to a person. The complaint classifier can keep handling ordinary messages while cancellation language bypasses it, payment reminders can keep running while top accounts and larger amounts get another check.

The status update can still be written automatically too, but it doesn't get to call something delivered without evidence. That is a narrower and more useful correction than declaring that AI can't write status updates.

Start with ten tasks

Write down ten tasks AI already touches in your firm and go through them with the person who used to do the work. That person often knows the checks you lost because they were the one making them without being asked.

For each task, decide whether it follows rules or needs judgment, what the worst realistic escaped mistake could cost, and what actual output proves the job is complete. Then ask how long an error could survive and which finished outputs you will sample.

If the honest answer is that you would only find out when a client complained, give that task a stronger control before you give it more freedom.

You probably won't have clean numbers at first. Make the first estimate, start the sample and improve the decision from what you find, rather than wait for a perfect picture before admitting the blind spot exists.

Sorting ten tasks can take an afternoon. Building the checks takes as long as the work requires, and the person who owns each check needs the authority and time to act on what it finds.

As that improves, consultants can spend less time copying information and writing routine first drafts, while senior people spend more time on the ambiguous cases and decisions that need their judgment. Work sold with senior signoff should keep that promise, not quietly turn into routine AI output with a different label.

This approach needs something you can check and a named person responsible for the decision to release it. If the work lives in verbal handoffs and a shared inbox with no reliable record of completion, sorting the tasks correctly won't give the system evidence it doesn't have.

While you still read most of what goes out, you are already the checking layer, although an expensive one. Before you stop reading everything, decide what will notice the mistakes you used to catch just by being there.

The Four Stages of Reviewing AI Work

Wed, 05 Aug 2026 13:00:00 GMT

Your team can produce more with AI and still take longer to get the work to a client, because somebody has to check everything that is now arriving faster.

And when a bad piece of work has already reached a client, I understand why that person starts reading every line. They aren't being difficult, they are using the control they have, and the hours you thought AI would save are going into that review.

What I have watched in service firms is a progression through four stages, marvel, panic, rubric and maturity. People start by trusting too much, then checking everything, then giving AI a written standard to check against, and eventually needing less human review as the whole system improves.

The third stage is where the work changes, but getting there takes time and the company can run slower while it learns. If you don't plan for that part, a team can stop just when it is beginning to find out what the system needs.

Let me take you through the stages, because the answer isn't to tell your reviewers to be less careful.

Marvel, when the output is enough

At first people are impressed by how much the tool can produce. A report appears quickly, it reads well, and the work gets sent on without much checking because it looks like the job is done.

This is harder to see when the AI use is unofficial. If nobody knows how a piece of work was made, they may not know which checks it needs, so they use the old process and assume the person producing it already did them.

The problem isn't that every output is wrong, it is that nobody can explain what would stop a wrong one. Ask who or what checked the last deliverable and the answer is often unclear.

That is part of the Production Gap, the difference between a tool making something impressive and a process delivering work you can depend on.

You don't have to go through a client-facing failure to learn this. You can build the checking alongside the new workflow, even though the sequence I have watched often begins without it.

Panic, when everything gets read

After something goes wrong, the team starts checking. A partner reads the reports line by line, sometimes another person reads them too because nobody is quite sure who is responsible for the final approval.

The work is faster to create and no faster to send. Senior people stay late, the same documents come around again, and the calendar starts filling with review rather than delivery.

Most firms I see are in some version of this stage. That is my observation, not a measured share of all firms using AI, and I don't think the people doing it are wasting time on purpose.

If the last wrong number reached a client, reading the next report carefully is a reasonable response. The owner has to give the reviewer a better way to check the work, not ask them to ignore what happened.

Atlassian described a similar pattern in its 2026 State of Teams research, which included more than 12,000 knowledge workers and more than 170 Fortune 1000 executives. Among those executives, 89% said AI increased the speed of work, while only 6% felt confident pointing to organization-wide returns.

Those are survey responses from a much larger-company setting, not a measured result for a service firm like yours. The part I recognize is the description of output backing up at reviews, approvals and other points that still need human judgment.

Hiring another reviewer can help, and I would not tell you that extra capacity never matters. Queueing theory explains why delays can rise sharply when the person doing the review is nearly fully booked, and adding capacity can bring that load down.

But a queueing formula doesn't prove another hire will only help a little, or buy you a fixed number of months. That depends on how work arrives, how long review takes and whether the new person can actually take over the same decisions.

The question is whether you are building review into the workflow or adding people who must keep rereading everything the workflow produces. If output keeps growing while the checking stays a full manual read, the staffing problem can keep returning.

That is the kind of moving bottleneck I have written about before. More capacity can relieve the queue, and changing the checking can reduce the amount of work entering it, those are different jobs.

Rubric, when the standard becomes part of the workflow

A rubric is a written standard for what acceptable work looks like. The next stage is having AI do much of the checking against that standard, with people handling the parts the system cannot settle.

You aren't asking a model whether a report seems good. You are checking its claims against sources, its statements about a client against the client's records, and its output against the errors the team has already seen.

In the systems I've worked with, four parts did much of that work, agents checking online facts, agents checking client data, checks for known error patterns, and guardrails for recurring language or logic mistakes.

An eval scores the result, while a guardrail can stop work from passing a boundary when a rule is broken. You need the checks to do their actual jobs, not just attach a score or a warning that nobody acts on.

The improvement comes through feedback from the people doing the work. Operations mark a piece of work as defective, implementation gets the feedback, works out the fix and ships a new version, then operations test again.

Marking a defect can take seconds. Finding and fixing the cause can take much longer, so I wouldn't turn the quick feedback step into a claim that the whole process is cheap or pays for itself immediately.

What makes it worth doing is that the same defect no longer has to be repaired by hand every time, once the fix works. The firm already spending hours reviewing bad output has a reason to invest some of that effort in changing what comes back next time.

Both sides have to take part. The person seeing the defect needs an easy way to report it, and the person receiving it needs to be able to change the system while the feedback is still useful.

A list someone opens once a month doesn't give you that response. The team needs to see that reporting a problem changes something, otherwise the report becomes another task they do while the bad work keeps arriving.

I have watched teams get slower during this stage, because a new system made mistakes and people had to check it while it was being improved. The firms that persisted and got the fixes working saw the gain after weeks to months of tuning.

That isn't a guaranteed recovery period. A slow rollout can also have the wrong tool, bad data or a workflow that isn't worth automating, so keep looking for evidence that the errors are falling and the work is improving.

If nothing changes after several attempts, investigate what is breaking instead of telling the team to be more patient. They are responding to the work in front of them, and you need to show that the next version is better.

In the franchise network's delivery data, across many projects, one week with more than 300 artifacts had roughly 95% fewer marked as carrying incorrect information after tuning, compared with that same system as first implemented.

That is a result from a tuned system with several checking layers and people feeding the improvements back into it. It isn't 95% accuracy for an AI reviewer, it isn't a comparison with a human reviewer, and it isn't a benchmark I can promise your firm.

The distinction matters because an AI checking another AI is still capable of missing the same mistake. A score that says the output is good needs its own test against errors you know are there.

A 2023 paper on ChatGPT as a factual-inconsistency evaluator found that in five of its six datasets, it could identify more than 95% of consistent summaries while performing poorly at finding all the inconsistent ones. In other words, being good at passing correct work didn't mean it was equally good at catching incorrect work.

In the 2023 HaluEval study, ChatGPT scored 58.53% accuracy on the summarization task, classifying whether a summary contained hallucinated information. The authors described that result as “barely above chance.”

Those were specific tests of models available in 2023, not a current ceiling on AI review. I use them as a reason to test the checker on wrong work, not as evidence that every model you could use today is close to a coin flip.

And a longer checklist isn't automatically a better one. Rubicon's 2025 research, which used rubrics in model training, found that indiscriminately adding more rubrics produced only marginal gains.

A separate 2025 Rubrics as Rewards study found rubrics generated with reference answers produced performance comparable to human-written rubrics in its HealthBench experiment, while generation without those references did worse. That is training research in medicine and science, not a service-firm review trial, so the business advice is my application of it.

Give the model examples of acceptable work and a real standard from someone who knows the job. I would rather spend an hour with the reviewer who catches the most errors than ask a model to invent a long list of things that sound like quality.

Maturity, when review gets smaller and better aimed

As the rubrics improve, models get stronger and the system has more history to compare against, the full human read can become less necessary for some tasks. That is the fourth stage I have watched, more quality work delivered with less review around it.

It doesn't mean nobody is responsible anymore. People still handle the work that needs judgment, the exceptions the system flags and the checks that cannot safely be left to a model.

The four review stages aren't the same numbering as the Delivery Model Ladder. Building checking into the workflow is part of the move from Stage 1, Enhanced, toward Stage 2, Augmented, on that separate ladder.

And these stages are a description of a pattern, not a scorecard for ranking your firm. There is no promised date when every task reaches maturity or a requirement to remove human review to prove you've arrived.

Sometimes a better model lets you remove a guardrail because it no longer makes the mistake that rule was catching in your tests. You still need to check that on your work rather than assume a new model release makes the rule unnecessary.

The model may cost more while leaving less work for a person. A cheaper one may still be the right choice when its mistakes are easy to catch and repair, so measure the model cost and review cost together.

That balance changes by task and by firm. The endpoint isn't the cheapest model or the smallest number of human checks, it is work that meets the standard at a cost the business can support.

And when review time does fall, decide what that time is for. The same thing that happens with faster production can happen here, the surrounding work absorbs the hours unless someone changes what the team is responsible for doing next.

There is one more reason to keep a record of the checks, it gives you an honest answer when a client asks how the work was made.

My position is that you don't need to advertise AI use simply for the sake of a label, but you must never lie about it. Follow the client's terms and any rules that apply to your work, and don't describe human review that didn't happen.

Thirteen experiments published in 2025 found people who disclosed AI use were trusted less than those who didn't, including in analyst-type work. Different wording and making disclosure voluntary or mandatory didn't prevent that effect in those experiments.

But the same research found a stronger trust penalty when the AI use was exposed rather than disclosed. I would not read that as advice to hide it, especially when your client is relying on your account of who did the work.

A 2026 study of 370 marketplace users found consumer reviews labeled AI-assisted were judged more favorably than those labeled AI-generated. That doesn't measure how your clients would react to a professional report, but it is another reason to describe the work accurately instead of treating all AI involvement as the same thing.

You only get to say someone checked it if someone did. The wording isn't a substitute for the validation.

The courts give us one historical example, not a general rule for every profession. In June 2024, the Fifth Circuit declined to adopt a special rule for AI-drafted briefs “at this time”, and reminded parties and counsel that they remained responsible for the accuracy of their filings.

That describes the court's decision then, not its entire rulebook today. Other courts and professional rules differ, and Ropes & Gray's court-order tracker is a place to look up that variation, not a reason to assume disclosure is optional in your case.

For the service-firm version, the one-page AI policy keeps the answer straightforward, client terms decide disclosure and the answer to a client's question is the truth. Build the record so you can explain who checked what without having to reconstruct it afterward.

This method needs work that repeats enough for someone to describe a useful standard. A one-off strategy engagement may still have parts you can verify, but deciding whether the recommendation is right can remain the actual service a person is being paid to provide.

It also needs someone who can improve the implementation when operations report a defect. Without that person, you have a queue of problems and a team still doing the same full review around them.

That is why human review can remain at the fourth stage, smaller and aimed at the decisions that need it. Removing every human check isn't the goal.

Pick the deliverable your firm produces most often and ask who or what checked the last one, then sit down with that reviewer and write down what they actually looked for. That gives you a place to start building the standard instead of another instruction to read faster.

Your AI Employee Has a Rate Card. You Set It.

Mon, 03 Aug 2026 13:00:00 GMT

I had an agent doing work in a production system I run, and the work cost twenty times what it needed to because I had picked a model that was more capable than the job required.

I changed it within a few days, because at that price the system wasn't going to pay for itself. The work stayed the same, the output quality held, and the bill fell to one twentieth.

That's what I want you to look at before you decide an AI employee is cheap or expensive. The model you choose, how hard you let it think, how much information it can reuse and where it runs all change what you pay for the same job.

You have more control over this bill than you probably realize, and somebody in your firm needs to use it.

When you staff an AI employee, you add a cost that grows as it does more work. A salary usually stays the same through a quiet week and a busy one, at least until you need overtime or another person, but each new agent run can add to the bill.

Service firms already have costs that vary with the work, of course, contractors, outside services, all sorts of things. What is different here is how much the price of doing the same task can change when you change the settings underneath it.

Let me give you the numbers from my system, because a bill you can picture is more useful than a warning about runaway AI costs.

Across 2,000+ agent tasks in a production system I run, in July 2026, the middle cost for an active user conversation was about eight to nine cents. The average was seventeen to eighteen cents, because some expensive tasks pulled it up.

More than half of the user queries cost between two and ten cents. A customer service summary came in at about eight cents, a full project analysis at fourteen cents, and a monthly sales review at $1.57.

Those are different jobs, so please don't take the cheapest one and use it to price everything your team might ask for. The most expensive single task I saw in that set was a project run that cost $16.12.

At the other end, an automated monitor running in the background cost about a tenth of a cent per run. A daily collections nudge cost a fraction of a cent too, so the gap inside one system was much wider than the average makes it look.

Now, if I include those cheap background monitors in the calculation, the middle cost drops to about three cents. If I count only the active user conversations, it's back around eight or nine.

Neither number is dishonest, but they answer different questions. Before someone tells you what an AI task costs, ask what they counted as a task, because you can't compare one person's background checks with another person's project work.

It's the same discipline behind the Four Numbers, a number is useful when you know what went into it. Otherwise the next month can look better just because the system did more cheap checks, even if the work you care about got more expensive.

And there is something about my setup you need to know before using these figures as a comparison. I optimize heavily for caching, which means the system can reuse information it has already processed instead of paying the full rate to process it again.

That is part of why these costs are low. Even within my examples, the effective cost per million tokens, the small pieces of text the model processes, ranged from about three cents to thirteen cents in the cases I compared, so counting tokens alone would not tell you the bill.

You shouldn't expect my exact prices from a system built differently. They describe my workload and my settings in that month, not a price list for your firm.

The first setting I would look at is the model. That was my twenty-times mistake, and it didn't need a new business process to fix, it needed someone to look at the work and ask whether we were paying for more intelligence than it required.

We don't need Einstein to fetch data from a website. We do want a capable model helping us read a customer report and flag the inconsistency we don't want to discover in a client meeting.

Those jobs should not get the same choice by default. For the website task, use the cheapest model that reliably gets the right data, and check what it brings back.

For the report, the price of missing something matters too. A model that saves a few cents and leaves your senior person fixing the report for half an hour has not made the job cheaper.

Then look at the reasoning setting, how hard you ask the model to think. Where that setting is available, the same model can spend more or less effort on the task, and you need to see whether the extra effort improves the result enough to justify the cost.

Caching is another choice, because repeated company instructions and background information can be arranged so the system reuses them. That is work for whoever builds or maintains the system, but as the owner you should know whether anyone has looked at it.

And you can change where the model runs. Open-source models on your own hardware have a different cost structure from a cloud service, but the hardware and the person maintaining it aren't free, so I would not start there if the whole bill is only a few hundred dollars a month.

There is one combination I particularly want you to try before replacing every cheap model with an expensive one.

Use a cheaper model to do the work, then have a stronger model check and guide the result. That second model is a validator, and it runs on the output rather than doing every step itself.

I've found that this can give you a better result than the cheap model alone while costing less than using the stronger model throughout. Adding a check sounds like adding cost, but it can let you lower the cost of the much larger part of the job.

You still have to test that combination on your own work. If the checker misses the same mistakes, or sends everything back for another attempt, you need to count that too, not assume that two models are automatically better than one.

ICONIQ's 2026 State of AI snapshot describes companies sending most workloads to smaller or fine-tuned models and reserving the strongest models for the harder tasks. That point comes from operating perspectives in its community, alongside a survey of around 300 executives building AI products, not a controlled test of my setup.

The human version is the named validation gate, where someone is responsible for deciding whether the work clears the standard. The machine check helps that person, it doesn't take away their responsibility for what reaches a client.

So how do you put this underneath a retainer without letting one busy month eat the fee?

Start by separating what the client buys from what it costs you to deliver it. The client can buy a finished outcome, a block of capacity or an ongoing service at a stable price, while you track the changing agent cost inside that price.

Software vendors do versions of this too, but read the unit they charge for carefully. Fin lists $0.99 for resolutions, configured procedure handoffs and disqualifications, while qualifications cost $9.99, and it charges only once per conversation.

That handoff detail matters. A conversation simply passed to your team without an outcome is free, but a procedure you configured to finish with a human handoff can be billable, so "it reached a person" does not mean "we won't be charged."

Zendesk describes pricing by automated resolution. Salesforce's May 2025 Flex Credits announcement priced an action at ten cents, and those are different billing units, not prices you can put side by side as if they buy the same thing.

Anthropic's guide to its usage-based Claude Enterprise plan describes another version, a seat fee for access with usage billed on top. The useful distinction for you is the one between access and consumption, not copying another company's contract.

A vendor handling huge volumes can spread variation across far more work than a small firm can. But a small firm can still sell a fixed fee responsibly, provided the scope, expected use, review work and spending limits are part of the decision.

For the budget, use the average cost for the mix of tasks you expect, multiplied by the number you expect to run. The middle task tells you what is typical, but it leaves out the effect of the expensive work, and the bill includes that work too.

At seventeen to eighteen cents on average, a thousand comparable conversations would cost roughly $170 to $180. That is an illustration using my July workload, not a quote for a thousand of whatever your clients might request.

Then look at the worst tasks when you set limits. Put a ceiling on spending per run and per engagement, decide how retries stop, and decide who gets called when the limit is reached, because the most expensive task you've seen is not a guarantee about the most expensive task you'll ever see.

To put the scale in perspective, imagine $175 of monthly agent spend supporting a $5,000 retainer. That's 3.5% of revenue, and it is only the agent-spend line, not the full cost of delivering the engagement.

Bessemer's discussion of 50% to 60% gross margins for AI companies, compared with 80% to 90% for SaaS, is about businesses selling AI products. You cannot take that comparison and tell a service-firm owner that a small agent bill will push their company into the same margin range.

And a retainer does not keep the gain by itself. You still need to choose what you sell and how you price it, because a lower delivery cost and a higher fee are separate decisions.

For most service engagements I would keep the agent spend in the internal cost sheet rather than create a new invoice line for every run. The client is buying the result, subject to whatever disclosure and billing terms you've agreed, and you need to know whether that result pays before you promise more of it.

I also expect the workload to change as people get better at using the system. In my experience, heavy users ask for harder work and pull the average up, while cheaper and more capable models can push the cost of a comparable job down.

I don't know which force will win in your firm. ICONIQ also reports rising internal AI spending as a share of revenue as adoption matures, but that does not tell us what the next month of your service work will cost.

That is why this needs a standing owner rather than a setup you never revisit. I expect cost-tuning responsibilities to grow, but at your size that doesn't have to mean hiring somebody with a new title.

Give someone already responsible for the system a monthly review of spending by task, what changed, what got rejected and what needed another attempt. Thirty minutes is a reasonable place to start that review, not a promise that every problem it finds can be fixed in thirty minutes.

This is part of the move from Stage 2 toward Stage 3, where the firm can take on more work without adding people at the same pace. Some responsibilities appear as the work changes, and owning this bill is one of them.

Before your next review, pull last month's agent spend, split it by task and look at the average alongside the typical and most expensive runs. Then ask whether the model and the checking step were chosen for those jobs, or whether you're still using whatever somebody picked in the first week.

That was my mistake. You don't need to keep paying for it.

Your Team Isn't Resisting AI. Nobody Gave Them the Hours.

Fri, 31 Jul 2026 13:00:00 GMT

When a company asks me to help with an AI rollout and tells me the team is resisting it, I don't start by trying to change the team's attitude. I want to know what happened when they tried to use it, and where in the week they were supposed to learn.

Because in the rollouts I've been called in to fix, what got called resistance turned out to be something else, a tool that was too complicated, a system designed around the wrong work, training that didn't keep up, or nobody giving people the time and help to get through the first attempts.

You can give everybody a login and tell them AI matters, but if the client work stays the same and their targets stay the same, you haven't given them a way to learn it. You've added another thing to a week that was already full.

I call that the Unfunded Hour, and if you're the owner, this is a decision you can do something about.

Think about the person whose work is already booked. The client is waiting, the manager can see whether the job is finished, and the hours spent on it show up in the numbers the firm reviews.

Learning the new system has no place in that plan. Even if the person believes it will help later, they still have to choose what to do now, and the work with a deadline wins.

That doesn't mean the team is incapable of learning, it means they are following the priorities you've made visible. If you want a different choice, some of the work or some of the target has to move.

The research gives you a reason to take that answer seriously. In Study.com's March 2026 survey of 1,000 US employees, 41% named lack of time as a barrier to getting better at AI, the most common answer.

Two-thirds said two hours a week or less would meaningfully improve their skills, while 36% said their employer provided paid time to learn. Those are employee reports, not a measured training prescription, but they describe a gap you can check against your own calendar.

And this wasn't simply a group waiting to be ordered into training. Only 9% named an employer requirement as their main reason for learning, with improving their work and personal curiosity much more common reasons.

Study.com sells training, so it has an interest in this problem. Still, the time issue appears elsewhere, Skillsoft reports that 58% of leaders and 59% of individual contributors named lack of time as the biggest barrier to building new skills.

You may be thinking that AI has already saved you so much time that your team should be able to find a couple of hours. Let me show you why I wouldn't use your own experience as the answer for everyone else.

Section surveyed 5,000 white-collar workers at companies with at least 1,000 employees, in the US, UK and Canada, in late 2025. As the Wall Street Journal reported, 40% of non-management staff said AI saved them no time, compared with 2% of the C-suite.

Those are large companies, not a direct measurement of a firm your size, and the answers are self-reported. But they should stop you from assuming the person running the business and the person doing the client work are getting the same benefit from the tool.

Two-thirds of non-management staff in that survey saved less than two hours a week or no time at all, while more than 40% of executives said they saved over eight. An owner can honestly think the tool is wonderful while a team member honestly cannot see where the promised time went.

So where would I find the learning hours? I would look at the training time the firm already has before asking for a new budget.

SPI Research's 2025 professional-services benchmark reports 9.2 guaranteed training days per employee in its 2024 figures. On an eight-hour day, that's about 74 hours a year, and ten hours of AI training would use roughly one seventh of that pool.

That is the benchmark, not a claim that your firm has 74 unspent hours waiting in an account. Check your own plan, see which hours are available and which commitments can move, then put the training where people can actually attend it.

The same caution applies to utilization, the share of working time billed to clients. Deltek's summary of SPI's benchmark puts it at 66.4% in 2025, but the remaining time is not automatically spare time.

People still sell work, run the firm, handle admin and meet commitments that don't go on a client invoice. You need to look at that work rather than announce that a third of the calendar is free.

If there is no training time to reassign, then funding it means making a real capacity decision. I would rather you face that cost before the rollout than quietly leave people to pay it with evenings and weekends.

And I would book general AI learning as a firm cost, not pass it to a client as if it were delivery they asked for. Any client-funded training needs to be part of an explicit agreement, not a surprise line on an invoice.

Now, how much AI training do employees need? I can give you the pattern I've seen, and a research finding beside it, but they are not the same kind of evidence.

BCG's 2025 AI at Work survey, covering more than 10,600 people across 11 countries and regions, found regular use was sharply higher among employees who received at least five hours of training and had access to in-person teaching and coaching. Only about a third said they had been properly trained.

That is an association, not proof that five hours causes somebody to become a regular user. It does tell you that buying access and preparing people to use it are different things.

Across the franchise delivery work I see, the pilots that stick usually get 8 to 10 hours of training over about three weeks. That includes video courses, in-person sessions, questions and answers, and live support from the technical team while people try it on real work.

I'm describing a pattern from those pilots, not promising that ten hours will make any tool work in any firm. The job you picked and the system you built still matter.

But notice the shape of the training, because the hours alone aren't the whole story. People learn something, use it, find the part that doesn't behave as expected, and have somebody available to help before they give up and return to the old way.

A video can help with the first part. It cannot answer the question someone brings after trying the system on their own client work, and one afternoon doesn't give you that cycle across several attempts.

You also need to check what people can do, not just ask whether they feel confident. In the Study.com survey, 34% reported confidence using AI, while 18% said they consistently produced high-quality output with little editing, and both figures are self-reports rather than an outside assessment.

There is a useful historical warning from METR's early-2025 developer experiment. Experienced developers believed AI had made them about 20% faster, while the measured result was that they took 19% longer on the tasks in that study.

METR's February 2026 update says those older speed results should not be treated as the current effect, and selection problems prevent a reliable estimate from its newer data. I keep the example for the gap between feeling faster and being faster, not to claim your team will slow down by the same amount.

That is also why skill and benefit are different from who adopts first. Opening the tool is a start, it isn't the result you're paying for.

And even funded training can stop in the wrong place. Teaching someone to get a nicer draft out of a chatbot can help that task without changing the rest of the job, and the saved time can disappear into checking, rework or other work nobody planned to change.

That's the problem in the extra time AI buys you is already gone. For this rollout, keep your attention on the piece of work you're trying to change, not just on how well people can prompt.

The Section respondents most commonly described using AI for search replacement and drafts, with fewer using it for analysis or coding. The same Wall Street Journal report described a separate Workday survey of about 1,600 employees, in which 85% reported saving one to seven hours a week, with much of the benefit offset by correcting and reworking AI output.

Those are separate surveys, so you can't combine them into a calculation of lost time. They do give you a useful question for the training plan, will people learn the whole new way of doing the job, including checking the result, or only the fast first step?

An AI system attached to a defined role and workflow asks more of the firm than a chat window does. Across the 150+ franchise units in the delivery data I review, the recorded split was roughly 80% chatbots, 15% rigid workflows and 5% autonomous agents defined by conditions, not a picture of the whole market.

On the Delivery Model Ladder, the move that matters here is from making individual tasks faster to changing how the work runs. Training needs to prepare people for that change, who checks the output, when the system stops, and what the team does with the time it frees.

BCG's 2026 survey reported frontline regular use rising from 51% to 74%, while the share reporting adequate training was 36%, still close to the roughly one third reported in 2025. Adoption can move much faster than the support around it.

I've also watched pilots get announced rather than run. People see a demonstration, receive some instructions, and then the people responsible for the system wait for somebody to report a problem.

Let me tell you why I don't trust that last step. I have seen a SaaS tool I use every day break and never reported the bug to the people who made it, so I can't expect everybody else to be a perfect source of feedback either.

If your new AI system needs constant correction and nobody tells you where it failed, it can stay broken until people stop opening it. Go back to the team, look at what happened on real work, update the training when the agent changes, and make reporting a problem easy.

In Study.com's survey, 56% of the people who had received AI training said practice on real work was the biggest thing missing. Generic examples won't tell your team how to handle the client task waiting for them after the session.

And don't confuse capability with permission. A written AI policy tells people which tools and uses the firm allows, while training helps them do the permitted work well, you need both.

There is a counterpoint worth keeping in the room. In the Section survey, 40% of all respondents said they would be fine never using AI again, and non-management workers were more likely to describe anxiety or overwhelm than excitement.

That isn't proof that missing training caused their feelings, and it doesn't disappear because another survey found curiosity. The populations and questions differ, and someone can want to get better at a tool while wishing it wasn't part of the job.

So ask about the job anxiety too. Explain what you're changing and invite people into documenting, testing and improving the work, rather than treating every objection as an attitude you have to overcome.

Managers often need their own version of that conversation. In my experience, operational teams tend to engage quickly when they can see a direct benefit, while managers and supervisors can take considerably longer and need dedicated training time.

The tracking work is familiar, reading spreadsheets, running numbers, checking status. When an agent takes that over, the manager is left with more of the judgment work, feedback, mentoring, one-on-ones, helping people improve, and often no written way to do it.

You haven't made the manager less capable, you've changed what their week needs to contain. Leadership has to help them learn and organize that work, which is the harder part of fewer managers doing more managing.

For your next rollout, pick one workflow worth improving and name the person who owns it from start to finish. Find the training hours, move the other commitments that would consume them, and spread the learning across real attempts with help available.

Use the 8 to 10 hours over about three weeks as a starting point from my experience, then adjust to what the work requires. Give managers material for the part of their role that changes, and keep someone responsible for following up on problems and results.

If the workflow isn't worth changing, more training won't make it worth changing. And if nobody owns the whole job, the training can improve individual skill while leaving the operation where it was.

Before you diagnose resistance, ask the people who aren't using the system what happened when they tried, and whether they had time to try properly. If it doesn't help with their work, fix that problem, and if they haven't had the hours, change the week you gave them.

Document the Process First, or the Agent Scales the Chaos

Wed, 29 Jul 2026 13:00:00 GMT

The first time we tried to put AI into a delivery operation I was running, we built an agent that impressed everybody, and then nobody knew what to do with it.

The model could do the work we showed in the demonstration. What we hadn't managed to give it was a clear description of how the operation actually ran, so we had a powerful tool and no meaningful change in the business.

That is why I tell owners to document the process before giving an agent responsibility for it. If the job still lives in people's heads, the software doesn't know the job just because it can give you a good answer.

And I don't mean writing a large manual about how everything ought to work. I mean getting the checks, decisions and exceptions your managers already use into a document the system can read.

When I first asked our managers to explain their workflows, the questions sounded straightforward. What do you do to monitor the consultants, what do you check, how do you keep track of tasks and projects, what tells you something is going right or wrong?

Getting the answers down was one of the biggest challenges. These were people doing the job every day, but they weren't used to taking what they knew and putting it on paper for somebody else to follow.

That distinction matters, because it would have been easy to call the problem resistance. The managers weren't bad at their jobs, the firm had simply relied on them carrying the process in their heads, and now we were asking a machine to work without access to it.

We built the agent anyway, and the prototype was impressive. But an impressive prototype that doesn't change the delivery operation is still on the wrong side of the Production Gap, the gap between a working demonstration and a system the business can depend on.

If you've had a pilot like that, I would look at what job you gave it before assuming you need a better model.

Your project tool can show the tasks and your CRM can show the account, but neither necessarily tells the whole story. There may be a side spreadsheet, an approval in a message, or a rule the manager follows because something went wrong with a client once.

That is part of the process too. If the agent can only see the official version, it can miss the part that keeps the real work moving.

In Reworked's April 2026 article on process documentation, platform engineer Pavan Madduri described an agent trained only on the official workflow in the ticketing system as "learning a fantasy." He was talking about infrastructure, but the gap between the recorded process and the working one is familiar in service delivery too.

You don't fix it by listing every possible case you can imagine and pretending the list is complete. Write down what the manager is looking for, which information they use, what a signal means and when somebody has to make a decision.

For example, "check the project" doesn't give the system much to do. The useful part is what you check, whether a task is overdue, whether the client has gone quiet, whether something in the last meeting suggests the engagement needs attention.

And it needs to know what happens next. Does it produce a report for the manager, ask for missing information, or stop and wait for a person because the next decision is outside its role?

Once we managed to get that knowledge into a document, the same effort started producing useful work. Triggers started reports, and those reports warned managers to step into a project or give a consultant feedback.

That was the change I had been looking for. The agent was no longer waiting for somebody to think of something to ask it, it had a piece of the operation to watch and a reason to act.

There are twelve conditions in the network example, drawn from how management runs the work. They include overdue tasks, churn signals from customer meetings, the quality of WhatsApp responses, opportunities to sell useful additional work, and overdelivery signals.

By overdelivery I mean noticing an artifact worth producing that would improve what the client already bought. The system can bring the opportunity to somebody's attention, and a person still decides what the engagement needs.

None of those conditions came from a vendor's generic list. They came from management knowledge that had to be made available to the system.

Compare that with a manager opening a chatbot and asking it to draft a check-in email for a client. The email can be perfectly good, but the manager still had to notice the client needed attention and start the task.

When the system watches the condition and warns the manager, it takes over part of that noticing work. That's a meaningful difference between a chat tool and an AI employee with a defined job, even when both produce an email at the end.

Across the 150+ franchise units in the delivery data I review, the recorded split was roughly 80% using chatbots, 15% using rigid workflows that run on triggers and 5% running autonomous agents defined by conditions. That is a picture of those units, not the whole service industry, and it will change as the tooling rolls out.

I wouldn't tell you that documentation alone explains the split. It was a necessary part of getting our own system to do useful work, but access, checking, training and the way the firm uses the output matter too.

The wider research helps explain why process work deserves attention in the first place. In Asana's 2023 Anatomy of Work index, knowledge workers reported spending 58% of their day on coordination and other work about work.

They also estimated they could save 4.9 hours a week with better processes. Those are survey responses from knowledge workers across several countries, not measured savings from AI or a promise about what documenting your firm will return.

But you can see the kind of work to investigate, the time spent finding out what's happening before anyone can do something about it.

Now, the first document won't be complete. People leave things out because the step is so familiar they no longer notice they're doing it, and real work will find gaps you didn't find in the interview.

This is where an AI agent is different from the expectation many of us bring to buying software. We expect to configure a product and use it, but getting an agent to do your firm's work takes a period of trying, reviewing and correcting the system around it.

You put a first version into controlled use, get people involved in testing it on real work, and read what happened. Look at the conversations, the errors, and the things the agent couldn't do.

Then update the software, the documentation and the rubric, the written rules you use to judge whether the output is good enough. Repeat that process as the next set of problems appears.

The documentation is easy to forget in that loop. Someone fixes a prompt or adds a check, but the description of the job still says the old thing, and now the system has two versions of how the work should run.

Keep them together. The output-validator workflow explains the checking side, but the person responsible for the process also needs to keep its written description current.

And please don't hear "try it while it's still unreliable" as permission to send unchecked work to a client. The team can test real work with review and clear limits while you learn what the system can handle.

In my experience, keeping everybody committed through that period is harder than building the first version. You need people to keep trying, report what failed and help you get to the output the business needs, rather than judge the whole project by the first awkward attempt.

The work has more than paid off in the cases I'm describing, but I can't give you one timeline that every firm can use. The pace depends on what the job requires, the gaps you find and how quickly the team can make and test changes.

So if you want to start, don't send your operations lead away with "document your workflow" as homework and wait for a perfect file. Sit with the person doing the work and ask them to walk you through it while somebody writes.

Start with what they check each day and each week. Ask how they monitor the people doing the work, where they look, and what they notice that wouldn't be obvious to a new person.

Then follow how tasks and projects get tracked. If the answer involves a message thread or a spreadsheet outside the main system, write that down too, because the agent won't know it exists from the process chart.

Ask what warns them that something is going right or wrong. Stay with one example long enough to understand which information made them act and what they did next.

For one important deliverable, ask how they know it's good enough before a client sees it. That starts the rubric, and "the manager checks it" is not the answer yet, you need to know what the manager checks.

Then ask where the hours would go if the system did one of those checks for them. The time needs a job too, or it can disappear into the rest of the week without improving the business.

That's a useful first document. It doesn't have to describe the whole company, it has to describe one piece of work well enough that you can test what you've written against what actually happens.

On the Delivery Model Ladder, that makes it possible to move beyond individual tool use and rebuild a workflow. The AI readiness assessment asks whether that foundation exists, and it comes before the changes to managers' jobs in Fewer Managers, More Managing.

There is one limit you need to settle first. If nobody owns the delivery process from start to finish, and nobody can explain what should happen when it crosses between teams, writing is not your first problem, ownership is.

And at the size of firm I'm writing for, I would start with that manager conversation before looking at enterprise process-mining software. You may need tools later, but you can learn a great deal by asking the person who already keeps the work moving.

Writing the process down does not put an autonomous agent on your delivery team. It gives you a job you can finally hand over and test.

What Is an AI Employee?

Mon, 27 Jul 2026 13:00:00 GMT

An AI employee is a software role that starts work when something needs doing, has access to the information and tools for the job, and produces work that gets checked before somebody relies on it.

That's the definition I would use as an owner, because the useful question isn't whether a vendor calls its product an employee. It's whether your firm has given the system a job it can do without a person having to start and explain every step.

You don't just buy the software and get that role. You have to staff it, define what it does, give it the right access, decide what starts the work and build a way to check what comes back.

And somebody in your firm still owns the result. Calling software an employee doesn't give it responsibility for the client relationship.

Let me show you what the difference looks like in the work, because from a demonstration the two versions can look very similar.

A manager opens a chatbot and asks it to draft a check-in email for a client. The email is good, and it saves the manager some writing time, but the manager had to notice the client needed a check-in first.

In the network example I work with, a condition watches for projects that have gone more than four days without a client touchpoint. The system can alert the manager about those projects without waiting for the manager to remember to look.

Now the software is doing part of the noticing as well as producing the report. That is the work I want you to see, because writing an email faster and making sure the right client gets attention are different improvements.

There are twelve conditions in that example, all drawn from how management runs the operation. They include overdue tasks, churn signals from customer meetings, the quality of WhatsApp responses, opportunities to sell additional work and overdelivery signals.

Overdelivery means something worth producing that would improve what the client already bought. It still needs judgment about whether to do it, but the system can bring the opportunity to the person who makes that decision.

Watching those conditions manually across the work would take staff time that was hard to justify. The system makes that monitoring practical, provided somebody maintains it and checks that the signals still mean what we think they mean.

In the franchise delivery data I review, across 150+ units, roughly 80% were still using chatbots, 15% had moved to rigid workflows that run on triggers, and 5% were running autonomous agents defined by conditions. That is our recorded split in that network, not an estimate of every service business using AI.

The shares move as we roll out tooling. I haven't seen a firm with a working agent go back to a chatbot, but that is what I've observed in this work, not a promise about every implementation.

There is a related finding in the Census Bureau's 2026 study of AI diffusion, where 66% of AI users relied on it solely to augment tasks. The study covered a different population and used different categories, so it doesn't validate my percentages, it gives you another view of how limited a firm's use can be even after it adopts AI.

So if you are looking at an AI employee for your firm, I would ask for four things, and I would start with the job.

Describe what it is responsible for in one sentence. A proposal first-draft role is a job, an engagement coordinator watching the firm's conditions is a job, and a research associate working against the firm's files is a job.

A list saying it can write, search, analyze and send messages doesn't tell you which of those jobs it is supposed to do. You wouldn't give a new hire that list and expect them to work out their responsibilities, and the agent needs the same clarity.

Then give it ongoing access to the systems where that work lives. It may need the project tool, inbox, CRM, files or company knowledge base, with access limited to what its job requires.

It also needs the relevant context, what happened with this client, which price was agreed, what decision was made last time. If somebody has to paste all of that into a new conversation before every task, the person is still carrying a large part of the role.

The third thing is what starts the work. It could be a schedule, a condition, a system event, a Slack message or a WhatsApp audio, whatever is appropriate to the job, but it can't depend on somebody remembering to open the chat window every time.

And the fourth thing is a validation method, a way to check the output before a human spends attention on it. That is where I see the hardest work, and where a lot of the buying conversation stops too soon.

A product can supply tools for all four things. It cannot decide your firm's scope, access boundaries, operating signals and quality standard for you without learning how your work runs.

The market's names don't make this easier. Digital workers, AI agents and AI employees come from overlapping ways of selling automation, so the label alone won't tell you what you are getting.

Automation Anywhere describes digital workers as virtual employees combining AI, machine learning, robotic process automation and analytics to automate business functions. That term comes from the automation world, where a lot of work followed fixed rules and screen steps, and a changed screen could break a bot following those steps.

An AI agent generally uses a model and tools to work toward a goal across several steps. The task can be simple or complicated, and that alone doesn't tell you whether it has been set up to carry an ongoing role in your company.

Then you have the role-based product names. Artisan sells Ava as an AI BDR, a business development representative, 11x markets digital workers, and Salesforce uses the language of digital labor.

Those are descriptions of what the companies sell, not evidence that the product is ready to do your job in your firm. I wouldn't spend much time arguing over which label is correct, I would ask what the system starts, what it can reach, what it produces and how that work is checked.

In June 2025, Gartner called the relabeling of assistants, chatbots and older automation without substantial agent capabilities "agent washing"

That relabeling is agent washing.. It estimated that only about 130 of the thousands of vendors claiming agentic AI were real, its estimate at that time, not a count I have independently audited.

The four questions are more useful to you than trying to identify which side of that vendor count a product belongs on.

Now I want to stay with validation for a bit, because "our team reviews everything" sounds responsible, and it can still leave you with an expensive system.

If the agent produces more work and every basic check lands on the same senior person, you have made more material for that person to sort through. They can spend the day reading work they didn't do, and the time saved upstream gets consumed in review.

A script can check arithmetic, required fields and whether links resolve. Another agent can look for contradictions or challenge an answer, and a written rubric can say what should be present in the output.

Those checks have limits, a working link doesn't prove the source supports the claim, and an AI checker can be wrong too. But you can catch a lot before the senior person gets the work, leaving their attention for the parts that need judgment.

Human review stays. It just shouldn't be the first place you discover that the numbers don't add up or a required part of the report is missing.

I've seen reports with incorrect numbers nearly go out. I've watched agents get lost in a task, use the wrong tool for thirty minutes, and return thin or broken work after we pushed toward cheaper models to contain the cost.

That last part matters, because these aren't only mistakes a vendor made somewhere else. Keeping the bill down was part of our own work, and we had to improve the system around the model to make the output good enough.

I call that surrounding system the harness, the instructions, tools and checks that guide the agent and catch problems in what it produces. The model is important, but swapping the model is not a substitute for doing that work.

You won't anticipate every failure when you write the first rubric. You put the system into controlled use, see what goes wrong on real tasks, then improve the instructions and checks so those failures are less likely to recur and easier to catch.

That loop is part of what you are building. A vendor can help you build it, but a vendor that has never seen your deliverables cannot hand you a finished test for what your firm considers acceptable.

After our first version went live, we reached consistently good output in about four weeks. That depended on an engineering team built around AI, able to diagnose problems from past agent sessions, make fixes in minutes and usually deploy them within 24 hours.

Without those conditions, four weeks is not a number I would give you. I'm telling you how that implementation went, not how long every AI employee takes to become useful.

The part that took longest wasn't the engineering. It was finding enough curious, engaged people willing to put their actual daily work through the system, because a demonstration doesn't expose the same problems as a real task somebody needs finished.

Those people need time and support to test it. If you expect them to do all the old work and quietly absorb the failed attempts as well, you're leaving out part of the cost.

The other cost is writing down what good work looks like. What has to be in the output, what would make it wrong, what distinguishes a version you can accept from one you send back?

In my experience, service firms often pass that standard from person to person without writing it down. It lives in review comments, in the way a partner rewrites a paragraph, and in the corrections somebody makes without explaining the rule behind them.

That can work between people who have spent years together. It's much harder to build a dependable agent around a standard that only appears when someone says "I wouldn't send that."

The writing is useful beyond the AI system. A clear standard gives a new hire something to learn from and gives reviewers a common basis for the decision, though the document only helps if people use and maintain it.

That's part of the shared context on the Delivery Model Ladder, and part of what makes a service business AI-native. The company changes how information moves through the work, rather than simply putting a better tool on each desk.

The cost of the agent runs and the fee you charge the client are separate questions. I would keep them in the cost and pricing discussion, rather than assume an employee-shaped product name tells you anything about the economics.

For the firm's progress, the useful distinction is whether the workflow changed. A chatbot helping an individual sits around Stage 0 or Stage 1 on the Ladder, a rebuilt workflow belongs at Stage 2, and condition-driven agents with shared context can support the move toward Stage 3.

You don't earn a stage because the vendor says its software is autonomous. If the team still copies the context in, starts every job and checks every detail by hand, that is the operation you have to measure.

Use the Four Numbers to see whether the change reached the business. Proposal and research work may affect cost to acquire, while delivery work may affect cost to deliver, and in either case you have to count the checking and rework too.

Then ask what the freed time is being used for. If you don't name that work, a faster task can leave the firm with no more useful output.

Retention depends on what happens to the client experience and quality. Price changes when you change the offer or the fee, not because the agent exists, and revenue per person is a result to watch rather than a promise from the software.

The surveys show why I wouldn't mistake experimentation for a finished operating change. In McKinsey's 2025 State of AI survey, 62% of respondents said their organizations were at least experimenting with agents, while 23% reported scaling an agentic system somewhere in the organization.

In any one business function, no more than 10% reported scaling agents. Deloitte's Tech Trends 2026 discussion cited 11% actively using agentic systems in production, a separate sample and a different measure, not another version of our franchise split.

I see several ways the gap between a good demonstration and useful work can persist. The most important here is what I call the Quality Debt Spiral in the Production Gap, output grows faster than the capacity to check it, and mistakes collect where nobody is looking.

Sometimes the pilot never leaves the demonstration. Sometimes several people build their own versions with different rules, so the firm has no shared standard, and sometimes the dashboard counts prompts and completed runs while nobody checks whether the business improved.

There is also the Headcount Reflex, more demand arrives and the firm adds the same role it expected the system to take pressure off. That isn't proof the hire was wrong, it is a reason to ask whether the planned change to the work ever happened.

And staffing an AI employee is not a layoff plan. The Census study reported AI-related employment decreases in only 2% of firms in its sample, which describes that survey period, not what your next staffing decision should be.

The effect on hiring and lost work deserves its own conversation. You can't answer it by comparing the agent subscription with a salary and leaving everything else out.

Gartner's June 2025 release also forecast that more than 40% of agentic AI projects would be canceled by the end of 2027 because of cost, unclear value or inadequate risk controls. That is a forecast, not a failure rate that has already been measured.

In the operation with the twelve conditions, the manager's job changes when the system takes over finding out what happened. The person spends less time compiling the picture and more time deciding what to do about it, a hard conversation, coaching, a change to the way a client is being served.

That's the shift in Fewer Managers, More Managing. The tracking can shrink while the need for a person to manage the team remains.

So when the next vendor presents an AI employee, ask them to show you what starts the work without someone opening a chat. Ask what systems and context it can use, and what access has to be supplied or restricted by your firm.

Then ask for the job in one sentence, and the checks that happen before a person reads the output. If the final answer is simply "your team reviews it," include the cost of that review in the decision instead of treating it as free.

Those questions test the proposed role. For the wider question of whether your firm is ready, the AI readiness assessment covers the operating conditions around it.

There is a limit to all of this that I don't want to hide. Checking a calculation is very different from checking whether a strategy recommendation is good, and work that can be checked reliably is easier to hand over than a whole client judgment.

I don't have a general method that turns every consulting deliverable into something a script can approve. The aim is to let senior judgment reach more work, but that depends on being honest about which checks are reliable and which decisions still belong to a person.

In my own experiments, agents get much stronger when they can use the company context, the written rules and the tools people already rely on. I've been running groups of agents that coordinate and produce work I judge good enough to put in front of a client, but that remains my experimental work, not evidence that every professional-services role can now run on its own.

Start with a role you can describe and work you know how to check. Keep the human responsibility attached to it.

AI Layoffs Can Start With the Clients You Lose

Fri, 24 Jul 2026 13:00:00 GMT

If you run a service firm, I wouldn't read every AI layoff headline as a preview of what happens when you give your own team the tools.

AI can replace work and people can lose jobs because of it, that part is real. But your firm can also lose jobs because somebody else gets better at serving the market and you stop winning enough work to keep the team busy.

That's the risk I want you to look at alongside the tool itself. From my perspective, the safer question is not just how many people AI could replace, it's whether the way you use it helps your company keep winning and delivering work.

I've watched hundreds of service firms adopt AI through a franchise network's delivery data, and in the first half of 2026, more than one client told me they were gaining market share.

When I asked about what had changed, I found a connection to AI tools, redesigned processes, faster delivery and a clearer view of their own data. Better outcomes, better Google reviews, more referrals, more business, that was the chain I could see.

I'm describing those clients' experience and what I found when I probed it. I don't have a study showing how much of their competitors' lost work was caused by AI, or how many jobs those competitors then cut.

But you don't need to pretend that part is measured to take the operating risk seriously. If your clients get a better result somewhere else, your own decision not to automate doesn't protect the work they're paying you for.

Now let me give the layoff numbers their proper place, because I am not dismissing them. In Challenger, Gray & Christmas's report covering the first half of 2026, employers cited AI in 101,743 announced job cuts.

That was about 23% of all cuts announced in that period, and roughly 85% more than the 54,836 AI-cited cuts reported for all of 2025. In June, AI led the reasons listed for the fourth consecutive month, those are the June report's figures, not a running total through today.

The important word is "cited." Challenger records the reasons employers give, it doesn't audit every job to establish whether AI replaced it, whether the business was already cutting costs, or whether several things happened together.

The job loss is real for the person affected. The explanation still needs more care than treating every mention of AI as the same event.

And a layoff count won't show you every change in the team. A firm can delay a budgeted hire, leave a vacancy unfilled, or decide not to bring in juniors before it announces a single cut, so I wouldn't use the tracker as the only way to understand employment either.

There is serious evidence of pressure on younger workers, and it belongs in this argument. Stanford's Digital Economy Lab revised its Canaries study in August 2026, using ADP payroll data covering millions of US workers through June 2026.

It reported that employment among workers aged 22 to 25 in AI-exposed occupations stood 19% below where it would have been had it kept pace with their less-exposed peers. Experienced workers did not show a comparable gap.

That is a relative employment gap, not a finding that 19% of all young workers lost their jobs. The study also found declines concentrated in occupations where AI use mainly substitutes for tasks, rather than complements workers, but the authors call these descriptive indicators, not causal estimates.

So yes, entry-level work deserves attention. I wouldn't reassure a junior by saying that firms can grow with AI and therefore their particular role is safe, because a growing firm can still change which people and skills it needs.

There is another side to the evidence, though. A Journal of Financial Economics study of AI investment from 2010 to 2018 found that AI-investing firms grew faster in sales, employment and market value, with product innovation explaining much of that growth.

That period predates the current generative-AI wave, and the growth was concentrated among larger firms, so I wouldn't treat it as a forecast for a small consultancy. It does show why automating some tasks and growing the workforce are not opposites.

PwC's 2026 AI Jobs Barometer reports faster headcount growth at companies most exposed to AI than at those least exposed, along with productivity growth that is 40% higher. Exposure means the work is more open to AI's effects, it is not the same thing as a measured rollout at every firm.

PwC's read is that AI can expand jobs when firms use it to open markets and create more value. That's a reason to examine the growth route, not a guarantee that buying tools causes a company to hire.

The size distinction is useful too. A 2026 Atlanta Fed working paper drawing on nearly 750 CFOs found large companies expected to shed workers because of AI while smaller firms anticipated modest employment growth.

Those are expectations, not hiring outcomes the researchers later observed. Separately, the paper links productivity gains with innovation and demand, rather than cost reduction alone, and I would keep those two findings separate.

A 2025 US Chamber of Commerce survey reported that 82% of small businesses using AI had increased their workforce over the preceding year. Again, that is an association in a survey, not proof that AI created each of those jobs.

The reasonable conclusion is that adopting AI does not require your headcount to fall. What happens to demand, what you sell and how you use the capacity all matter.

You can see the mechanism in an older example. James Bessen's account of ATMs for the IMF describes banks needing fewer tellers per urban branch, from 20 to 13 between 1988 and 2004.

The branches became cheaper to run, and banks opened 43% more urban branches over that period. Teller employment did not fall in the way the task-automation story alone would have led you to expect, while the job shifted toward relationship work.

That is a historical example, not a claim that banking employment stayed protected forever. The useful part is the extra demand that became practical when the cost of serving it fell.

For a service firm, the equivalent might be work you couldn't price before, more clients you can serve without sacrificing quality, or a faster turnaround that helps you win an engagement. The savings have to help you reach that work, not just leave the same team doing the same amount in the same week.

Apollo chief economist Torsten Slok calls this the Jevons employment effect from AI, cheaper professional work can expand the market for it. In his April 2026 note, he also pointed to unusually high US business formation and read AI as a likely contributor, his interpretation rather than proof of the cause.

That's why the destination of the saved time matters so much. If nobody decides what the capacity is for, you haven't made the growth side of the argument happen.

And cost reduction on its own can take you somewhere you didn't intend. In February 2024, Klarna said its AI assistant was doing the equivalent work of 700 full-time customer service agents.

That is Klarna's workload-equivalent claim, not a verified count of 700 people dismissed because of that assistant. By May 2025, about fourteen months later, the company was recruiting human agents again, including a freelance-style pilot.

CEO Sebastian Siemiatkowski said, "As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality."

Klarna still described itself as AI-first, so this was not a complete rejection of the technology. It was a public admission that the balance between cost and service quality needed changing.

IBM's account shows a different use for savings. Its AskHR system automated 94% of simple, routine HR tasks, such as vacation requests and pay statements, according to reporting quoting IBM's HR technology leadership, while a couple hundred HR roles were absorbed.

CEO Arvind Krishna said, "Our total employment has actually gone up, because what [AI] does is it gives you more investment to put into other areas." The areas he named included software engineering, marketing and sales.

These are two company accounts, not a controlled comparison of the same tool. They show different decisions about what to preserve and where to put the resources, and neither guarantees what happens to a service firm your size.

But the quality question is even closer to home when the service is what you sell. A lower cost doesn't help much if the client stops trusting the answer, and automating the preparation doesn't remove your responsibility for the judgment in the deliverable.

Now come back to the firm losing work, because its AI-related problem may not appear in an AI layoff announcement at all.

In my client observations, nobody described a formal announcement that customers were switching to an AI-native provider. The changes showed up in outcomes, reviews and referrals, the ordinary ways one firm becomes easier to recommend than another.

There is an older account from the other side. In January 2024, a person posting as the owner of a content development agency wrote, "Slowly, but steadily, we are losing clients to ai. We do produce strategy etc, but all writing jobs are going to the bots. I have had to lay off writers."

That is one person's account, not audited business data, and it predates the 2026 figures above. It also describes clients choosing AI instead of buying writing, which is different from choosing a competing agency that uses AI better.

Both routes matter to the owner, but we should not merge them. A customer doing the work themselves and a customer moving to another service firm can both reduce your demand, even though they tell you different things about what to change.

The broader pattern of productive firms pulling ahead is older than generative AI. An OECD study from 2016, using firm data through 2014, found the most productive firms gained market share relative to less productive firms.

That doesn't measure today's AI-driven share transfer. It gives the forecast a historical basis, and my view is that AI can speed up that competition when firms use it to improve the work customers actually buy.

I cannot tell you what share of future layoffs will come from firms losing to better AI users. I can tell you that doing nothing with your delivery operation is not a way to keep competition away from your team.

So I would make the next decision around work you want to win and work you need to deliver better. Choose one part, use AI where it helps, and measure the whole result, including checking and rework, before counting the time as available.

Decide beforehand what any saved time will fund, better deliverables, training, another process improvement, or more client work that is actually there to take on. Then choose the next part and repeat.

That's how you move through the Production Gap, rather than treating an announcement as an operating change. It can support the move toward Stage 3 on the Delivery Model Ladder, where revenue can grow without adding people at the same pace.

Keep the work coordinated too. A company-wide order to "use AI" without clear boundaries can create shadow AI, and silence about the staffing plan can add to people's anxiety about the tool.

Your team deserves to know what you are trying to change, and you need their help to find where the work improves or breaks. That is more useful than asking them to celebrate a tool while wondering whether their job is the saving you have in mind.

There is a real limit to the growth route. If the market is contracting and there is no more work to win, faster delivery does not create demand by itself, and even a firm that gains share may still have to make difficult staffing choices.

Look at demand, quality, win rates, reviews and referrals alongside the cost of delivery. Then make the staffing decision from the work the firm can sustain, not from a headline or a promise on a software box.

Fewer Managers, More Managing

Wed, 22 Jul 2026 13:00:00 GMT

I've watched supervisors go from spending two hours a day reading data and preparing reports to sometimes spending less than ten minutes checking what the AI produced.

The part that interested me wasn't only the report getting faster. In the firms that used the time well, those people spent more of the day training, developing and motivating their teams, and the company became more connected rather than less.

That's the change I want you to consider before you decide AI means you need fewer managers. Give the tracking work to a system that can do it reliably, then help the manager use the recovered hours for the people work that was getting squeezed out.

A founder I know had a company that had become top-heavy while revenue was healthy. Before changing the reporting lines, I suggested connecting an agent to the tools where the work already lived, Slack, Gmail, the CRM and GitHub, and seeing how much of the tracking it could take over.

That was advice, not a result I'm claiming for his company. But it is a pattern worth looking for in your own firm, you can spend a lot of effort automating client delivery while the management around it still runs on people fetching updates from each other.

I find it useful to separate two parts of the manager's job. Tracking is finding out what happened, assembling reports, chasing a status update, passing information between people who can't see the same picture.

Judgment is deciding what to do with that picture, having a hard conversation, coaching someone through a problem, noticing who is ready for more responsibility. The agent can help prepare that work too, but the person still owns the relationship and the decision.

Those are different demands on the week. If the same manager spends the morning gathering information, the time left for a conversation with someone on the team is whatever survives afterward.

There is plenty of research on the coordination load, although most of it isn't a direct measure of your managers. Asana's work-about-work research, covering more than 10,000 knowledge workers, reported 60% of time spent on work about work, including 352 hours a year talking about work.

That is a broad knowledge-worker finding, not proof that 60% of every manager's job can be automated. I would use it as a reason to inspect the week, not a percentage to put into a staffing plan.

Microsoft's 2025 report on the workday reported 117 emails a day and 153 Teams messages per weekday for the average worker in its data. Its much-repeated interruption-every-two-minutes figure was based on the top 20% of users by incoming ping volume, not every employee.

A manager sitting between several teams can recognize that sort of day. But you still have to see which messages need judgment and which are just requests for information the system could already supply.

A Quantum Workplace summary of Gartner research puts manager responsibilities at 51% more than managers can effectively handle, and says one in five would leave people management if they could. That is a warning about workload, not evidence that the people doing the job aren't capable.

There is also research on work changing when AI arrives. An account of a Harvard Business School study involving 50,032 developers using GitHub Copilot reports project management falling by 10% as a share of activity while coding's share rose.

A smaller share of activity doesn't tell you that ten percent of manager hours became free, or that AI directly performed the missing coordination. It does suggest the mix of work can change, which is what I would investigate rather than assume.

In the service firms I've watched, the report-preparation example is more concrete. The supervisor still receives the information and checks the AI output, but doesn't spend the same two hours reading data and compiling it by hand.

I've also seen systems check for projects with no recent client contact, overdue tasks and consultant interactions that need attention. The system warns the manager so they can address the situation before it becomes a churn problem, rather than asking the manager to discover every warning signal manually.

That does not mean the system prevented every lost client. I'm describing the monitoring and intervention process, and the change in what the manager spends time doing.

The tool has to be connected to the information it needs, and somebody has to write down what it should watch. "Check whether projects are healthy" isn't enough if the firm has never agreed what a warning looks like.

GitLab CEO Bill Staples described the direction in the company's May 2026 Act 2 memo: "If an agent can do it, we automate it, and find things where our judgement or skill is essential."

The same memo says, "Every layer of management increases the number of places where priorities and communication gets filtered." That's GitLab's operating argument, not a reason for you to remove a layer before you know which work it carries.

My own operation is a small-scale example of the same approach. When I described it in August 2026, about 90% of my software and publishing work was automated compared with mid-2025, including feature exploration, bug fixing, log analysis and research.

That is my description of my own work, not a benchmark for how much of your firm can run without people. My agents have dozens of command-line tools for interacting with the systems, and when I catch myself doing a task twice, I look for a script or a skill the agent can use instead.

It leaves me spending more time writing, thinking, studying and working out how systems should operate. A manager's version starts with the repetitive questions and reports in their own week, not with copying my setup.

Now, managers often take longer to adapt than the operational team, and I don't read that as resistance. In the delivery work I see, operational teams tend to engage quickly when they can see the benefit, while supervisors and managers can need dedicated time to learn the new way of working.

The tracking work is familiar and visible, you have a spreadsheet, some numbers and a report to show for the day. The people work is harder to organize, and in many firms nobody has written down how a good one-on-one or a useful feedback conversation should run.

So when tracking shrinks, the manager can be left with hours and no shared process for the part of the job that needs to grow. Leadership needs to help them make that transition, not assume the coaching appears because the report is finished earlier.

The reporting lines can change after that, but I would be careful about what the wider data proves. Gusto's payroll analysis of 8,500 small companies found individual contributors per manager rising from roughly three in 2019 to roughly six in 2024.

It also reported manager hiring falling about 40% to 50% from 2022, compared with roughly 11% for individual contributors, and the share of employees in people-manager roles falling 34%. Those are changes in payroll records, not a causal estimate of how many roles AI removed.

The sector detail matters for this audience too. Professional services, information and finance were among the sectors that flattened least in that analysis, so the headline doubling is not a target I would hand a service-firm owner.

Other numbers tell you the pressure on management roles is wider than one dataset. Deloitte reported middle-management job postings down 42% between spring 2022 and the end of 2024, and in October 2024 Gartner predicted that 20% of organizations would use AI to flatten through 2026, eliminating more than half of current middle-management positions in those organizations.

One is a posting trend and the other is a forecast. Neither tells you that half of your own management work has disappeared.

The big-company announcements are louder. Amazon set a target to increase its ratio of individual contributors to managers by 15%, Google reported cutting 35% of managers of small teams, and Coinbase described replacing pure managers with player-coaches, people who manage and also do delivery work.

Those are different decisions in different businesses, not one proven AI playbook. The quieter pattern I've seen in service firms is a manager leaving and the seat not being refilled because the agent has taken enough of the work for the remaining responsibilities to fit elsewhere.

A supervisor gets promoted and takes on what remains. I've often seen younger, more AI-fluent supervisors do that, but age isn't the test for who can handle the job, the skills and judgment are.

That can remove a management layer without a layoff. It doesn't mean headcount is mathematically unchanged when somebody leaves, it means the firm doesn't have to begin by dismissing the people who are already there.

And once the tracking is handled, the constraint can move to skills. Who can run the system, check its output, manage the exceptions and help the rest of the team improve?

This is where I think owners can miss the better use of the time. They see fewer hours required for reporting and start counting a salary saving, while the firm still needs more attention on developing people.

In the firms where I watched that two-hours-to-ten-minutes change, some managers used the recovered time for training and motivation, and I saw teams operate in a more connected way. Other owners have told me similar stories, less fetching data and copying it around, more attention to the work that helps the business.

That is my observation, not a measured effect on morale across all firms. Some teams don't make that change, and the time gets used up without a clear benefit.

The management research explains why I wouldn't treat people time as the leftover. Gallup estimates that managers account for at least 70% of the variation in employee engagement scores across business units.

That doesn't mean managers cause 70% of every person's feelings. It means the way teams are managed is strongly tied to differences in their engagement, and taking management away without replacing its functions is a serious decision.

In its 2026 State of the Global Workplace reporting, Gallup looked at employees in US organizations investing in AI. Those who strongly agreed that their manager actively supported their team's AI use were 8.7 times as likely to strongly agree that AI had transformed how work got done.

That is an association in reported experience, not a promised return from giving a manager an agent.

The useful move is the same one in Delegate the Inputs, Own the Outputs. Let the system assemble the information, keep a person responsible for the decisions about people, and give that person enough time to do the work.

On the Delivery Model Ladder, that can support the move from Stage 2 toward Stage 3. The operating structure changes because the work changed, not because you renamed the roles.

There are a few ways to get this wrong, and the first is assuming the saved hours will find their own use. BCG's June 2026 survey found 42% of frontline regular AI users reported saving at least a workday a week, while 66% received limited or no guidance on using the saved time.

That isn't a manager-only sample, but the planning problem applies. If you want the hours to go into mentoring, decide whose mentoring, when it happens and who checks that it happened, rather than leaving it as a good intention.

I would use the system to help track the agreed work too, with the same clear boundaries you use for other management information. You are checking whether the plan happened, not treating every unfilled minute as misconduct, and the point is to keep the extra time from disappearing.

Another failure is removing the management layer while leaving all its human work unassigned. Korn Ferry's workforce survey found 41% of employees said their organization had cut management layers, and 37% said a lack of managers left them feeling directionless.

There is an older warning in Zappos's move to holacracy, where about 18% of the workforce had left by January 2016. That departure figure included people taking offered severance, so it isn't a clean measure of people leaving because a flatter structure failed.

Still, deleting a line on the chart doesn't delete the coaching, escalation and development that used to travel through it. Somebody needs to carry that work after the change, and they need hours for it.

You can also overload managers by doing the reverse, adding responsibility for AI without taking anything away. Harvard Business Review's June 2026 article on overloaded middle managers describes consulting-firm managers expected to validate AI output, coach the team and maintain quality on top of the existing job.

Don't give someone all of that and call the software a time saving before the tracking duty has actually gone. Make sure the agent does the work reliably, then redesign what the manager is responsible for.

And write down the judgment part too. What does a good one-on-one cover, how is feedback given, what should a manager notice about a person, and when should that lead to a conversation?

People learn with other people. The contact, encouragement and correction are part of how someone grows into the next role, and an org chart that loses that work hasn't become efficient just because it has fewer boxes.

Gartner's flattening forecast carries that warning itself, mentoring pathways can break and juniors can lose development opportunities. If the old structure taught people partly through proximity, you need to provide that learning deliberately when the structure changes.

Use the recovered hours to prepare the team for an AI-native firm, including running agents, validating output and understanding the delivery system. Those skills don't arrive with the license either.

There is a size limit to the org-chart argument. If you still carry all the coordination yourself and nobody has a dedicated management role, an agent can save you time, but there may be no management layer to remove.

And even in a larger firm, the remaining people work may justify another hire. The decision should follow that work, not a ratio somebody else reported.

Before you post the next manager or coordinator vacancy, list the reports compiled by hand and the status questions repeated through the week. That is the beginning of an agent's job description, and you need to test which parts it can actually take.

Then write the role that remains, including the time for coaching and development, and decide whether somebody can grow into it or whether it needs a new person. Give the hours a job before you take a seat off the chart.

The downturn playbook for AI-native firms: cut the fat, not the capability

Mon, 20 Jul 2026 13:00:00 GMT

If revenue drops and you need to cut costs, I would look very carefully at what you are about to lose before deciding that AI lets you keep the same business with fewer people.

You may need fewer hours to produce the work, that part can be true. But somebody still has to look after the client, catch the mistake, improve the service and do the work that makes the next renewal easier, and those hours need to be in your calculation too.

My recommendation is to find the waste first, protect the parts of delivery that clients depend on, and use the time AI actually frees to keep those clients and win more of the right work. Have a fallback plan as well, because telling an owner to keep investing without asking how long the cash will last is not useful advice.

I don't have franchise-network data showing how this plays out through a recession. This is the approach I would take, drawing on what previous downturns tell us and what we already know about AI in delivery, not a result I have measured across firms.

And you don't need to agree that a recession is coming to do this work. A client can leave, a renewal can get smaller, a strong pipeline can stop turning into signed work, your own firm can come under pressure while the wider economy is doing fine.

The hard part is that the quick cut usually looks very clear. You can see a salary leaving the monthly bill, while the cost of losing that person's judgment or their knowledge of the client shows up somewhere else, sometimes much later.

That doesn't make every job untouchable. It means you need to follow the saving through the business instead of stopping at the line where you found it.

There is a useful piece of recession history here. In Roaring Out of Recession, published in Harvard Business Review in 2010, the researchers looked at 4,700 public companies across three recessions and compared how they cut and invested.

The firms most focused on cutting costs had a 21 percent probability of pulling ahead of competitors after the recession. For the group that combined selective cuts with continued investment, that figure was 37 percent.

Those are results from groups of public companies, not the odds that your AI plan will work. The study predates this kind of AI, and it does not prove that keeping a particular tool or employee causes a better recovery.

What it gives you is a reason to question the idea that the deepest cut is the safest choice. The firms that did better were cutting too, they were making different decisions about what to protect.

Sony's experience in that study is worth staying with. Around the 2000 downturn, it cut its workforce by 11 percent, research and development by 12 percent, and capital spending by 23 percent.

Its margin improved from 8 percent to 12 percent, which would look like a successful response if that were the only number you watched. But its average annual sales growth went from 11 percent before the recession to 1 percent afterward.

Now look at the other approach. Bain's 2019 recession analysis describes Samsung continuing to invest in research and marketing through the 2009 downturn, while competitors pulled back.

That is a large technology company, not a small consultancy, so I would not copy its spending plan. The useful comparison is what each company was trying to preserve, one was protecting the immediate margin, the other was also protecting what it would have to sell when demand returned.

Research spending sounds remote from the week of a service-firm owner, but think about the work that makes your AI useful. Someone has to learn the tools, write down how a good job is done, test the checks, fix the failures and help the team use the new workflow.

That work costs money before it gives you a dependable saving, which makes it very easy to remove when you need the bill to come down quickly.

An NBER summary of research on financially stressed firms during the 2008 crisis found that cuts to research persisted beyond the crisis. The authors discuss adjustment costs as an explanation for why firms don't simply restore those teams when conditions improve.

My comparison is that learning and workflow redesign deserve the same care in an AI budget. I am not calling your training afternoon basic scientific research, I am saying you can cut the work that creates a future capability and then discover that buying it back is harder than keeping it going.

We also have examples of the cost-first AI approach before any future recession arrives. Klarna said its assistant was doing work equivalent to 700 customer-service agents, and later moved employees back into customer support after quality concerns.

The 700 figure was a claim about work capacity, not a count of 700 people laid off in one action. And the CEO's criticism of going too far concerned cost-cutting broadly, so I would not turn that story into proof that every use of AI in support failed.

It is a warning about what you count as success. Handling the volume is one test, taking proper care of the person asking for help is another, and you need both before removing the people who handle the difficult cases.

In Gartner's February 2026 release, only 20 percent of surveyed customer-service leaders said they had reduced agent staffing because of AI. Most reported steady staffing while supporting more customers.

Gartner also predicted that half of companies attributing customer-service cuts to AI would rehire for similar work under different titles by 2027. That second part is a forecast, not a rehiring result already on record.

The first part matters more for the choice in front of you. Keeping the team and serving more customers is a real option, it just doesn't make the same headline as a large headcount reduction.

And a cost target is not a saving yet. In Bain's 2026 survey of 951 companies, 37 percent targeted cost reductions of 11 to 20 percent, while nearly 40 percent of those measuring outcomes reported reductions in the 0 to 10 percent range.

Those figures describe the target and result distributions, they do not tell us that every firm aiming for the first range landed in the second. They are still a good reason to keep checking the actual result rather than treating the budget proposal as money already recovered.

Now, AI does create useful capacity. The NBER working paper on 5,179 customer-support agents reported a 14 percent average increase in issues resolved per hour, with a larger gain among novice and lower-skilled workers.

That is people doing the work with an assistant, not a test of removing the people. If you use the finding to plan layoffs, you have added a decision the experiment did not test.

There is a similar boundary in the consulting research. In Ethan Mollick's account of the BCG consultant experiment, consultants using AI did more work, faster and at higher quality on tasks within the model's abilities, but performance got worse on a task outside them.

Somebody still needs to know which kind of work your service contains. You cannot take the gain from one part of that study and leave the failure condition out of your staffing plan.

There is another reason I wouldn't start with headcount. You can make a task faster without getting useful time back across the whole job, and you can get time back without deciding what it should be used for.

Those are separate problems. If review and rework consume the saving, the hours aren't available yet, and telling the team to take on more clients would give them work the new process cannot support.

If the hours really are available, leadership has to assign them. That is the problem I describe in the extra time AI buys you, a tool improves what people can do, but management has not changed what they are expected to work on.

My hypothesis is that this helps explain some disappointing AI returns, and that those disappointments could feed wider pressure to cut. The OECD's March 2026 interim outlook names lower-than-expected AI investment returns as a possible financial-market risk, but it does not establish that unused employee hours are causing that risk.

For your firm, the useful part is much smaller than the economic argument. Before counting a saving, decide how you will find out whether it exists and what work will receive it.

I would start with your profit-and-loss statement and the people who know how delivery actually happens. Look at tools nobody uses, vendors doing overlapping jobs, work you keep selling despite its poor margin, and steps everyone follows without knowing why.

There is no honest percentage I can promise you will find there. But you should know what the waste is before cutting your ability to deliver good work, because removing an unused subscription and removing the only person who can fix a troubled account are very different savings.

Then write down the cutting order while you can still have a calm conversation about it. Put customer experience, service quality and the technology that improves them near the end, and name what evidence would make you change that order.

An AI project doesn't get protection just because it has AI in the name. If it adds cost and still has no credible path into delivery, you need to question it like anything else, while distinguishing it from a working system that clients already depend on.

For an automation that saves time, put the next assignment beside it. If, for example, you establish that it frees 20 hours a month, decide who will use those hours and which clients or delivery problems they will work on.

In a downturn, my first choice would be retention. Give the manager time to catch a service problem earlier, help the client get more use from what they already buy, or improve the work that keeps coming back for correction.

That can support new business too, but choose the work deliberately. Sending every client more AI-generated material is not the same as giving them better service, especially if they now have to spend their time finding the useful part.

I would keep looking for good opportunities while other firms pull back. Bain's research on the early-1990s recession found that more than a fifth of bottom-quartile companies moved into the top quartile during the downturn, and many gains persisted through the recovery.

Again, that is historical evidence that positions can change, not permission to spend money you don't have. Taking a useful risk needs a floor underneath it.

So set the fallback plan as carefully as the growth plan. Decide which revenue or cash conditions trigger another cut, what gets paused, and who can make that call, then look at the effect on delivery before you approve the list.

If cash is running out, survival can require cuts to capability too. This playbook cannot remove that tradeoff, its purpose is to help you avoid arriving there after cutting the things that might have kept your clients.

Sit down with the person who owns delivery and write those decisions before the next difficult budget meeting. You need to know what you will protect, what you will stop, and where any real saved time will go.

How AI Is Changing the Consulting Industry (and Why the Retainer Wins)

Fri, 17 Jul 2026 13:00:00 GMT

I've watched monthly-fee consulting firms produce more work with less effort while continuing to charge the same fee, and I've also watched clients cancel consulting contracts because they decided an AI chat could give them the advice they needed.

Both things can happen at once. AI can make a retainer more profitable for you and make the client less certain they need to keep paying it.

So if you are wondering how AI is changing the consulting industry, I would start with the agreement between you and the client. How you charge decides where a saving goes, but the reason the client keeps paying decides whether you get to keep that agreement at all.

The way I would use AI is to improve delivery and put some of the recovered time into useful work the client wasn't getting before. That work needs to answer a real problem, and someone who knows the client has to check it, otherwise you are just sending more material for them to deal with.

Let me explain the billing part first, because it is easy to miss when you are concentrating on making the team faster.

If you charge by the hour and the same task takes fewer billable hours, the invoice for that task comes down, assuming the rate and scope stay the same. The client receives the saving as a smaller bill.

You can still benefit, of course. If you have more work waiting, you can use the available hours on another project, so hourly billing doesn't mean AI is useless to you, it means the saving doesn't automatically stay in the fee for the first job.

With a fixed monthly retainer, the fee can stay where it is while the cost of delivering the agreed work falls. That leaves room for a better margin, provided you count review, rework and the tools as part of the cost to deliver.

But a fixed fee doesn't stay fixed forever. At renewal the client can ask for a lower price, more work, or an explanation of why the same fee is still worth paying, and you should be ready for that conversation.

Outcome-based pricing is another option, where payment depends on an agreed result rather than the hours spent. That creates its own work, because you and the client have to define the result, measure it and agree which parts you can actually control.

I wouldn't turn this into advice to move every client onto the same contract. A changing scope can make a fixed fee dangerous, and a result you cannot measure clearly can make an outcome agreement a long argument about who owes whom.

Start with the repeated work where you understand the cost and can describe what the client is buying. That is where the effect of the billing model becomes easier to see.

The big consulting firms are dealing with this too, but their starting point is different. Their traditional staffing model puts a lot of junior research, analysis and production under a smaller number of senior people, and those hours have supported the way they charge.

AI can now help with several of those tasks, so the model comes under pressure when the production hours fall. That does not mean AI does everything a junior consultant does, or that every reduction in consulting headcount was caused by AI.

Reporting on McKinsey described headcount falling by about 5,000 from its peak, while reporting on PwC put its global headcount reduction at 5,600 in its 2025 financial year. A headcount decline includes more than announced layoffs, and neither number isolates the effect of AI.

The pricing changes are more directly relevant to this piece. The Wall Street Journal reported that more than 30 percent of McKinsey's global fees were tied to client outcomes, and described the difficulty firms face in moving away from hourly work.

Bloomberg Tax reported managed-services targets of 20 to 25 percent of advisory revenue at PwC and 15 to 20 percent of US consulting fees at KPMG. Those were stated targets, not reported revenue shares already achieved.

If you run a smaller consulting firm, you may already work with a few senior people, a small bench and a junior supporting several projects. That is a shape I've seen, along with fixed monthly fees, so you don't necessarily have the same staffing model to unwind.

But having the right contract doesn't settle the client question. It just changes how much room you have to answer it.

In Source Global Research's review of its Q4 2024 client findings, 87 percent said they would pay more for consulting delivered with AI-enabled tools. In the same review, 58 percent expected consulting prices to fall.

Those are stated views, not a record of what every client later paid, and the figures don't tell us exactly how each respondent reconciled the two answers. My read is that clients can want a better result while questioning why they should still pay for the hours that result used to require.

The research also put client use of generative AI at 84 percent by Q4 2024. That tells you many buyers were already trying it themselves, not that demand for every kind of consulting was growing or guaranteed to hold.

And that is where the cancellations I've seen come in. The client engagement settles into a routine, the difficult early questions have been dealt with, and the consultant keeps doing work that no longer feels especially useful to the client.

Meanwhile the client is asking an AI chat their own questions and getting a clear answer quickly. It doesn't have to be as good as everything your firm can do, it only has to seem good enough for the work they think they are paying you for now.

From your side, you may be maintaining the relationship and making sure the agreed deliverables arrive. From their side, the same monthly bill has started paying for something they believe they can get elsewhere with less effort.

I would not wait for the cancellation email to have that conversation. Ask what the client is trying to solve next, what has become harder in their business, and whether the work you send helps them make those decisions.

That is different from asking if they liked the report. A report can be well written and arrive on time while answering a question that no longer matters very much.

The firms I've watched hold their clients have used AI to deliver useful extras beyond the original scope, market research, analysis of the client's own data, competitor work, social strategy ideas, reading and content suggestions.

These were produced with AI and checked by a person. The lower cost made that extra work possible, and the person supplied the understanding of which part would help this client rather than just fill another document.

I don't have a measured retention lift to give you for that pattern. What I have seen is firms doing more relevant work for their clients at a cost they could carry, rather than treating every hour recovered as a reason to reduce the relationship to the contract minimum.

And please don't read that as a promise to do unlimited work for a fixed fee. You still need scope, you still need to know what it costs, and an extra that becomes a standing expectation may belong in the next agreement.

The practical move is to keep a short list of the problems you hear from each client. Build it from conversations, the numbers they share and what is changing in their business, then decide which problem deserves attention before it becomes urgent.

If a client is worried about losing a particular kind of customer, a focused piece of analysis on that question could help. A general report on trends in their industry may look more impressive and tell them much less about what to do.

That example is the distinction I want you to make. Choose the question from the client's situation before you ask an agent to produce the work, otherwise the tool's ability to generate material starts deciding what you send.

I would begin with one useful extra in the month, not a new weekly reporting obligation. That is a starting recommendation, not a cadence I can prove is right for every relationship, and the client may prefer a short conversation to another file.

The cost needs checking too. AI production is cheaper for many of these tasks, but someone has to prepare the input, run the work, verify it and decide what to do if the answer is poor.

Count that whole job before saying the retainer has become more profitable. The model and its settings can change the bill, and the amount of senior review can change it more, so measure the setup you actually use rather than assuming every extra is nearly free.

This is the consulting version of giving saved time a purpose. The hours don't become retention work by themselves, the manager has to make room for it and someone has to own the client question.

There is a very clear counterexample. If you send a monthly bundle of generic AI reports, the client has to work out what is relevant and whether any of it is true.

You have given them another job, and you have also shown them something they could generate in their own chat window. More output can make the substitution easier when the judgment is missing.

So every extra needs a named person responsible for checking it. That person needs to understand the client, not only whether the sentences read well.

They should check the source of a number, whether the analysis fits the client's data, whether a recommendation conflicts with something the client has already decided, and whether the firm is making a claim it can support. That checking time belongs in the plan before you offer the extra.

In October 2025, Deloitte Australia agreed to a partial refund on an A$440,000 government report after errors including nonexistent references and citations were identified. The revised report disclosed use of Azure OpenAI GPT-4o.

That is an Australian-dollar contract amount, not US dollars, and the partial refund was not a refund of the whole fee. The useful warning is that a large firm's name and a polished report did not keep unsupported references out of the delivered work.

Your extra carries your name too. Calling it a bonus doesn't make the client responsible for checking it, and a deadline doesn't turn a generated citation into a source.

So will AI replace consultants? It has already replaced some consulting relationships in the cases I've seen, and it can take over parts of research and production, but neither fact settles what happens to your firm.

The safer question is whether the client still receives something useful from your judgment and your knowledge of their business. If they do, AI can help you deliver more of it, if they don't, changing the invoice from hours to a retainer won't fix the missing reason to renew.

For the next client review, bring the current agreement, what delivery actually costs, and the short list of problems the client is facing. Pick one piece of work you can improve or add, decide who will check it, and make sure the client wants the result before you produce it.

Constraint Whack-a-Mole: What AI Adoption Feels Like

Wed, 15 Jul 2026 13:00:00 GMT

You can make your team faster with AI and end up with work taking longer to reach the client, because the people making it are no longer the people setting the pace.

The drafts arrive faster, but somebody still has to check them, approve the promises and decide what can leave. If that part of the job hasn't changed, the extra work waits there.

What I have seen work is to keep following that pile, find what is holding the work up, decide whether the step is needed, and improve it if it is. Then you look again, because once that part works better, something else becomes the limit.

That is what I mean by constraint whack-a-mole. The constraint is simply the part of the job that limits how much useful work gets through, and using AI doesn't remove the need to manage it.

I have watched implementations get dismissed because the first results were poor while everything around the tool stayed the same. Other teams stayed curious about where the work was getting stuck and changed the functions and workflows around it.

I'm not saying a flat result proves the tool is good. It tells you to look at the whole job before deciding, because a faster first draft and a faster service are different results.

Think about ten reports as an example, not a measured case. AI can help write all ten this week, but the partner can safely check only five.

If you start all ten, the reports don't become delivered work just because the writing is finished. Five are waiting for a person whose week was already full, and some of that work may need updating before the person gets to it.

The team can be doing good work throughout this. The junior produced what you asked for, the partner is checking carefully, and the client still gets the report late because you started more than the whole process could finish.

So I would not begin by telling the reviewer to hurry up. You set the amount of work going into a process that depends on their time, and that is something you can change.

There is research from software delivery that makes this distinction visible. Google's 2024 DORA report, based on nearly 3,000 working professionals, associated a 25 percent increase in AI adoption with about 2.1 percent higher individual productivity.

The same increase was associated with about 1.5 percent lower delivery throughput and 7.2 percent lower delivery stability. In plain words, the individual measure improved while the measures of getting software out reliably got worse.

These are associations in software teams, not proof that AI caused a slowdown in service firms. DORA suggested that AI might be encouraging larger batches of code, which are harder to move safely, and explicitly treated that explanation as a hypothesis.

The service-firm version I want you to check is simpler. Have you increased how much work people can make while leaving review, approval and client decisions sized for the old amount?

There is a useful difference between work waiting to start and work waiting after someone has made it. A request on a list still needs attention, and a client waiting for it can have a real cost, so I wouldn't call that waiting free.

But you haven't yet spent the production time on a version that may go stale. If priorities change, you can move the request before someone has written the report with numbers that are no longer current.

That is why I prefer to hold work before production when review has no room for it. It is easier to choose the next thing carefully than to keep refreshing a pile of finished drafts nobody can release.

The first question at the stuck step is whether it needs to exist at all. A status report nobody uses may be something you can stop making rather than something that needs a better AI prompt.

Be careful with that question around controls. A step can protect the client without appearing in the final deliverable, so not seeing it in the report is not a reason to delete it.

Ask who uses the step, what decision depends on it and what would go wrong without it. If it is needed, work on making it easier to complete without losing its purpose.

For repeated work, I would make the queue visible in four states. There is work waiting to start, work being made, work being checked, and work that has passed the check and can go to the client.

The important part is that being made and being checked share one limit. Moving a draft from production to review doesn't create room for another draft, passing the check does.

Suppose you set that shared limit at five reports and three are still open from yesterday. There are two slots available, not five new starts because the calendar changed.

A limit on open work is different from the number you finish in a week. You need to watch both, because five open reports that take a day to clear behave very differently from five that take a month.

The person who owns the job from request to client sets and holds that limit. The reviewer tells them how much checking the team can safely handle, but the reviewer should not also have to chase everyone who starts work outside the agreement.

If the owner makes an exception, I want a reason, a named person responsible for it and a date it ends. Otherwise the exceptional workload becomes the normal workload without anyone choosing that.

Counting reports works only when the reports require roughly similar effort. If a custom analysis takes four times as long to check as the weekly report, counting both as one item hides the work, so give the custom job more of the available room or track checking hours instead.

I would begin by watching two full cycles of repeated work, often around ten working days for a weekly process. That is a starting window, not a guarantee that ten days captures every kind of variation in your firm.

Write down what arrived, what passed the final check and what remains open. Also look at how long the oldest item has waited, because a steady total can hide the same difficult file being passed over again and again.

My warning line is a queue that grows for two weeks running, by roughly 10 percent of a normal week's output each week. If you normally finish 50 similar items, that would mean five extra items left waiting one week and another five the next.

That is my rule of thumb, not a threshold measured across the franchise network. Its purpose is to make you act on a growing pile before everyone gets used to working around it, and a missed client deadline deserves attention before the threshold is reached.

Before raising the limit, I would want two steady cycles in which work finishes in the expected time. The oldest item must remain within the review window and within what you promised the client.

I would also check that rework hasn't risen, serious defects aren't reaching clients and quality is staying in the range you agreed. Faster completion bought by skipping checks is not extra capacity.

Then ask the reviewer what it took to get there. If they repaired the reports after dinner or worked through the weekend, those clean delivery numbers are borrowing time from a person, they are not showing what the process can sustain.

When those conditions hold, add a little room, one slot for comparable work, and measure again. I would not double the amount coming in after two good weeks and assume the next part of the job can absorb it.

Now, limiting starts protects the reviewer, but it doesn't by itself make the checking better. For that, you need to move some of the checks into the work instead of leaving everything for one person at the end.

Through a franchise network's delivery data, I have seen review move from people to agents as the checks improved. Meeting summaries went from human review to agent checking, research review began matching quotes to references automatically, and data analysis moved away from heavy manual checking toward agent reviewers.

The checks were specific, claims against online sources, results against the client's own data, recurring mistakes from earlier runs, and the familiar ways AI gets language or logic wrong. When the delivery team found a bad piece, the implementation team changed the workflow and the delivery team tested the change.

Across many projects, one week of output contained more than 300 finished pieces. After tuning, roughly 95 percent fewer pieces were flagged for incorrect information or data compared with the same system when it first went live.

That result concerns flagged quality problems. It does not establish a 95 percent reduction in all errors, and the comparison did not measure how many human review hours, people or additional delivered pieces were involved.

I want that limit clear because this is exactly where an owner can read a quality improvement as a staffing saving. The evidence says the checking got better at the problems being tracked, you would need another measurement to decide what capacity that released.

And better automatic checks still leave decisions that belong with people. A proposal can have correct totals, complete sections and acceptable standard terms while making a promise your firm should not make.

AI can prepare those checks and flag the unusual parts, but a named person owns the promise. They decide whether the scope is realistic, whether to accept the margin and who is responsible for the part nobody has properly assigned.

Some cases also need to bypass the ordinary queue. In one case in the network's delivery data, a major client's service complaint was tagged as a billing question and sat in a low-priority queue for 11 days.

The consultant learned about it when the client contacted them directly. The client had asked to cancel and later left, though I cannot say the delay was the only cause.

Within 24 hours the rule changed so cancellation language, threats to leave and messages from strategic accounts went around the normal sorting and reached a person. The routine flow stayed automatic, but the dangerous cases had a different route.

That is the kind of distinction I would make in your review work. Repeated low-risk work can use automatic checks with samples and alerts, more consequential work needs a person looking at the important parts, and high-risk promises stay with a named senior person who signs them off.

Before changing the number of juniors per senior, count the senior minutes those different kinds of work need. Also make room for juniors to see the difficult decisions and hear why they were made, because routing every hard case straight past them can remove the work through which they learn.

Once review gets faster, expect the next wait to become visible. Reports may now clear internally but sit with a client, support cases may reach the right queue but wait for the one person allowed to resolve them, proposals may be ready while the owner has no time to decide.

Follow the work to that point and ask the same questions again. You are managing a service from beginning to end, so a local improvement is useful only if the rest of the job can use it.

This approach fits repeated work where you can measure checking and someone owns the whole job. One-off work still needs judgment, and a short rush needs real checking time booked, a hard cap and an end date.

Pick the workflow where completed drafts are waiting now, and sit with the person who clears them. Before starting more, find out how much open work they can safely handle and what is keeping the oldest item there.

The AI Policy Template That Fits on One Page

Mon, 13 Jul 2026 13:00:00 GMT

If your team is already using AI, I would start by giving them a clear way to use it for work, which tools are allowed, what data can go into them and who checks the result before it reaches a client.

You can put those everyday rules on one page, and for a small business that page is the AI policy people actually use. Your lawyer may need more behind it, but the person trying to finish a client report needs an answer they can find and follow while doing the job.

Through a franchise network's delivery data, I have seen a practical version of this, an internal AI tool covered by a defined data privacy agreement, a ban on putting work data into public tools, and a path for people to propose a new tool before using it.

That is the practice behind this AI policy template. The six rules below are my way of making the operating boundaries easy to remember, they spell POLICY, and they include a boundary for agents that can take actions rather than just write a response.

The one-page AI policy for a small business

P: Pick from the approved list. Use only the firm's approved tools and accounts for work, within their approved purposes and data limits. The firm checks their data agreements and settings before approval. Approved tools: [tools, account types and permitted uses]. List owner: [name].

O: Off-limits. Do not put client or third-party data into public AI tools, even when those tools are approved for other work. This includes prompts, uploaded files and sharing links. Approval of a tool does not override a client's restrictions or permit public sharing of their information.

L: Loop the firm in. Found a better tool? Propose it to [name or channel] before using it for work. It must be checked and approved first. Report a suspected data exposure or mistaken action to the same owner promptly so the firm can respond.

I: Irreversible actions need a person. Agents may act alone only within an approved workflow where their work can be checked, mistakes can be caught in time and the consequences can be undone safely. Anything irreversible or client-facing needs a person's approval before the action happens.

C: Client terms decide disclosure. Follow applicable law, professional duties and each client's terms on notice, consent and disclosure. Obtain required consent before using AI on the work. Answer client questions truthfully, and ask [name] when the requirement is unclear.

Y: You own what you ship. Before AI output reaches a client or a production system, a named person verifies it and is responsible for its use. Check facts, sources, client context and any commitments the work makes.

Never use AI to impersonate a person or let it independently sign, commit or bind the firm.

Policy owner: [name]. Effective date: [date]. Next review: [date]. Approved-tools list: [location].

This is an operator's starting template, not legal advice or a claim that one page meets every obligation. Have the person responsible for legal advice check it against your jurisdiction, industry, contracts and actual tools before adopting it.

You can use the companion, Where Client Data Is Allowed to Go, to write down your approved tools, data limits and request contact. Fill it in, have the relevant adviser check it, then walk your team through it alongside this policy. Download the editable Word version.

You will notice that the C rule doesn't just say to disclose AI whenever it is used, and it doesn't say to stay quiet unless someone asks. Different work can have different requirements, and your policy needs a way to find the requirement before the work starts.

The important part of keeping it short is that somebody can use it under pressure. Imagine a person about to paste a client file into a free chatbot because the approved process is too slow for the deadline.

If your policy says to consider whether the information is sensitive, that person has to make a data decision while also trying to finish the job. A stack trace may look like ordinary code and still contain information about a customer.

The approved-list rule gives them a simpler first decision. Is this the approved tool and account for this kind of work, and is this data allowed there?

That does not eliminate all judgment, because approval still has to cover the use and the data. But the firm makes the tool decision once with the proper information instead of asking each employee to improvise it every afternoon.

The list also has to offer a workable option. If you tell people they cannot use the tool that gets the job done and give them no alternative or proposal path, the deadline is still there when your policy announcement is over.

I would not call that a failure of the team's attitude. As the owner, you need to supply the approved route and make it possible to ask when that route doesn't cover the work.

The older survey figures explain why simply having a document is not enough. In McKinsey's 2023 global survey, 21 percent of respondents whose organizations had adopted AI said they had policies governing employees' use of generative AI.

A September 2023 Littler survey reported by SHRM found that 37 percent of 399 employers had AI policies. These are different samples and old snapshots, not a current count of how many service firms have rules.

And in UpGuard's shadow-AI study, 40 percent of employees recalled AI training, while 40 percent reported using unapproved tools daily. Those two percentages don't tell us that the same trained people were all in the daily-use group, or that training caused the behavior.

They give you a reason to look at what happens after the training. Can people name the approved tool, can they use it for the task they need, and do they know who to contact when they can't?

I like the way FRB Law describes the enforcement problem: “Employees quickly learn which rules are real and which are decorative.”

If the policy says a person must approve a client email but the agent has permission to send it without approval, the workflow is teaching a different rule from the page. Fixing the wording alone won't change that.

Sharing is another place where the tool name can distract you from the actual risk. An approved account with suitable protections can still expose information if someone makes the output public.

In 2025, ChatGPT's discoverable-sharing feature allowed shared conversations to appear in search results. On July 27, 2026, Axios reported that publicly shared Claude artifacts were appearing in Google results, including business plans and clinical-trial material.

Those reports concern shared content, they do not establish that private chats were all made public. The lesson for your policy is to treat the sharing link as a data decision too, because a person may think they are passing a document to one colleague when they are publishing something more widely.

The same care applies to inputs, and that is where people ask what you shouldn't share with ChatGPT. The Samsung reporting in 2023 described employees putting sensitive material into ChatGPT, including source code.

Whether a provider uses submitted material for training depends on the product, account, settings and agreement. I would not tell the team that every public chatbot trains on everything, or that a paid subscription by itself makes client data safe.

Have the firm check those conditions and the client's permission, then make the allowed use plain. The person producing a report should not have to interpret a vendor's data terms while the client is waiting.

Now look at the agent rule, because this is where a familiar instruction can stop working. With a chatbot, you ask for a draft and read it before deciding what to do with it.

An agent connected to email or billing may be able to take the next step itself. If it has already sent the reply or issued the invoice, reviewing the text afterward is too late to provide approval before the action.

So “review AI output before use” needs to be implemented as a real stop before the action, not left as a sentence that assumes the stop is already there. This is a gap to check in a policy, not a claim that every other policy template ignores agents.

An agent drafting a client reply and leaving it in an approval queue stays on the preparation side. Give the same agent permission to send that reply and it has crossed into client-facing work, so the I rule requires a person before it sends.

For internal actions that can run alone, check more than whether a button says undo. Can you detect the mistake in time, and does undoing it repair the consequence, or has another person already acted on the wrong information?

A wrong internal summary can become a bad client promise when someone quotes it in a proposal. That is why owning the output includes checking what the next person will do with it, not only where the file is stored.

The policy above deliberately sets a conservative client-send boundary. If you later want a tested workflow to send routine messages automatically, that needs an explicit policy decision and controls, not an employee quietly treating the word routine as permission.

Client contracts deserve the same attention. The Association of Corporate Counsel publishes sample AI guidelines for outside counsel, which is a concrete example of buyers putting expectations about AI into the instructions they give professional firms.

A sample is not a rule binding every firm. What binds your work depends on the client's actual terms, the agreement you accepted, applicable law and any professional duties that apply to you.

For US lawyers, the ABA's Formal Opinion 512, issued July 29, 2024, discusses competence, confidentiality, communication and reasonable fees when using generative AI. It is guidance on the ABA Model Rules, not a law that automatically governs every jurisdiction or every service business.

Consent and disclosure depend on the circumstances, including confidentiality risks, relevance to the representation and the client's instructions. Lawyers need to check the rules and opinions governing their own work, and a consulting or agency owner should not copy a legal-profession requirement as if it applied universally.

That is why the C rule names the sources of the obligation and gives the team someone to ask. Honest answers matter, but so does obtaining consent before use when consent is required, answering truthfully afterward doesn't repair having skipped it.

You can put this page in the employee handbook, with the current approved-tools list somewhere people can reach easily. Name the owner and set a review date, I would review it quarterly and whenever a tool, contract or workflow changes the rules people need to follow.

Then walk the team through actual examples from their work, a file upload, a shared link, an agent preparing a message and the point where a person approves it. Ask them to show you what they would do, rather than asking whether they have read the page.

Keep the proposal path open and validate new tools before approving them. That is part of the practice I have seen, people can suggest an option, but suggestion does not become permission to use it on client work.

This gives you a controlled starting point for AI use that was happening without company oversight. It won't redesign delivery, prove an AI return or make the firm AI-native, and it won't replace training, access controls or the fuller legal material your work may require.

Fill in the names, tools and dates, get the relevant legal review, and show the team where approval actually happens in the workflow. The page is ready to be useful when the work follows the same rules.

AI Anxiety and the Output-Validator Workflow

Fri, 10 Jul 2026 13:00:00 GMT

Your team can want to use AI and still be worried about what happens to their jobs when it works. I wouldn't read those two things as a contradiction, because wanting a better way to do the work doesn't tell someone where they fit in the company afterward.

What I keep seeing is firms leaving that question unanswered while people start using AI through their coworkers. Then the work changes before anyone has properly decided how responsibilities should change with it.

Senior people receive finished drafts after the important choices have already been made, and they are still responsible for what reaches the client. They can approve it, send it back or repair it, but they weren't given a useful place in deciding what should have been made.

That is what I call an output-validator workflow, responsibility for the result without enough authority over the choices that shape it. My recommendation is to move that judgment earlier, explain what the company intends to do with the added capacity and give people paid time to learn the new work.

This is an operating pattern I have seen, not a claim that I have measured the anxiety of everyone working in it. The research gives us reasons to take lost decision power and job uncertainty seriously, and I want to keep that evidence separate from what I know from delivery work.

Take a marketing campaign as an example. This is an illustration of a pattern across firms, not one recorded client case.

Before production starts, somebody needs to choose the audience, the offer, the evidence and the promises the client can safely make. A senior marketer may know the history behind those choices, including a claim the client has already rejected.

Now suppose a junior employee can generate a complete campaign before that senior person sees the brief. The campaign looks ready, the team has spent time on it, and the senior marketer is asked whether it can go out.

Imagine the copy promises qualified leads in 30 days, but the client has no evidence for that result and has rejected guaranteed-outcome language before. The problem began before the writing, because the junior and the AI never received that boundary.

You can ask the senior person to fix the copy, and they can probably do it. But if the offer itself is wrong, checking becomes a return to decisions that should have been made before the campaign existed.

The junior wasn't careless for using the tool you wanted them to use. They were producing inside a brief that lacked information the firm already had, and management owns the job of getting that information into the work.

Nor is the senior person necessarily resisting AI when they keep sending it back. They may be trying to meet a responsibility you left with them after moving the decisions somewhere else.

There is a useful contrast here with a payment batch. AI can match invoices, flag possible duplicates and prepare the batch, while the controller decides whether the money leaves the bank.

In that case, final approval can be the important decision. The controller doesn't need to perform every earlier production step to retain real authority over the consequence.

A monthly client report can contain both kinds of work. AI can assemble the routine figures, but the person responsible for advising the client needs to decide why the margin changed and what action the report should recommend.

So the test isn't whether a person reviews something at the end. It is whether the person who carries the consequence controls the decisions that create it, wherever those decisions belong in the workflow.

That distinction matters because human review is necessary in plenty of work. This article is not an argument for removing it, or for requiring a senior person to touch every step so they can feel involved.

It is an argument for putting their judgment where it can still change the direction, instead of asking them to correct the direction after production has made it expensive to change.

The workplace surveys show why I would have this conversation openly. In EY's October 2025 survey of more than 1,100 US desk workers at large companies, 84 percent were eager to embrace agentic AI in their role, while 56 percent worried about their job security alongside agents.

That is not a survey of small service firms, and it doesn't establish that the people in my marketing example felt the same way. It does show that eagerness and concern can exist in the same workforce, so an adoption number isn't enough to tell you whether the team understands the plan.

The same EY survey found that 83 percent said most of their knowledge of agentic AI was self-taught. There is something worth noticing there, people are putting effort into learning, but the company may still be leaving them to work out how that learning changes their job.

Through a franchise network's delivery data, I have watched hundreds of service firms adopt AI, often with use spreading from one colleague to another before a coordinated company effort arrives. That gives people access to useful tools, but not necessarily a shared agreement about the work.

One person thinks a tool is allowed, another thinks client data cannot go into it, and the person checking the result is not sure which parts the AI did. Those are decisions the firm should make, rather than leaving each employee to negotiate them under a deadline.

In Slack's June 2024 Workforce Index, 37 percent of desk workers said their company had no AI policy. That was a multinational survey, not a current count of policies in US service firms, but it is another example of use and company guidance failing to arrive together.

I would not assume that writing a policy resolves job anxiety. People also want to know what the owner intends to do if the company can produce the same work in less time.

Are you trying to serve more demand, improve quality, change roles or reduce staffing? You may not know the final answer yet, but you can explain what you will measure, who will decide and when the team will hear the next decision.

EY reported a 30-point difference in workers reporting productivity gains for their teams, 92 percent where the organization clearly communicated its AI agent strategy compared with 62 percent where it didn't. This is survey evidence, not proof that communication alone caused the difference.

I still think communication belongs in the implementation plan. If the team has to guess what success means for their own jobs, you have left a consequential part of the change unmanaged.

There is a retention concern as well. In the American Psychological Association's 2023 Work in America survey, 46 percent of workers worried about AI said they intended to look for another job, compared with 25 percent of workers who weren't worried.

That measures intention, not actual departures, and it doesn't prove AI worry caused anyone to leave. For an owner, it is a reason to ask what the experienced people you depend on understand about their future before assuming they will stay through the transition.

The immediate cost is easier to see in the work. A campaign gets produced around the wrong offer, a senior person reopens the brief, and somebody has to make it again, often while new drafts keep arriving.

BetterUp Labs and Stanford Social Media Lab's September 2025 research found that 40 percent of surveyed US desk workers had received low-quality AI-generated work in the previous month. Respondents spent about two hours resolving an incident, on average.

The study calls this workslop, work that looks finished but leaves someone else to recover the substance. It did not test the output-validator workflow I describe here, so I use it as evidence of downstream work, not as a measured cost of this specific design.

The authority question has research behind it too. A 2026 Technology in Society paper on AI fear of missing out at work, using OECD workplace-survey data, linked perceived loss of decision-making autonomy with that fear and identified retained human oversight as a protective condition.

That doesn't prove a particular campaign workflow creates anxiety, or that moving a brief meeting will cure it. The narrower point is that whether people retain decision power matters, and you can inspect that in the work your firm assigns.

So in the marketing example, I would put the owner or account lead on the business goal and the senior marketer on the audience, offer, evidence and claim boundaries before production starts. The junior and AI then have freedom to produce within those decisions.

Give the junior a chance to make the choices as well. Before opening the tool, ask them to write the audience, the offer, the evidence they would use and one direction they would reject, then compare that with the senior person's reasoning.

That is AI training for employees in the context of the job. Learning which button produces copy is useful, but learning why a plausible campaign should not ship is the part they need if their role is going to grow.

The senior person has to explain the correction rather than silently repair it after hours. When the junior sees which assumption was wrong and why, the next attempt can begin with better judgment instead of just a better prompt.

I don't have a measured reduction in versions or review hours from that change. The recommendation addresses the missing information directly, but you would need to count your own rework before claiming a financial result.

A separate 2026 study of 424 employees in Kunming, China found that information literacy weakened the relationship between generative-AI use and job insecurity in its model of psychological distress. That was a cross-sectional study, not an experiment assigning paid training.

So I am not presenting it as proof that a training program will reduce anxiety in a US consultancy. My recommendation is to pay for the learning time because you are changing the work and asking people to become competent at it, that is a business responsibility rather than a private evening project for each employee.

I would put the first training dates in a one-page rollout plan, alongside the workflow owner and the decisions that stay with people. The plan should also say how you will evaluate any capacity the AI frees.

You could set a defined learning period before making AI-related staffing cuts, with 90 days as one possible starting point. That is an example to consider against your cash and delivery needs, not a measured standard or a promise you should make if you cannot keep it.

During that period, look at demand, review time, rework, quality and revenue per person. You need to know whether the whole job has improved and whether there is useful work for the released capacity, not only whether staff report writing faster.

My preference is to use that capacity against demand first, then retrain people and move them into work the business needs before considering cuts. I have seen firms retain experienced teams, adjust responsibilities and train people for new functions, but I did not run a controlled network-wide comparison proving a universal result.

And if the company doesn't yet know what it can afford, say that plainly. Give the team a decision date and the criteria rather than a reassuring promise that disappears at the next budget meeting.

The limits of this advice matter. Most of the US surveys cover broad workforces or large employers, the academic evidence is not a direct study of this workflow in US service firms, and I don't have employee testimony establishing the emotional effect of one observed case.

What I can tell you is where I have seen the work go wrong, important choices arrive after AI production, and senior people inherit the corrections. Before telling those people to get more comfortable with AI, look at the next brief and make sure they have the authority to shape the work they will answer for.

Delegate the Inputs, Own the Outputs

Wed, 08 Jul 2026 13:00:00 GMT

When you are deciding how much an AI agent can do without you watching, I would start with the work you are handing over, not with how much you trust the model.

Can you check the result quickly, against something more reliable than how convincing it sounds? And if the agent gets it wrong, can you catch the mistake and undo the consequences at a cost you are willing to pay?

Those questions give you a useful starting boundary. Let agents help with gathering information, checking sources and producing drafts, but keep a named person responsible for the checks and a person in front of client-facing actions until the workflow has been properly tested and approved for them.

By freedom on the input side, I mean freedom to prepare work within those limits. I don't mean permission to send it, commit the firm or pass unchecked information into someone else's decision.

That last part matters because the first work firms delegate often looks harmless. Through a franchise network's delivery data, I have watched hundreds of service firms adopt AI, and fetching and summarizing information across Gmail, Drive and Slack is a common place to start.

It is useful work to hand over. Instead of a person opening several systems to gather the same information, an agent can bring it together and prepare something they can use.

The failures I've seen also come from that work, an analysis with a wrong number, an unchecked report, a support response that goes out without the review it needed. The task was possible to check, but the check didn't happen.

I would not describe those teams as careless. The output looked complete, the queue was long, and forwarding it was the easiest next action, while nobody had made the check a dependable part of the job.

That is the difference between saying a task is checkable and knowing it will be checked in your firm. The first is a property of the work, the second needs a person, time and a place in the workflow.

AI also gives you a different kind of mistake to look for. A human who is uncertain often gives you signs of it, while an AI answer can arrive with a confident explanation, neat formatting and a source that does not say what the answer claims.

The finished appearance encourages the send even when the content is wrong. So part of the training is learning to ignore that appearance long enough to trace the number or reference back to its origin.

I think of checking AI output as a skill people need to learn. Knowing the service helps, but people also need to recognize where generated work is likely to mislead them and what evidence is enough to accept it.

There is a useful caution about relying on your own impression of the work. In METR's July 2025 randomized trial, 16 experienced open-source developers worked on 246 real tasks, with AI tools allowed or not allowed.

When AI was allowed, they took 19 percent longer. Afterward they still believed it had made them about 20 percent faster.

That result doesn't measure your service firm's review cost, and it doesn't prove checking alone caused the slowdown. It does show that experienced people can misjudge whether a tool helped them, so I would measure completed work rather than rely only on how fast using the agent feels.

The two-question framework comes from Jina Yoon's PostHog article on agent autonomy, which asks whether the work is easy to check and whether mistakes are cheap to undo. I am applying that way of thinking to the work of a service firm, not presenting it as a scientific standard.

You can see why it is more useful than a general question about trust. A model can be good at finding a document and still be the wrong thing to leave alone with permission to send a price to a client.

And a better model can change what is feasible without removing the need for controls. The task, the data, the permissions and the person who will act on the result all matter, so model quality is part of the decision rather than the whole decision.

The simple version gives you four cases. If the work is hard to check and a mistake would be costly to undo, keep the agent in a supporting role, it can gather material or suggest options while a person owns the consequential work.

Pricing and scoping can fall there. The agent can add up costs, but deciding what a client really needs and what your firm can promise may involve judgment that a quick check will not settle.

If the work is hard to check but still cheap to redo, the agent can draft and a person can review each result. A first pass at a client email can sit in that group while it remains an unsent draft, because you can replace it without anyone outside the firm having acted on it.

If the work is easy to check but the action would be expensive to undo, let the agent prepare it and put a gate before the action. An invoice may have totals you can verify automatically, but sending the wrong invoice creates a client problem even if the accounting entry can later be reversed.

If both the work and its consequences are genuinely easy to check and undo, it is a candidate to run without someone watching every step. An internal extraction task can fit, provided the checks are operating and a named owner deals with failures.

Those examples are conditional, not permanent labels on tasks. An internal summary used for convenience has different stakes from the same summary quoted in a signed proposal, and you should ask the questions again when the use changes.

Chasing a client for missing documents is a tempting example of work to leave with an agent. It sounds routine, but a reminder still leaves the firm, and a wrong recipient, repeated request or badly timed message can have consequences you cannot remove by deleting your copy.

In Uku's 2026 accounting field report, 68 percent of respondents said they would hand document-chasing to an autonomous agent. That is willingness to delegate in that report, not evidence that every reminder workflow is safe to run without approval.

Under the starting rule in this piece, the agent can prepare the reminder and a person approves the send. A firm can later approve a tested routine-send workflow explicitly, but calling it document-chasing doesn't grant that permission by itself.

The same report found no respondent saying they already fully trusted AI, and roughly six in ten made trust depend on human approval before anything was sent or filed. Those findings concern surveyed accounting firms in eight countries, not every accounting firm.

Compare that with Upwork's Q1 2026 survey, where 62 percent of its SMB-leader sample said they were very or extremely confident handing high-stakes work to agents. The sample's revenues ranged primarily from below $1 million to $49.9 million, so it extends beyond the firms I usually write for.

These surveys ask different questions of different groups. I wouldn't line them up as proof that one group is reckless and the other is afraid, or use either as a test of whether your own agent should send something.

Go back to the job and its consequences. A confident owner can have an unsafe workflow, and an owner who doesn't fully trust AI can still build a useful, well-controlled one.

There is a stronger objection to the input/output rule than any survey, and I agree with it. An input can cause damage without ever being sent to a client, because someone inside the business may use it to make a decision they cannot easily reverse.

Suppose an agent summarizes client notes and an account lead uses that summary to set the scope of a proposal. Once that happens, it is no longer just a convenient recap, it is evidence supporting a promise.

The check needs to follow that use. Match the relevant summary back to the source before relying on it for the scope, and name who is responsible for that match, otherwise the human approval at the end is signing something whose foundation nobody checked.

That is why I keep the owner of the check next to the delegation rule. Moving work inside the building doesn't make it safe, and putting a human after the agent doesn't help if the human has no time or information to verify it.

You can improve both sides of the decision. To make checking easier, ask the agent to return the source with each important claim, separate facts from its suggestions and flag the parts it could not confirm.

You can use another agent to challenge the first result, but don't assume agreement between two models proves it is right. When the claim depends on a client's records or an external source, the check needs to reach that evidence.

For repeated low-risk work, you can build automatic checks and sample the output rather than have a person read every line forever. The sample has to be appropriate to the risk, and failures need a route back to someone who can stop or change the workflow.

To make undo easier, keep drafts as the default, limit what the agent can access and change, test restoration from backups, and separate preparation from the action that commits the firm. Those are choices you can make without waiting for another model release.

Anthropic's February 2026 research on agent autonomy classified only 0.8 percent of observed tool calls as appearing irreversible. It also found that about 80 percent came from agents appearing to have at least one safeguard, while warning that its classifier tended to overestimate human involvement.

That is evidence from the usage the researchers studied and the classifications they made. It is not a claim that 99.2 percent of actions in your firm are safe, or that restoring a file restores a client's confidence after a bad message.

The Replit database-deletion incident reported in July 2025 gives a concrete reason to care about permissions. A coding agent deleted a production database during an explicit freeze, according to the reporting on Jason Lemkin's account.

My operational conclusion is that an instruction not to act should not be your only protection against an action with that much consequence. Restrict the permission, isolate the work and test the recovery before allowing the agent near production.

You also need to know what earns a workflow more freedom. I would write down which checks must pass, how you will detect a failure, who can stop it and which actions still need a person, then test that with the actual work rather than a single impressive demonstration.

The amount of evidence you need depends on what a wrong result costs. I cannot give you one universal number of clean runs that makes every workflow ready to send, and neither can the task's name.

So start with your repeated work and sort it by the thinking required and the cost of getting it wrong. For the tasks worth delegating, answer the check and undo questions against their real downstream use.

Choose one where you can put the controls and the owner in place now. Let the agent prepare the work, inspect what the whole process produces, and keep the client send where the current approval rule says it belongs until you deliberately change that rule.

What ROI Does AI Actually Produce in a Service Firm?

Mon, 06 Jul 2026 13:00:00 GMT

If you're asking what AI will return in your service firm, I can't give you an honest percentage that applies to your company. I can tell you what I've watched improve, what had to change before that happened, and why buying the tool was only a small part of it.

In firms I've watched make that change, retention improved, margins improved, and revenue grew without headcount growing with it. But those firms were changing how they delivered the service, not just giving people a faster way to do one task.

And by the time the business numbers moved, they had also improved their processes, written down more of what they knew and made that information easier to find. So separating the return from AI from the return on all that other work became difficult.

That doesn't mean you should stop asking where the money went. It means you need to be clear about what you're measuring, because the AI ROI numbers people put in front of you often answer a different question.

Take the surveys. Wharton's 2025 report says three out of four leaders see positive returns on their generative AI investments, while McKinsey's 2025 survey says 39 percent of respondents attribute any impact on earnings before interest and taxes to AI.

Those aren't two researchers looking at the same set of accounts and disagreeing about the answer. They're asking different people different questions, and a positive return on one use of AI is not the same thing as a visible change in the whole company's profit.

The same caution applies to the Microsoft-commissioned IDC study reporting an average return of $3.70 for each dollar invested in generative AI. That's a vendor-commissioned survey result, not a promise that your next dollar will produce the same return.

You may also have seen the 95 percent failure headline attached to MIT's NANDA project. I wouldn't use that as the odds your project will fail, its methodology has been contested, and a widely repeated headline doesn't become a reliable benchmark for your firm because it has a university's name beside it.

There is a more basic measurement problem too. In Thomson Reuters' 2026 professional services survey, only 18 percent of respondents said they knew their organization was tracking the return on AI tools.

That doesn't prove the other 82 percent track nothing, some respondents may simply not know. But it does mean you should be careful about treating a person's impression of the return as if someone had checked the financial result.

Let me give you a concrete example of how far those impressions can drift. In METR's early-2025 trial, experienced open-source developers expected AI to make them faster, and afterward they still thought it had made them about 20 percent faster, but the measured work took 19 percent longer.

That's a historical result in a particular setting, not a verdict on today's coding tools. METR now explicitly says those results no longer reflect current impact, and its February 2026 follow-up found signs of improvement while explaining why changes in who joined the study made the size of the gain hard to estimate.

The reason I keep the older example is much narrower, people can be wrong about how much time they saved even when they've just finished the work. You need something better than that impression before you build a budget around it.

Now, none of this means the task gains aren't real. In the study of 758 BCG consultants, people using AI finished suitable tasks 25.1 percent faster and produced work rated more than 30 percent higher in quality.

But the same study found that, on a task outside what the model could handle, AI users were 19 percentage points more likely to get the answer wrong. So even inside one study, the answer depended on what work you gave the system.

And a published study of 5,172 customer-support agents found a 15 percent increase in issues resolved per hour, with larger benefits for less experienced workers. That's useful evidence for that kind of work, it still doesn't tell you what happens to the profit of a service firm with a different delivery process.

Think about a report your team prepares for a client. Writing the first draft faster helps, but somebody still has to check the numbers, fix the mistakes, approve it and send it, and the price you charge may still depend on how many hours went into it.

If the draft gets done sooner but sits in the same review queue for three days, the client doesn't get it sooner. If checking it takes more work than before, some of the writing gain has already been spent before you've delivered anything.

And please don't answer that by telling people to check less. The report still has to be right, what you're trying to find out is whether the new way of doing the whole job is better.

There is another place the return can disappear, even when you genuinely free up time. I've watched the early gains stay small or absent because nobody had prepared the surrounding process or decided what the team should do with the recovered hours.

The person finishing a task sooner isn't automatically the person who can decide which other work matters most to the company. That's a management decision, and if you leave it to them to guess, you haven't finished the implementation.

I've written about where the extra time goes, but the practical point here is to decide what that time is for before you count it as a return. It can go into more delivery, fewer mistakes or better care for existing clients, whatever your firm actually needs, but someone has to assign that work and check that it happened.

This is part of why the change takes longer than the software setup. In franchise units where everyone wanted AI to speed up delivery, I've watched it take about six months, and in firms where people weren't engaged or a bad first implementation had done damage, I've watched it take over 18 months.

Those are timelines I've observed, not a payback guarantee. Some firms were still working through the change, and getting people to use something after a bad first experience was part of the work they had to pay for.

You need leadership to support it, people inside the team who help it along, and a clear account of how the work is changing. If the team thinks the purpose is to replace them, you can't expect a tool demonstration to settle that fear for you.

They need to know what they're responsible for, what they still have to check and what the company expects them to do with the new capacity. You can ask them to help work that out, but you can't hand them a login and call the uncertainty their resistance.

As firms get further into this, the return spreads across work that wasn't in the original tool pitch. Better information helps someone prepare a proposal, brief a meeting, follow up with a prospect and plan the next piece of client work.

And when the proposal improves, how much came from the AI and how much came from finally having the client's history in one place? You can measure that the process improved without pretending you can separate every cause cleanly.

I wouldn't take that as permission to stop measuring individual tools, either. A narrow tool can have a perfectly useful, measurable return, and an implementation that is hard to measure can still be a bad investment.

My point is that demanding one isolated AI percentage for a whole-company change can push you toward measuring the easiest part instead of the part you actually wanted to improve.

There is an older version of this problem in Paul David's work on factory electrification. Replacing the power source wasn't the whole change, factories also had to reorganize work around what electric motors made possible.

And Erik Brynjolfsson, Daniel Rock and Chad Syverson's research on the productivity J-curve explains how spending on things like new processes and skills can be poorly captured in the early productivity figures. The work is real, but the accounts don't necessarily show its benefit when you're doing it.

That gives us a reason to expect a difficult early stretch, it doesn't prove every AI project is about to pay off. You still need to distinguish a firm that is doing the necessary work from a firm that keeps spending and calling the lack of progress a transition.

And you also need to look at how you charge. If you bill by the hour and the same deliverable now takes fewer hours, you can improve the work and reduce the revenue from that engagement at the same time.

Under a fixed fee, the same saving can help your margin if quality holds and the other costs don't eat it. So two firms can use the same tool, save the same amount of time and end up with different business results because their prices work differently.

Clients have a view on this too. Bloomberg Law's reporting on an ACC and Everlaw survey found that nearly 60 percent of the in-house counsel surveyed saw no noticeable savings from their outside firms' AI use.

My read is that you shouldn't assume a client will keep paying for visible effort that is getting smaller. That doesn't mean every client will demand a discount, or that every service should be priced by outcome, it means the pricing decision belongs in your plan rather than arriving as a surprise after the task gets faster.

So here is how I would approach the money question in your firm. Pick one repeated piece of work, write down how it runs today and count the whole cost of getting an acceptable result, including the person who reviews it and anything that comes back to be done again.

Then include the cost of the change, the tool, the setup, the training and the time people spend getting the new process to work. Those hours don't become free because they're on an existing employee's calendar.

Decide which business number you expect to move and why. The Four Numbers are cost to acquire a client, cost to deliver, retention and price, and you don't need all four to move at once to learn something useful.

If you're trying to reduce delivery cost, start there, and keep checking quality beside it. If the aim is better client service, decide what improvement you'd expect to see before you start calling every saved minute profit.

Then look at margin and revenue per person over time to see whether those changes reached the business. A quarterly review can help you keep that longer view, while the people running the work need a closer check on errors and rework as the new process settles in.

You may find a good task-level gain that hasn't reached the business yet. You may find that the tool isn't earning its cost, or that the gain is real but your pricing model gives it to the client, and those are different decisions.

I can't promise you the return will arrive on the same schedule I've seen elsewhere. What I would ask you to do before the next rollout is sit down with the person who owns the work, agree what should improve, count what changing it will cost, and decide how you'll know whether that improvement happened.

Age Predicts Who Adopts AI. Skill Predicts Who Benefits.

Fri, 03 Jul 2026 13:00:00 GMT

Before you decide AI means you should hire fewer juniors, I would look at what those juniors can do with it, and at where your next senior people are going to come from.

Those are two different parts of the same decision. You can save money on the work being done today and still leave yourself with nobody learning how to do the work you'll need later.

What I've watched in service firms is more useful than the story about young people understanding AI and older people not getting it. Some firms are adding juniors and giving them AI for work where mistakes are less costly, while keeping experienced people responsible for the decisions that can do real damage.

So the question I would use to sort the work is how expensive it is to get it wrong. Age can tell you something about who reaches for the tool, but it doesn't tell you who should be responsible for what comes back.

There is research behind part of that distinction. In the customer-support study described by MIT Sloan in 2023, the least experienced workers resolved 35 percent more chats per hour with AI assistance, while productivity was essentially flat for those with the most skill and experience.

That was a finding about particular support work, not a rule that experts get nothing from AI. It does tell you that being the best person at the old version of a task doesn't automatically mean you get the biggest gain when the tool arrives.

A junior can have more to gain because the assistant helps with things they haven't learned yet. And the senior who already knew those things can still benefit on different work, research, preparing materials, pulling together information before a decision, which is what I've watched happen in firms using AI well.

Even the adoption story is less neat than the headlines suggest. Slack's 2025 Workforce Index reported that desk workers aged 28 to 43 were more likely to use AI daily than Gen Z workers in its survey.

That's self-reported use in a vendor survey, not a skills test. I'm mentioning it because choosing the youngest person in the room to lead your AI work isn't a sound way to choose, and neither is assuming your experienced delivery lead won't understand it.

Now look at what's happening to entry-level jobs, because the concern about juniors isn't imaginary. In its August 12, 2026 revision of the Canaries paper, Stanford's Digital Economy Lab reported that employment of workers aged 22 to 25 in AI-exposed occupations stood 19 percent below where it would have been if it had kept pace with their less-exposed peers.

That analysis used payroll data through June 2026, and the authors found no comparable gap for experienced workers. They also found that the change was happening mainly through reduced hiring of young people, rather than more people leaving their jobs.

So don't read that as 19 percent of young workers being fired by AI. It's a relative employment gap between groups of young workers, and the researchers also say they find no evidence of widespread, economy-wide job displacement.

The pattern is consistent with AI affecting some early-career work, but it doesn't settle the cause of every hiring decision. What matters for your decision is that a leaner junior layer can look normal in the market without being the right design for your company.

Think about the usual service-firm setup. A junior prepares the work, a senior checks it, and the firm charges enough to cover both people's time and still leave a margin.

AI changes parts of that arrangement because the first pass can take much less effort. Research gets gathered, a report takes shape, a meeting becomes a set of notes, and the junior can prepare more than before.

But a report that looks finished isn't necessarily ready for the client. If every extra report creates another piece of work for the same senior person to repair, you haven't removed the constraint, you've sent more work into it.

This is the strongest objection to keeping juniors, and I wouldn't brush it aside. You may already have tried junior-plus-AI and found that the senior review hours cost more than the junior hours you saved.

That is a real cost, and giving the junior a better prompt doesn't automatically remove it. You need to decide which tasks can be checked in a clear, repeatable way and which ones still need experienced judgment throughout.

For a first pass at meeting notes, the reviewer can compare the actions with the transcript. For a recommendation that changes the client's tax position or commits your firm to a price, checking the wording isn't enough, someone needs to understand the decision and what happens if it's wrong.

That's the risk line I'm talking about. Work that is expensive to undo, can damage a client's trust or creates legal trouble stays attached to someone with the experience to own it, even if AI helps prepare most of the material.

Below that line, juniors can use AI to handle more of the preparation and routine work, with a named person responsible for how the output gets reviewed. Calling it lower risk doesn't mean nobody checks it, it means the check can be designed without asking a senior to repeat the whole job.

And above the line, the experienced person should get the tool too. They can use it for research, drafts and the routine steps around the decision, so more of their time goes into the part the client needs them to get right.

I have watched firms add juniors under that arrangement, because they could take on more of the lower-risk volume while training into the firm's way of working. Those firms were deliberately giving the juniors less of the high-stakes work, not treating a convincing AI answer as a substitute for experience.

There is a limit to how far you can carry that observation. I don't have a staffing ratio that says one senior with AI replaces a certain number of juniors, and the right mix will be different in an agency, an accounting practice and an engineering firm.

But I do think the training question belongs beside this quarter's delivery cost. If the reason your seniors are good is that they spent years doing the simpler work, making mistakes and getting corrected, removing that simpler work changes how the next group learns.

The Harvard Law School Center on the Legal Profession's essay on the training crisis makes that point for law firms, the work at the bottom of the pyramid is also where people learned to reach the top. You can't assume some other employer will keep paying for that training while your firm only hires the finished result.

So I would keep juniors close to the judgment work. Let them review an AI draft, explain what they think is wrong and compare that with what a senior notices, because the difference between those two readings is part of what they need to learn.

That doesn't happen just because the tool saved an hour. Someone has to protect time for the senior to teach, otherwise the junior gets faster at producing things without getting much better at judging them.

And there is another reason to leave room for juniors, they can be the people who find the better way to do the work. I've watched them lean into the tools, try things their seniors hadn't considered and show the rest of the team what was possible.

On one team I watch, a junior handled meeting follow-ups by copying each transcript into an AI chat, asking for a summary and then entering the agreed tasks into the project tool by hand. It took about ten minutes to summarize and twenty minutes to enter the tasks, across about twenty meetings a week.

On the first day the team moved to an agent setup, that junior built a skill that read the transcripts, pulled out the tasks, filed them in the project tool and dated them against what the meeting had agreed. Nobody senior had asked him to build it.

That removed about ten hours of manual work from his week, with fewer mis-dated tasks. That's the observed time saving and the improvement we saw in dates, not a measured claim that every output was correct or that the firm earned ten extra billable hours.

The useful part is that he knew the repetitive work well enough to see what could change. If you only think of him as a cheaper person producing the first draft, you miss that contribution.

Now let me show you where this sorting can go wrong, because judgment can hide inside a task that looks routine. I've watched this in process mapping, inventory and finance, where a junior gets something from AI that looks right until an experienced person reads it.

Take a process map. The junior interviews the staff and gives the transcripts to AI, and the result is a clean account of how the work supposedly happens.

But people have described what they say they do, not necessarily what they actually do. It takes experience to notice that two departments have given answers that don't fit together, before the firm rebuilds the process around a description that was wrong to begin with.

So being easy to undo isn't the whole test. You also need to ask who will notice a mistake, and whether it can keep affecting later work before that person sees it.

In law, tax, healthcare and engineering, more work belongs above the risk line because a plausible mistake can carry a much larger cost. The same sorting idea still helps, but it doesn't give you permission to drop professional review or legal duties.

I would expect sorting recurring delivery work properly to take real time, plan it as work over a quarter rather than something you announce in a memo. Start with the tasks your team repeats, including the boring ones, and sit with the people who do and review them.

For each task, decide what happens if it's wrong, who can check it and who stays responsible. Then give the lower-risk work to the junior with a clear check, and keep the high-stakes decision with the experienced person while helping them with its preparation.

Choose the person who runs this by their knowledge of delivery and their ability to help colleagues change, not their birth year. Give them the authority and time to change the work, because enthusiasm on its own won't clear a review queue.

And make a place for the ideas coming from the team to be tested and shared. The transcript workflow didn't need a company-wide reorganization to teach the people around it something useful, it needed someone to notice it, check it and help it spread.

This assumes your firm actually has a junior layer and someone who can teach and review the work. If everything still runs through you, the problem is how to divide work between you and AI, and that needs a different plan.

Before you remove the next junior role, look at the tasks it contains and the experience someone would gain by doing them. Decide what AI can take over, what the junior should learn instead and who will help them learn it, then make the hiring decision with all of that in view.

Your AI Is Just a Better Google Search

Wed, 01 Jul 2026 13:00:00 GMT

If your AI can't reach the information your team works with, you spend a lot of your time explaining the company to it before it can help you.

You copy in the client notes, explain what happened in the meeting, find the old proposal and tell it how the firm likes things written. Then you take the answer back into the tools where the work actually happens.

That can still be useful, I don't want to dismiss it. But in the firms I've watched, the larger change starts when AI can work with the right company information and follow the firm's rules, so people no longer have to carry everything into and out of the chat by hand.

Without that connection, a lot of what you've bought is a better Google search. It helps someone find or prepare an answer, while the job around that answer stays much the same.

I want to walk you through a public example, because it shows the work that tends to disappear from the AI success story. In July 2026, Replit published The Self-Driving Company, describing how it had put agents into work across the business.

The number that gets your attention is 2.9 times as much code from the same group of authors. Replit also says its trends for code reversions and production incidents stayed flat, and that its hardest support tickets, those escalated to humans, closed 60 percent faster.

Those are Replit's own figures. The post doesn't establish an independently audited productivity result, and writing more code is not the same thing as creating proportionally more value for the company.

So I wouldn't put 2.9 times anything into your plan. What I would look at is what Replit says it did before the increase, because that is the part a service-firm owner can learn from without pretending to run an AI software company.

First, it built a controlled place for agents to work. It put rules around what they could access, recorded their actions and protected the network, and only then gave them access to the systems its people used, including GitHub, Slack, Notion and Zendesk.

That's an important order. Connecting the company doesn't mean giving an agent every password and hoping the instructions are enough, it means deciding what information it needs and what actions it is allowed to take.

Then the support team gave the agent skills for investigating problems and following its standard playbooks. The data team also made the company's data easier for the agent to understand, so it could work with what the numbers meant and how they related to each other.

Basically, the firm supplied the context and the rules that a good employee would need. The model didn't discover Replit's operating procedures by being clever, people did the work of making those procedures available.

I've watched hundreds of service firms adopt AI through a franchise network's delivery data, and the same part matters there. When agents can bring together the relevant files, emails, calendar entries, CRM information and meeting transcripts, they can help with work that a disconnected chat struggles to do.

A follow-up can start from what the meeting actually agreed. A proposal can use the firm's previous work and the client's history, and a project update can draw from the documents and messages where the project is being run.

Those are possible workflows, not promises that you can connect the accounts and leave them alone. Someone still needs to decide which source to trust when two records disagree, what the agent should do if information is missing and who checks the result.

That is where people's jobs can begin to change around the tool. They spend less time gathering the same material and more time deciding what to do with it, but the gathering has to work well enough for them to trust it first.

If your rollout hasn't reached that point, I wouldn't start by blaming the team for only asking simple questions. They may be using the only part of the tool you made practical, while the company information and the authority to act are still somewhere else.

You own the work needed to close that gap. Your people can help write the instructions and test them, but they need time to do it and someone who can make decisions when the current process doesn't fit.

There is a temptation to use the failure statistics as proof that connection is the whole answer. It isn't, and the famous MIT NANDA headline doesn't establish that every stalled project failed for the same reason.

Fortune's August 2025 coverage described a learning and integration gap in the report, with tools that didn't adapt to how firms worked. That's secondary reporting on a report with contested methodology, not a measured explanation for every company that bought a chatbot and saw little return.

The more useful question is what you can actually see inside your rollout. In Thomson Reuters' 2026 survey, organization-wide AI use rose from 22 to 40 percent, but only 18 percent of respondents said they knew their organization was tracking the return on its AI tools.

That doesn't prove the rest weren't measuring, because respondents may not know. It does show why you shouldn't assume that more use comes with a clear account of what improved.

And when the agent can act in your systems, seeing what it does becomes even more important. Sinch's May 2026 research release says 74 percent of surveyed enterprises had rolled back or shut down a live AI customer-communications agent after a governance failure.

That was a survey of 2,527 senior decision-makers at organizations with at least 1,000 employees, so it isn't the failure rate for a consultancy your size. It also measures whether a company had pulled back an agent, not the percentage of all agents that failed.

Sinch reported an even higher rate, 81 percent, among organizations with mature controls, and suggested better monitoring was helping them find failures others missed. That's the company's interpretation of the pattern, it doesn't prove that controls caused the difference.

But I agree with the operating point, being able to notice and stop a bad run is useful. A quiet system isn't necessarily a good one, it may just be a system that isn't showing you enough.

So what would I copy at your size? Start with one internal piece of work where the source material already exists, rather than trying to connect every department at once.

Meeting follow-ups are one possibility. You already have notes or transcripts, somebody already turns them into tasks, and you can compare what the agent proposes with what the meeting actually agreed.

Before you let it change the project tool, decide which meetings it may read, which projects it may write to and which proposed actions a person must approve. Keep a record of the source and what the agent did, so a wrong date can be traced and corrected rather than becoming a mystery later.

Then write down the procedure the person currently follows, including the parts that require a decision. If a task has no owner, if the transcript doesn't give a date, if two people disagree, the agent needs a rule for stopping or asking, not encouragement to fill the gap.

This is the documentation work firms tend to skip because their experienced people already know how to handle those situations. But if the rules live only in their heads, neither an agent nor the next hire can reliably follow them.

And the documentation isn't done when it reads well. Give it to someone who does the work, try it on real examples and see where they need to add information, because that is part of the process you've been relying on without writing it down.

For customer service, my recommendation is to keep the first agent in an internal support role. Let it research the account, gather the history and draft the reply, while a person stays responsible for what goes to the client.

Replit's 60 percent figure is specifically about tickets escalated to humans, which makes that part of its story relevant. Its post also says the agent can offer a response or escalate, so I'm not claiming Replit kept a person sending every reply, the stricter starting boundary is my advice for your firm.

Once that internal process works, you can decide whether a narrower set of replies is safe to automate. That decision needs evidence from the work and a way to catch mistakes, not just the fact that another company calls itself self-driving.

I would also be careful about copying Replit's decision to build its own tools. It says it canceled a seven-figure software contract because an internal application was better, and that may be a good decision for a company whose own product is software for building software.

It doesn't follow that your accounting practice should replace its main systems with applications an agent made. Buying a suitable product also buys you some of the maintenance and support, and if you build, that responsibility still has to belong to someone.

My starting preference for a service firm is to use the tools that already fit, connect them safely and find out what problem remains. Build when you can name the gap, judge whether the result is right and support it afterward, rather than because generating the first version has become easy.

There is a measurement trap here too. METR's early-2025 developer trial found people believed AI had made them faster even though their work took longer in that experiment.

METR now warns that the finding no longer represents current tool impact, and its February 2026 update describes evidence of improvement alongside problems measuring it. So I use the old trial as a warning about trusting impressions, not as proof that today's tools slow your team down.

For your own rollout, follow the work to an acceptable result. How long did it take, how much checking was needed, what had to be redone and what did the tool and the setup cost?

Replit's report is more useful when it talks about reversions, incidents and review time than when it only talks about code volume. Copy that habit of putting quality beside output, while remembering its chosen measures don't capture every kind of quality either.

And decide what any freed time is supposed to make room for. Otherwise you can get a better-connected tool and still lose the benefit in the work around it.

There is usually a person involved in helping this change spread. In firms I've watched, someone starts improving workflows, creating agent skills, sharing instructions and helping less technical colleagues use the tools, often before anyone gives them a formal role.

I call that person an AI enabler. They aren't necessarily a new hire, and noticing them is only the first step, they need time and support if you're going to ask them to help the rest of the team.

Replit describes people seeing engineers use the agent in Slack and trying it themselves. That gives you a more useful thing to encourage than a contest over who sends the most prompts, let people see a piece of work improve and help them try it on their own work.

You can plan an initial round of this over a quarter, but the scope has to fit what you're starting with. If the source information is missing or nobody can judge the output, connecting more systems will not fix that for you.

So take one internal workflow to the person who owns it, write down what the agent needs to know, what it may do and where it must stop, then test whether the whole job gets better. Expand after you can show that, not after the first answer looks impressive.

AI Projects Don't Fail at Your Size. They Go Underground.

Mon, 29 Jun 2026 13:00:00 GMT

An AI project can stop working in your firm while the team keeps using AI, and from your side of the business it can look as though the rollout succeeded.

The proposals arrive faster, people talk about the tools, and the client still gets the work. What you don't see is that the approved system lost its place and someone went back to a personal ChatGPT account to finish the job.

I saw this at a firm that introduced an internal AI tool for proposals and reports. It was supposed to replace people copying client notes into personal accounts, but it kept losing the client context that made the proposal useful.

With two hours left before a Thursday proposal deadline, a consultant went back to ChatGPT. Later, in a staff interview, the consultant explained it plainly, “I had two hours left. I used what I knew would work.”

Now, you can read that as an employee refusing to follow the new process. But the client deadline hadn't moved, the approved tool wasn't giving them what they needed, and the old path had worked before.

That doesn't settle whether the personal account was safe to use. It does tell you what problem the employee was solving, and it wasn't the problem management thought the rollout had already solved.

The proposal's version history showed the change. The first draft had the internal tool's generic structure, while the final version changed voice and included language from the team's old ChatGPT prompt.

By the next week, that prompt was being shared again. The team hadn't stopped wanting AI, some of the work had simply moved back to the route they knew.

And the owner had reasons to believe the new system was working. He had seen it demonstrated in Teams, proposals were arriving faster, and people were openly talking about using AI.

Those signals told him something true, the work was AI-assisted. They didn't tell him which tool had produced the version that reached the client.

That's the failure I want you to look for after a rollout disappoints. A canceled project can leave no AI in the workflow, but it can also leave shadow AI, work happening in tools the firm hasn't approved or can't see.

In this case the personal use existed before the rollout. The new tool didn't create it, the rollout made it easier to mistake the existing workaround for a working company system.

The cost is more than a license nobody uses. Client information is going into a different account, the prompt shaping the answer isn't the shared company prompt, and managers may be checking the result under different assumptions.

I have seen one manager check every AI-written sentence while another assumes the approved system has already done the checking. If they don't even know which system made the final version, they aren't starting from the same picture of the work.

I have also seen fabricated statistics used with client financial data. My records stop there, I don't have a recorded discovery time, client response or account of how that case was fixed, so I won't turn it into a more complete story than it is.

You don't need a public incident to have a problem worth correcting. When the source and prompt stay in one person's account, a correction made there may never reach the next person preparing the same kind of work.

The firm keeps producing, but it isn't keeping a shared account of what went wrong and what should change. So the next proposal can start with the same weakness, even though somebody already learned the lesson.

This is why I would ask which tool produced this version, rather than asking whether the team uses AI. The second question can get an enthusiastic yes while leaving the failed rollout completely hidden.

Now let me separate that from the big failure numbers, because they don't tell you how often this happens at a firm your size. When people ask why AI projects fail, they often get a statistic about a different kind of project, or a forecast presented as something that has already happened.

Fortune's August 2025 coverage of MIT NANDA reported that the vast majority of the enterprise pilots it described were stalled, with little to no measurable impact on profit and loss. That's the coverage behind the widely repeated 95 percent headline.

I'm relying on Fortune's account here. The report's methodology has been contested, and its headline is not a measured probability that your proposal tool will fail, much less that your staff will return to ChatGPT.

In 2024, Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025. The same release discussed deployment approaches costing $5 million to $20 million, which gives you an idea of the scale of change it was talking about.

And Gartner's June 2025 forecast put cancellation of agentic AI projects above 40 percent by the end of 2027. Those are dated forecasts, not a count of what subsequently happened.

The causes in the research can still help you. RAND's 2024 report, based on interviews with 65 experienced data scientists and engineers, describes teams solving the wrong problem, lacking suitable data or the systems needed to use it, choosing technology for its own sake and asking AI to do work beyond its ability.

That last part matters, because the answer isn't always better management or another connection between tools. Sometimes the task itself is a poor fit, and no amount of pressure on the team changes that.

But the interviews don't give you a measured failure rate for small service firms. RAND's much-quoted “more than 80 percent” line is introduced as an estimate from elsewhere, not a rate calculated from those 65 interviews.

I would use this research to ask better questions about the work, not to assign your firm a set of odds. In the proposal case, we could name the failure much more precisely, the tool lost client context and the workflow still required a client-ready proposal by Thursday.

I've seen other paths into the same kind of problem too. Leadership buys something the team hasn't had time to learn, or everybody wants the tool but it can't fit the way the work is done, or employees want to improve the process and the company won't fund the tools and time it would take.

Money, learning time, people and agreement about the job all matter. If you only fund the software, the team still has to find the rest of those things somewhere in the working week.

But I don't want the title to leave you thinking every failed project continues in secret. I also saw a finance workflow where the approved tool was too slow, failed and stayed dead.

That work involved payroll and client cash data. Access was limited, uploads were monitored, and the finance manager required a source trail for every conclusion, so staff couldn't quietly complete the same work in a personal AI account.

That's the counter-case, and it's an important one. In the proposal workflow, there was a working route around the approved tool, while the finance workflow had boundaries that prevented that route.

So after a rollout fails, inspect what actually happened rather than assuming either that AI stopped or that everyone went underground. You can start with one recurring task and follow the latest finished version back through its sources.

Ask which tool produced it, what the person used that tool to do, what client or company information went in and where the output went afterward. Then name who checked it and what source or rule they checked it against.

Version histories, source records and a conversation with the person doing the work can give you a much clearer picture than the count of active licenses. Explain that you're trying to understand the working process, because if the conversation feels like a hunt for someone to blame, you make the next workaround harder to see.

Then decide whether the use should be approved, changed or stopped. Approval needs a clear data boundary, a reviewer who can judge the result and a shared way to record corrections, not just a decision that the output looked good this time.

If it needs changing, give people protected time to learn the replacement. The Production Gap calls this the Unfunded Hour, the learning work a company expects while leaving the person's delivery commitments unchanged.

And if a use exposes restricted information or cannot be checked safely, stop that exposure rather than waiting for a nicer tool. Keep the work manual or use another safe fallback while you prepare the replacement, because protecting a deadline can't make an unsafe route acceptable.

Where the issue is fit rather than immediate risk, have the workable replacement ready for the next deadline before you remove the route the team relies on. Otherwise you've recreated the choice that sent the consultant back to ChatGPT in the first place.

Give the person who found the workaround a say in the redesign, and give them credit for what they learned. Don't quietly make them the unpaid trainer and support desk for the entire firm, with responsibility for every future mistake and no authority to change the system.

This check assumes you can inspect the workflow and name someone who can judge the output. If you can't, keep that work manual until you can, and start by finding out which tool produced the last version your client received.

The Extra Time AI Buys You Is Already Gone

Fri, 26 Jun 2026 13:00:00 GMT

Your team can get faster with AI and you can still finish the week with the same amount of work done.

The tool works, people are using it, but the extra time you thought you were getting doesn't seem to show up anywhere.

And if you're looking at that and wondering why people aren't doing more, let me tell you what we experienced at Berry, because we had this problem too.

We could do more, but we weren't properly guiding the teams toward what to do with that time, so it was being lost. We had improved what people could do without properly changing how we managed the work.

That's the part I want to talk about, because getting a report written faster and getting more useful work out of your company are two different things, and somebody has to do the work between them. If you run the company, that somebody needs your help.

Now, the obvious explanation is that people are stretching the work because they don't want more of it. And yes, I've seen the remaining tasks stretch to fit the same hours, checking a report starts taking longer, other parts of the job take up the time that was saved.

But from my perspective, calling that a problem with the team lets management off far too easily.

Think about what we've actually asked them to do. We give them a faster tool, but the work they're responsible for stays the same, and we haven't decided what finishing sooner should make room for.

Then we expect them to figure out which other work matters most to the business, how much of it they should take on, and what they can stop doing to make that happen.

Those are management decisions. Your team can help you make them, of course, but they shouldn't have to guess what the plan was supposed to be.

At Berry, we had to improve how supervisors and managers guided their teams toward process improvement, better customer experience, ways to reduce errors and rework. Basically, the work that would help the business but wasn't being picked up just because people had a better tool.

I don't have before-and-after numbers to give you for that, what I'm describing is what we experienced, not a measured result I'm promising you.

And notice that none of those things has to mean giving someone more clients. If you use the time to fix a process that keeps causing mistakes, that's useful work. If you use it to take better care of the clients you already have, that's useful too.

But you have to decide that's what the time is for, and make it part of the job, otherwise it's just another thing everyone agrees would be good to do someday.

This is the AI productivity paradox, individual tasks get faster but the company doesn't seem to get the benefit, and I want to give you a little of the research without turning this into a list of numbers.

In a writing study published in Science, people using ChatGPT took 40 percent less time to do the writing tasks. That's a real result for the work those researchers tested, and it's easy to see why an owner would look at that and expect a big change in their own company.

Now look at the company side. A separate NBER survey asked nearly six thousand executives across four countries what AI had done for their firms over three years. Eighty-nine percent reported no effect on how much work they produced per worker.

Those weren't the same people doing the same work, so you can't put the two studies next to each other and calculate how much time went missing.

And the company figures were what executives reported, not somebody going through all their files to check the output. But they give you a reason to ask the question inside your own firm, because a faster task on its own doesn't tell you what happened to the business.

You might say we just need to give it more time, and I agree that changing how a company works takes time. You don't give everyone a login on Monday and expect a different company on Friday.

But the waiting has to include doing something differently. In a Census Bureau paper, 64 percent of firms using AI said they hadn't made any changes to how the company was organized to use it. So for a lot of firms, the tool arrived and the way the company worked stayed where it was.

What I've seen at Berry and in client work is one way that can play out, people get faster at part of the job and the work around it takes the time back.

The studies don't prove that this is where their missing gains went, that's my observation, and I'm not saying it explains every company. It is something I would check before buying another tool to solve the problem.

Because there is another possibility, and you need to separate it from time that was saved and then lost. Sometimes the saving wasn't there once you counted the whole job.

Take a report as an example. AI helps someone write it faster, but someone still has to read it, check the numbers, fix anything that's wrong and get it ready for the client.

If that part takes longer now, you have to count it too. You can't take the time saved on writing and call it a win while leaving the person checking it out of the calculation.

And please don't take that as a reason to tell people to check less. If the report needs checking, it needs checking, the client doesn't get a worse report because we wanted a better number for our AI project. You need to find out whether the new way of doing the whole job is actually better.

So I would start there, before making any promise about what the team can take on. Pick one piece of work and follow it all the way through, from what comes in to what the client actually receives.

Write down who touches it, how much time they spend, what gets checked and what gets sent back to be done again. You need a picture of the work as it happens today, because later you're going to compare against it, and memory isn't good enough for that.

Then, before you put the tool into that work, decide what you want any saved time to make room for. Maybe it's more client work, maybe it's fixing the process that keeps sending reports back, whatever your firm actually needs.

The important part is that you name the work and somebody is responsible for assigning it.

I would put that in the same plan as the tool and the training. People need to learn how to use the AI, but they also need to know how their job is changing with it, what they're still responsible for checking, and what they should work on when that time becomes available.

Otherwise you teach them a faster way to do the old job, let them settle into it, and come back later to say you expected more all along.

From their side, you have changed the agreement after they learned the work. That is a harder conversation than explaining the new way of working before you start.

And once it's running, go back to the work you measured and look at the whole thing again. Did writing get faster, did review get slower, are fewer things coming back, how much time did it take to get something the client could actually use?

If the writing got faster but the finished report took the same amount of work, you don't have those hours available yet. You have a part of the process that improved and another part you still need to work on.

If you did free up time, check whether the work you planned for it is happening. Don't stop at someone saying the tool saves them time, go and look at the process they were going to improve, the client work they were going to take on, whatever you agreed those hours were for. That's how you find out whether the change reached the business.

You don't need to turn this into a company-wide project before you can learn anything. Start with the piece of work you're about to change, measure it properly and have the conversation with the manager who owns it.

If nobody has the authority to change what the team works on, sort that out before you count on getting more done.

So before your next rollout, sit down with that manager and decide what the team will do if the time is actually freed, and how you'll check that it happened. Don't leave them to guess.

What Is an AI-Native Service Business?

Wed, 24 Jun 2026 13:00:00 GMT

An AI-native service business is a firm where AI does the repeatable production work using the company's shared knowledge, and people review the result and own the decisions that need judgment.

So when a client needs a proposal, the process doesn't start with someone opening a blank document and telling a chatbot everything they remember. The system can work from the recorded conversation, the firm's past work and its rules, and a person checks the proposal before it goes anywhere.

That's the distinction I would look for, because an AI-native company isn't something you can identify from the tools on its subscription list. You need to look at how the work is being done and what information the people and systems doing it can use.

I've watched hundreds of service firms adopt AI through a franchise network's delivery data, and the first thing I notice in firms getting further along is how information flows. More of what the firm knows gets recorded, connected and made available to AI under the firm's control.

That includes meeting transcripts, sales calls, client messages, email, CRM records and the information in the project tool. Things that used to exist only in someone's head start becoming material the company can work with again.

Let me give you a simple check. If someone needed the full history of one client, where would they look, and how much would they still have to ask a particular person to remember?

A lot of firms have plenty of information, but it is split between inboxes, messages and people. Finding it takes experience, because knowing which person to ask and which old document to trust is itself part of what the senior team knows.

If you give AI the same scattered material without those distinctions, you've made more information available without necessarily making it usable. You still need to decide which record is current, what an update replaces and who is allowed to see it.

Software engineers have a useful way of thinking about this. We work with a repository, usually called a repo, where a team keeps its code, tracks changes and shares the approved version of the work.

A repo doesn't magically contain everything every engineer knows. People still have to write things down, resolve conflicting changes and keep the supporting information useful, but it gives them a shared place to do that work instead of each person keeping a private version.

I think an AI-native service firm needs that same relationship with its company knowledge. There should be a dependable shared account of what the firm knows, with access rules, a record of changes and a way for new decisions to reach the people and agents that need them.

That doesn't require you to move every email and every client record into one giant folder. The information can remain in connected systems, as long as the firm can make clear which sources to use and keep the permissions intact.

The point of one shared home is that the answer shouldn't depend on which employee happened to be in the room. And it certainly doesn't mean every employee or agent should see every client's information.

Some of the systems I've been building and studying are early versions of this. Much of my research is about adapting software-engineering practices to service delivery, because tracking changes, controlling access and keeping a common version of the work matter in a service business too.

I don't think the finished playbook exists yet. My estimate is that even if AI stopped improving, we would have years of work exploring what we can already build, because so much company knowledge still needs to be made usable.

Now, you don't have to reach that whole picture before AI is useful. There are steps between individual help and a changed delivery model, and the distinction helps you avoid calling the first step the destination.

I use AI-enhanced for a firm where people do the same work and AI helps with pieces of it. Someone writes faster or summarizes a document, but the process around them stays where it was.

AI-augmented means you have rebuilt a particular part of delivery around AI. The proposal may begin from recorded discovery notes with a shared set of instructions and a review step, while people still do much of the work between those improved parts.

And AI-native means the delivery model itself runs around that arrangement, shared company knowledge, AI doing a substantial part of the repeatable production, and people responsible for the judgment and the result. These are working distinctions, not certifications or a claim that everyone in the market uses the words the same way.

The AI-Native Firm describes a related progression for professional services. My Delivery Model Ladder is the longer explanation of how I think about that climb in an existing firm.

Take the proposal again. In the more developed version, AI can use the lead call, past engagements, pricing history and the firm's recorded terms to prepare a draft that fits the situation.

A senior person checks that the facts are right, adjusts the decisions and approves what the firm will commit to. The next proposal uses the same process, and if the firm changes a rule, the shared process can carry that change forward.

Compare that with a team where everyone starts a fresh chat and writes their own instructions. Both teams use AI, but in the second team the company is relying on each person's memory and prompting habits to reproduce its standards.

That's not a judgment on the employees, it's the process you've given them. If you want the firm to learn from corrections, someone has to make those corrections part of the shared way of working.

This is where I use the word proofwork, the human work of checking what the system has done and taking responsibility for what leaves the firm. It sits at the center of Proofwork, the system I use to connect machine production, human judgment and business results.

And proofwork isn't just proofreading. A proposal can have perfect grammar and still promise the wrong service at the wrong price, so the person reviewing it needs to understand the decision, not just the text.

There are public examples of this split. Forbes' reporting on Lightbringer describes AI helping draft patent filings while attorneys review the work and retain professional responsibility.

That is evidence of a different workflow, not proof that its legal judgment is better. The distinction matters, because changing who prepares the material doesn't remove the professional's duty to judge it.

At Crosby, Emergence Capital describes lawyers sitting beside engineers and giving feedback every few hours so the system can be improved. Emergence is an investor writing about the category, so I treat its examples as attributed accounts, not independent audits.

What I want you to notice is that the feedback is part of running the business. The people who understand the work stay close to the people changing the system, instead of being asked to report a problem and wait for an unknown future release.

Something similar happens to the information-carrying part of management. If the project record is kept current and people can find the latest decision themselves, someone needs to spend less time chasing updates and passing them along.

I've seen one firm further along in AI adoption move managers into other functions after that part of their work disappeared. That is one observation, not evidence that management as a whole goes away.

Coaching someone, resolving a disagreement and deciding what the team should work on next are still real jobs. A shared record helps with them, but it doesn't make those responsibilities disappear because nobody has to assemble the status report anymore.

The financial change comes later, and it needs checking too. If AI reduces the manual work of writing, copying, filling forms and fetching information, the firm can get more through delivery without adding the same amount of human production time.

But the savings have to survive review, mistakes, tool costs and the work of keeping the system running. You can't describe a margin gain while leaving the people who check and fix the output outside the cost of delivery.

Emergence makes a useful warning in its playbook, growth alone doesn't prove AI is doing enough of the work. It asks firms to look at gross margin, revenue per employee and whether delivery still requires staffing to grow alongside clients.

I would use those as questions, not as a label test decided by one quarter's accounts. You may be investing in the change or choosing to put capacity into better service, so flat margin alone doesn't prove AI is decoration.

And pricing changes what you keep. If you charge by the hour, reducing the hours on an engagement can reduce its revenue, while a fixed fee gives you a different way to keep the benefit if the result and other costs hold.

That doesn't mean every service should be sold at a fixed price. It means price belongs beside cost, retention and acquisition when you decide what the new delivery model is meant to do, rather than being treated as something to discuss after the tool is working.

You also need quality beside volume. If the team produces more but more work comes back or clients lose trust in it, that isn't the result you set out to buy.

Now, can an existing business become AI-native, or do you have to start again? I don't think an existing firm needs to throw away its clients and experience to make this change, those are part of the knowledge the new system should help it use.

Startups give us some examples of what a different setup looks like. Harper's February 2026 announcement says the insurance brokerage served more than 5,000 businesses in its first 13 months, but that is the company's own growth figure, not a benchmark for your service line.

For an existing operator, Integris' account of changing its managed-services business is also useful. It reports more than 14,000 hours saved through more than 100 automations during a 12-month change, and says it tracks savings for each automation run.

Those are reported savings from automation, not a measured claim that the entire company meets my definition of AI-native. I include the case because it shows an established provider changing repeated work and tracking it, which is something an existing firm can start doing without a clean slate.

The first move I would make is to pick one client workflow and find out where its knowledge lives. Get the person who does the work and the person who checks it together, then follow a recent job from the first conversation to the delivered result.

Write down what they had to find, what they knew without looking it up and which decisions changed along the way. Then decide what should become a shared record, who may access it and who keeps it current.

After that, you can choose a bounded part for AI to prepare and define the check before it runs. Keep the human work visible too, because the balance between producing, reviewing and repairing tells you more than a count of prompts.

The AI readiness assessment gives you a longer version of that check. You don't need to call the firm AI-native to start, you need one piece of work where the company's knowledge is available, the system can use it safely and someone can show that the result is better.

Shadow AI: The AI Your Firm Already Uses (That You've Never Seen)

Mon, 22 Jun 2026 13:00:00 GMT

Your firm can be using AI in client work even if you've never bought a tool, announced a rollout or approved a policy.

Someone can draft an email in a personal ChatGPT account, paste a spreadsheet into Gemini or ask Claude to review a contract, then bring the answer back into the work without telling you how it was made.

That is shadow AI, employees using AI tools without the employer's knowledge, approval or oversight. The risk for a service firm is that it can change the work you bill for while the people responsible for its quality don't know the process has changed.

I wouldn't assume this is happening in every seat in your company. But I also wouldn't accept “we haven't adopted AI” as proof that none of your client work is passing through it, because that answer usually describes what management approved, not everything people do.

The term comes from shadow IT, software and systems people use outside the approved setup. The concerns overlap, especially around access and client data, but AI also gives you something that can go straight into a deliverable, an analysis, a recommendation or a number that looks as though somebody checked it.

So you need to ask about the output as well as the account. Knowing which tools are installed doesn't tell you which one helped write the proposal that left on Thursday.

There is evidence that the company view and the employee view can be very different, but I want to be careful with the numbers because they measure different things.

In its May 2026 report, JPMorganChase Institute tracked payments to AI services through the end of 2025. It found adoption on that payment measure at 10.3 percent for Baby Boomer-owned businesses and 22.1 percent for Millennial-owned businesses.

That is a difference in purchasing behavior among the businesses it studied. It doesn't tell us how much free AI their employees used, whether a manager approved each use or whether the owner's age caused the difference.

And Microsoft's 2024 Work Trend Index reported that 78 percent of AI users brought their own AI tools to work. That is among people already using AI, not 78 percent of all workers, and bringing your own tool doesn't automatically mean the employer forbids it or doesn't know.

You can't subtract those figures to calculate how much AI is hidden in your firm. They come from different samples, years and questions, one measures business payments and the other asks AI-using knowledge workers about their tools.

What they give you is a reason to look beyond the tools the company paid for. My operating concern is that the official plan can move at the owner's pace while people doing the work find other ways to get help, and a subscription list won't show you all of those ways.

Some use is hidden deliberately. Employment Hero's July 2026 account of its AI Paradox survey says 42 percent of Gen Z respondents used AI without their employer's knowledge, and the same share presented AI-generated work as their own.

The study surveyed workers and business leaders across the UK, Australia, Canada and New Zealand, not the United States. So I wouldn't turn that into a claim that close to half of your youngest hires are hiding something, but it is evidence that concealment happens, even where employers say they want AI skills.

And there can be a cost to admitting it. Reif, Larrick and Soll's 2025 PNAS paper found that people described as receiving AI help were judged lazier and less competent than people receiving human help or no help.

In its hiring experiment, the manager's own AI use mattered, managers who rarely used it favored the candidate who didn't use it, while frequent users favored the AI-using candidate. These are experimental findings about judgment, not proof of what every manager in your firm thinks.

But they make it easier to understand why someone might hesitate to tell you. If using AI is praised as a company priority and treated as taking a shortcut when an employee does it, the employee has to work out which message you actually mean.

I don't think you fix that by calling the team dishonest and stopping there. You still need clear rules, but you also need to make it possible for people to tell you what they've used and what went wrong without feeling that the admission itself is the mistake.

Otherwise the same silence that hides a useful shortcut can hide a bad result. Someone who didn't tell you which tool helped with the first report may be even less willing to explain why the second report needs correcting.

I've seen five kinds of problems in unsanctioned AI output through delivery across a franchise network, and I want to stay with them for a moment because checking only for a data leak misses most of the work.

One is inconsistent style and angle across the same deliverable. Different people use different tools and instructions, and the report comes back sounding as though several separate arguments have been joined together without anyone deciding what the firm is trying to say.

That doesn't prove AI was involved, human teams can produce the same problem. But when AI is involved and there is no shared process, you need an editor who checks the whole thing, not three people who each approve their own section.

Another is a wrong fact stated confidently. A sentence can be easy to read and completely wrong, and the client has no reason to know the fact was generated rather than checked against a source.

So the check has to go back to the source, not just ask whether the sentence sounds reasonable. If the source isn't available, you haven't verified it by reading it twice.

I've also seen the numbers themselves be real while the conclusion drawn from them is wrong. That is a different review job, because checking that the spreadsheet figures were copied correctly doesn't tell you whether the analysis means what the report says it means.

Someone has to understand the business question and the comparison being made. A neat chart can carry the wrong answer just as easily as a paragraph can, and the underlying numbers being genuine can make the mistake harder to notice.

Then there are made-up statistics, numbers that don't appear in the source material at all. I've seen that happen with client financial data, so I don't treat a plausible-looking number as something we can let through because it fits the story.

I don't have a documented client outcome to add to that observation. The risk is clear enough without inventing one, if a client uses an unsupported number in a decision or repeats it elsewhere, the correction has more work to catch up with.

The fifth problem is client information going into a tool that the firm hasn't cleared for that data. Depending on what was shared and the firm's obligations, that can become a trust, security or legal problem, and checking the final report won't show you where the source material went.

A public example shows why the sharing settings matter. On July 28, 2026, the BBC reported that hundreds of Claude conversations could be found through search engines, including some with personal and work information.

Those were conversations users had chosen to share by link, not evidence that ordinary private chats were all public. The BBC also reported that search availability had been removed, while some conversations had already been saved and shared elsewhere.

That distinction doesn't make the risk disappear, it tells you which action created it. A person can think they are sending a useful link to a colleague without understanding that anyone with that link can access the content and that public web content may be copied or indexed.

So your rules need to cover what information may go in and what may be shared afterward. Approving the name of a tool isn't enough if nobody has decided which account, settings and data uses the approval covers.

And please don't aim all of this at the youngest people. Microsoft's bring-your-own figures cover AI users across generations, and older research summarized by NBER in December 2024 found work use across age groups, with lower use among older workers rather than no use.

That's historical adoption evidence, not a current age cutoff you should put into a policy. The senior person whose work gets the least checking can also use AI, so an audit based on birth year misses the person whose judgment you were relying on.

Learning isn't standing still either. Rebecca Perron's June 2026 article in ASA Generations describes a narrowing age gap in LinkedIn Learning participation.

That is a learning-participation measure, not proof that everyone has reached the same skill level. It is another reason I wouldn't wait for a generational change to solve a problem that needs a decision about work today.

The separate question of who benefits most from AI depends on the person and the task. Here, your job is to find out what is already being used and bring the work under a review process the firm can stand behind.

I would start with a conversation, before buying a monitoring product or writing a long policy. Ask what AI tools people already use, which tasks they use them for and what they find useful, and say that you want an accurate picture rather than the answer they think management wants.

You can make room for candor without approving everything you hear. If someone is putting restricted client information into an unsuitable account, that use needs to stop and the work needs a safe route, even while you thank them for telling you.

What I wouldn't do is announce a blanket ban and assume the absence of discussion means the tools disappeared. A ban without a workable alternative can make disclosure harder while leaving the deadline and the need for help unchanged.

Then take a sample of recent client work and walk through it with the people who prepared and reviewed it. Find out which parts used AI, where the source material came from and whether the result was checked against it.

Look for the mixed voice, the unsupported fact, the wrong conclusion from correct numbers and the statistic nobody can trace. Separately, check what client data entered the tool and whether any conversation, file or output was shared beyond the intended people.

Don't treat a clean-looking sample as proof there is no shadow AI. You are checking a piece of work and learning how it was made, not certifying the whole firm from one report.

For the uses you keep, name who owns review and put the data boundary and checking rule somewhere the team can find. A short AI policy can help carry those decisions, but it has to describe the work people actually do.

If nobody in the firm can judge a particular AI output, keep that part of the work manual until someone can. The first useful move this week is to ask how the last client deliverable was made, then check the answer against the work itself.

Writing | Rod Amora

The Two AI Skills I Would Put First: Imagination and Creativity

We started by asking how to prevent churn

Imagine what would solve the problem before choosing a tool

Learn enough about AI to see what you could try

You can get help turning the idea into something that works

Don't Be a Detached CEO

I didn't know where to start either

AI leadership: learn enough to join the conversation

You can explore without a company project

Try something you want to understand

A useful experiment doesn't commit your company

How I Built AI That Could Work Across My Company

Everyone was figuring it out separately

I split the problem into two layers

The next person needs the project history too

Sharing the work means deciding who gets access

We stopped teaching the company rules in every chat

Use the two layers to decide what to buy or build

The agent still doesn't manage the projects by itself

AI Can Do the Junior's Work. First, You Have to Check Everything.

At first, you check everything

The failures become the safeguards

Give each part the right kind of checker

What happens to entry-level jobs when AI takes the first pass?

Count the cost before changing the role

This does not answer the whole hiring question

We Couldn't Afford to Review 900 Applications, So We Built an AI Interviewer

We had more applications than we could handle

The $50 didn't include the build

Compare it with the work that stays waiting

Put the whole job in the budget

You Bought Automation and Installed a Guess

A clean summary can be a damaged record

Buying the tool didn't change the job

Give AI information work, not the whole responsibility

The right tool can still be doing the wrong part of the job

Start with one small piece of the work

Fix the AI step, replace the tool, or stop using it

Where this advice stops

Your AI Can Find the Record. That Doesn't Make It the Answer.

The conversation wasn't finished at the sales call

Adding a tool can add another record

Decide what supports the answer

Follow the change, or ask

Agreement still isn't proof of delivery

Start with an answer the client will use

AI prices fell up to 22x. Our bill fell 2x. Here is where the rest went.

AI token cost and the bill move on different lines

Where the tokens went

The cheaper model did not do this. The rebuild did

People told us what they wanted to read

Review time went down, not up

How much work we assign matters more now

Decide where the cut goes before it arrives

Making the same work faster is not enough

The reports were done. The manager's work wasn't.

We changed what the manager received.

Checking was part of getting there, not the final job.

The manager still had to help the person improve.

Decide what people will stop doing.

You Can Build Your Own Software Now. Buy the Cheap Tool Anyway.

The reason you bought software was never the features

What we built at Berry, and what it cost us

The rule we actually use: buy cheap first, build when nothing fits

Who owns it in three years

How to run the rule this quarter

Where this stops

Don't Pick Your First AI Pilot by Performance Alone

At Berry, I started with the people who wanted it

Strong performance doesn't guarantee a benefit

Check how the work feels and how it turns out

What to do in the first month

Where this stops

Nobody Wanted to Write the Meeting Summary

AI Enablement Is a Loop, Not a Roadmap

The four jobs inside AI enablement

Who owns the loop

Start with one piece of work

AI-Native Without Starting Over