AI-Native Without Starting Over

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.