The orders still have to ship, just like they always have. They had to ship back in the 90’s when the mainframe was finally running. When the Internet happened, they had to ship while ERP and just-in-time was implemented. They have to ship now too as we all shift to an “AI-native” business. But, what does AI-native mean and do we even really want to be that?
I think there's a useful idea inside the phrase. If AI can do some of the work, we should be willing to reconsider how that work happens. Who does what, which steps we still need, and what becomes possible that wasn't practical before. But, becoming a particular kind of company is an awfully vague objective when you're one of the people who has to make the company actually work.
I prefer to talk about “AI from here”, accepting history and embracing potential in equal measures. From here: the systems you have, the people who know how they work, and the customers who are counting on you. You can change quite a lot from there. You just need a better reason for each change than wanting to call yourself AI-native.
We've got a business to run
Alex Lieberman's characteristics of an AI-native company and Nathaniel Whittemore's discussion on The AI Daily Brief got me thinking about this. They cover useful ground, including shared context, permissions, and the idea that agents should earn more autonomy as they prove themselves. There's plenty in these takes I agree with.
The question I keep coming back around to is how an existing business decides where to start changing out parts of the engine while the wheels continue to spin. A list of things we could become doesn't quite answer what we should change first, or how much of the company needs to grow/shrink/evolve along with it.
Think about the systems you run today. Some were probably chosen because they were the best option available, some came with an acquisition, a few probably as a reaction to a failure or risk, and some are still there because replacing them would interrupt work that matters more than replacement. The people keeping all that working have, over time, made some sensible compromises. Start by understanding those compromises before deciding which ones AI makes unnecessary.
Then find a piece of work worth improving. Something that takes too long, gets done inconsistently, or depends on somebody remembering a detail that nobody else knows. Give that problem a name and understand its shape before assigning an agent to execute it.
What do we actually want it to do?
Imagine a company that sells and ships physical products. When an order gets stuck, somebody has to find out why and decide what to do about it. That might be a customer service person, an operations team, or, in some companies, a team called the order desk. They're the people sorting out a price that doesn't match, figuring out what to do about an unavailable item, or handling instructions from a customer that the warehouse hasn't received.
Let's give this hypothetical team a problem. A customer has ordered several items, only some are in stock, and they've asked for everything to arrive together. The person handling the order needs to check the inventory, find the customer's instructions, and work out whether to hold the shipment or ask the customer about sending part of it now. The information might be spread across the order system, warehouse records, and an email.
There is indeed a reasonable job for AI in there. The question is how much of that job we want to hand over. Let’s consider proposals for two possible agents we might assign to the problem.
Order Researcher gathers the information and explains what's holding up the order. In this case, it brings together the stock information and the customer's request to receive everything at once, with links back to the records. A person checks that information, decides what to do, and makes any changes. Order Researcher can't change an order or contact the customer; its job is to save the person from having to go looking for context.
Order Resolver gets permission to act on what it finds, within rules the company has agreed on. For this order, it could put the shipment on hold so the warehouse doesn't send an incomplete delivery. For an order where the customer allows separate deliveries, it might split the shipment instead. Cases outside its authority still go to a person, but for the cases it can handle, Order Resolver changes the actual order record.
We might put both proposals under the title "AI for order management," but we've asked for very different things. With Order Researcher, a person still makes a decision on what happens to the shipment. With Order Resolver, the warehouse could start acting on a change before a person has looked at it. Being ready to use Order Researcher doesn't establish that we're ready to hand that authority to Order Resolver.
And, Order Researcher still needs to be accurate. If it misses the customer's request or presents yesterday's inventory as what's available now, the person relying on it could make a bad decision. Read-only access doesn't stop an answer from influencing what someone does. We can't delete the research and expect the shipment to come back as a mulligan.
I'd start this hypothetical pilot with Order Researcher. Give it access to the information it needs, require it to show its sources and flag what it couldn't establish, and keep the decisions with the team. Then find out whether the time it saves gathering information is worth the work of checking it. Order Resolver remains a separate proposal, with more to prove before we let it touch an order.
Starting small still means doing the work
I once heard in a meeting “Let's just pilot the damn thing” after the CEO became fatigued with a solutioning session he had joined. His statement can mean quite a few things, first and foremost: “I’m bored.” But I'd want it to mean: we know what we're trying to improve and have agreed on how we'll tell whether it's working. Otherwise we might finish with a convincing demonstration and still have the same order backlog.
Write down the decisions together before the team starts building.
- What should improve? Name the error, delay, or effort you want to reduce; and the output you want to encourage. Compare AI with a report, ordinary automation, or a change in the process.
- What can the agent do? Say what it can read, recommend, or change, who receives the result, and who's responsible. Give it access that enforces those limits.
- What does that job need? Find the data, definitions, permissions, and people it depends on. Be able to explain why each proposed repair belongs in this pilot.
- How will we check it? Agree on acceptable results, ordinary and difficult cases to test, the review people still do, and what happens when it fails.
- Is it worth continuing? Use the results to proceed, narrow the work, fix a dependency, or stop. Include the effort of checking and correcting it.
- When do we reconsider? A new action, changed data, a model change, or an incident can make the earlier decision worth revisiting.
For Order Researcher, look at the information it assembled before someone corrected it. In our example, did it find the customer's request to receive everything together? Did it accurately report which items were available and how current those stock figures were? Count how long the team spent checking the answer and whether they reached a useful decision sooner. Producing a summary more rapidly doesn't help much if the person has to repeat the research to trust it.
Then try other orders, including partial shipments, cancellations, and records that disagree. Include cases the team hasn't already used to improve Order Researcher. A quiet week can tell us something, but it probably doesn't tell us enough about the orders that take the most work to resolve.
Suppose the customer records don't match across systems. We might still be able to use Order Researcher for orders whose information is complete and tied to a reliable order number. That narrower scope needs testing as well, including whether Order Researcher recognizes when the necessary context is missing. If it can't tell that the customer's delivery instructions belong to this order, it needs to hand the case back rather than present an incomplete account as the whole story. If it can't reliably recognize those gaps, we have a dependency to fix before that use can proceed.
If we later want to build Order Resolver, the test changes. Finding the customer's instructions is only part of the job now. Can it put this shipment on hold before the warehouse starts packing it? Does that hold reach every system that needs to know? If an attempted update fails and it tries again, could it make the same change more than once? Who fixes the consequences of a mistake?
Those questions belong to Order Resolver's authority to change orders. A successful Order Researcher pilot gives us useful evidence about gathering information, but it doesn't answer them. We can keep using Order Researcher while we decide whether the additional work and responsibility of Order Resolver are worth taking on.
Some things should change
Keeping the ERP doesn't mean keeping every spreadsheet people built around it. If Order Researcher does the useful work of assembling the information, perhaps that morning export and the copy-and-paste routine can go. The person still decides how to handle the stuck order, but the way they get to that decision changes.
Ask them what the old steps were doing before removing them. What looks redundant from outside the work may be how someone catches a problem the system doesn't show. That's knowledge we need in the new process, even if we no longer need the old step.
There are also repairs we won't be able to avoid. If Order Researcher can't connect orders to the customer information it needs, and narrowing its scope leaves too little useful work, somebody has to fund that repair or choose a different starting point. "AI from here" doesn't promise that we can build around every limitation. It gives us a way to decide which limitation is worth addressing now.
Our Integration and Data Maturity Index can help you look at the broader condition of your systems and data. The decision about this particular workflow still comes from understanding and testing this particular work.
So, do we want to become AI-native? I want us to become better at the work our businesses exist to do, and AI is giving us more ways to do that. Some changes may be substantial. Others might leave most of the business looking familiar, with less time spent chasing information and more time doing something useful with it.