AI Did Not Change What Your Operation Is

The question arrives in every engagement now, usually early and usually in the same shape. What should we be doing with AI. Which tools. Where do we start. Are we behind.

The industry has an answer ready, and it is the same answer it has for everything: adopt, or get left behind. Every vendor deck, every conference panel, every piece of trade counsel points the same direction, and the direction is acquisition. Buy the scheduling engine, the forecasting model, the voice ordering system, the review responder, the pricing tool, the menu description generator. Adoption is the metric. Being early is the strategy.

I am going to tell you something less exciting and more useful. AI did not change what your operation is. It changed how fast your operation becomes more of what it already was.

That is not a hedge and it is not caution about technology. I think this is the most powerful instrument that has ever been available to an independent operator. It is a statement about mechanism, and the mechanism has a direction problem that nobody selling you anything has an incentive to mention.

Why Amplifier Is Not A Soft Word

The word amplifier sounds like a way of avoiding a position, so test it the way you would test any other claim: does it send you somewhere different to work.

If AI is a transformation, the work is selection. Which tools, which vendor, which order, how fast, what budget. That work is real and it is all downstream of a decision nobody made.

If AI is an amplifier, the work is upstream. What is this operation built to produce, is that architecture coherent, and what happens when you multiply it. Because a multiplier does not have an opinion about the sign of what it multiplies. Point it at a coherent operation and you compound. Point it at an incoherent one and you industrialize the incoherence, on schedule, across every station, with better reporting.

Same technology, two different addresses for the work, and only one of them can tell you whether a purchase is a good idea.

That is why I will not answer a tool question until the architecture question is answered, and why the AI conversation in my engagements happens after the architectural read rather than as its own project.

Coherence Is The Multiplier’s Coefficient

Here is the mechanism, stated as plainly as I can put it.

Your operation already has an architecture, whether you designed it or inherited it. It has a contract form it runs with Guests, a reward structure that pays your cast, a composition discipline on the food side, and a read discipline that produces your decisions. Those layers either agree with each other or they do not.

When they agree, the operation is coherent, and a coherent architecture amplified produces more of one thing. Faster, at scale, in the same direction. That is compounding, and it is the whole case for the technology.

When they do not agree, amplification does something different and worse than nothing. It accelerates each layer independently, which widens the gaps between them. The forecasting model makes your labor plan sharper against a throughput target while your Guest contract still promises a relationship. The review responder answers faster in warmer language than your cast has the authority to deliver. The pricing engine optimizes a number your operation cannot justify at the table. Every individual system improves and the seams tear, because the seams were the thing holding an already-mismatched set of layers together, and they were being held by human beings absorbing the difference.

This is why so many rollouts produce a measurably better process and no change in the outcome. Nothing failed. The tool did its job at the layer it was installed on, and the operation was never governed at that layer.

That is why I read the seams between your layers before I will look at a stack, and why I have told operators to postpone a purchase that was obviously going to work.

A Layer On Top Is Not A Redesign

The most common form of this is an operation that has bought a great deal and changed nothing.

Tools get acquired. Pilots run. Adoption climbs. Speed improves. Somebody produces a number for the board or the partners. And underneath all of it, the workflows are the workflows, the incentives are the incentives, the decisions get made by the same people using the same read against the same assumptions. AI has been installed above the operation rather than inside it, which is a superstructure, and a superstructure is not architecture no matter how much of it there is.

The reason it is so hard to see from inside is that every available metric measures acquisition. How many tools, how many users, how many hours saved, how many tasks automated. Not one of those tells you whether a single governing decision in the operation now happens differently. Adoption is a measurement of purchase, and purchase is the easiest thing in this business to mistake for progress.

Ask for the evidence in the other form and it gets clarifying fast. Name three decisions that now get made differently than they were a year ago, and say what changed about them. Name one thing you decided not to automate, and why. Name one Guest-facing outcome that was redesigned because AI is inside the operating system rather than sitting above it. If those three answers do not exist, there is no integration to discuss, regardless of how much is installed.

That is why my first AI question in an engagement is about decisions rather than tools, and why I ask what you refused before I ask what you bought.

Refusal Is The Only Reliable Evidence

That middle question deserves its own beat, because it is the one that separates a designed operation from a busy one.

Everything AI can do, it will do on request. Which means an operator who has designed nothing will automate whatever is easiest to automate, and what is easiest to automate is almost always the human contact that was producing the value. Answering the phone. Greeting. Following up after a bad visit. Writing the note. Handling the complaint. Every one of those is a cost center on a transactional read and the actual product on a relational one.

So an architecture reveals itself in what it will not hand over. If you cannot name the work your operation refuses to automate, you do not have an architecture governing your technology, you have a budget. And the refusal has to be specific and current: this task, this touchpoint, this decision, and here is why the operation eats the cost of keeping a person in it.

The operators who get this right are usually surprised at how few refusals they need. It is not a long list. It is the two or three moments where the relationship is actually made, protected on purpose, while everything around them gets faster.

That is why I ask every operator I work with to write their refusal list before their purchase list, and why an engagement that cannot produce one is not ready for a tool conversation.

Enhance The Experience Or Supplant It

That refusal list gets misread as a rule about proximity, and it is not. There is a role for every piece of this technology, and the condition on all of it is one I have been writing and saying for years, long before any of this arrived: technology enhances the experience, or it supplants it. Those are the only two things it can do.

My own test on this has never changed, and it is one question. Does this tool make the cast more capable of genuine human connection, or does it replace the need for that connection. If it makes them more capable, it enhances. If it replaces the need, it supplants. That is the line, and it holds for a reservation platform, a scheduling engine, a phone system, and every model released since.

Notice what the question is not asking. It is not asking how close the tool sits to the Guest. A system that routes a Guest’s history to the lead before they sit down is closer to the Guest than any back-office tool and it enhances, because a person is still doing the thing and now they know something they could not have known. A system that answers a complaint on your behalf in language nobody in the building authorized is equally close, and it has taken ownership of the relationship. Once the technology owns the relationship, the loop breaks.

Build the whole stack on that condition and almost nothing is off the table. Violate it once at the moment where the relationship was actually being made and you have automated away the reason the Guest chose you, efficiently, and the number will look fine for two quarters.

That is why the boundary I hold in an engagement is supplanting rather than proximity, and why I will argue for a tool that sits inside the Guest’s path and refuse one that sits in a person’s place.

The Same Line Runs Differently On CX Than On GX

Where I have sharpened the position is here, because the condition has to be read against the register you are running. Supplanting means two different things depending on which one it is, and that part I stated too narrowly for years by writing it only against the GX.

On the eating side you are producing a fulfillment outcome. The Customer wants the transaction to be accurate, fast, and low-friction, and the technology is allowed to be the interaction. A kiosk, an app, a voice system taking the order, automated confirmation, a self-managed pickup — executed well, those improve the CX rather than degrading it, because the thing the Customer came for is the transaction itself and a person in the middle of it is often just latency. Demanding relational warmth in a fulfillment event makes a coherent operation look broken.

On the dining side you are producing an experience whose product is the relationship. The same tools, at the same touchpoints, supplant the GX. Not because they perform worse, but because the interaction was the product, and a competent machine performing it has delivered everything except the only thing that mattered.

So the same purchase is correct on one register and disqualifying on the other, which is why the register has to be declared before the tool gets evaluated. Most operations run both, at different dayparts and through different channels, and the failure is almost always a tool bought for one register and deployed across both.

That is why I make you name the register a tool is being installed on before I read the purchase, and why the honest answer in a mixed operation is that some parts of your stack should stop at the door of the dining room.

The Tools Are Converging Your Operations

The strategic problem is one nobody in the vendor economy will raise with you, and it is the biggest one on this page.

You and every operator in your band are being sold the same instruments by the same vendors, trained on the same data, producing the same recommendations, installed over architectures that were mostly inherited from the same default. Run that forward. If everyone applies the same amplifier to the same underlying architecture, the outputs converge. Your menu descriptions read like theirs. Your pricing moves like theirs. Your review responses sound like theirs. Your promotional calendar rhymes with theirs.

Which means the technology being sold as differentiation is a convergence engine, and it is most powerful exactly where the operator has designed the least. The tool cannot supply differentiation the architecture does not have. It can only reproduce, faster and at lower cost, whatever the operation already was, and if the operation was the industry default then that is what gets reproduced.

The bitter part is where this lands hardest. The independent’s structural advantage over scale has always been the things scale cannot do: a cast with real authority, Guests who are actually known, decisions made by someone in the building. Those are the exact functions the tool layer is most eager to standardize, and an independent who automates them has traded away the only advantage that was never available to the chain.

That is why I treat every AI decision as a positioning decision rather than an operations decision, and why the question I ask is what this makes you less like, not what it makes you faster at.

Ask A Model For Strategy And You Get The Industry’s Median

There is a second-order problem specific to using these systems for thinking rather than for tasks, and it is worth naming because it is invisible.

These models were trained on what has been written about this business. What has been written about this business is overwhelmingly the transactional consensus: the benchmark tables, the cost-percentage orthodoxy, the promotional playbooks, the best-practice counsel, the vendor content, the trade advice. So when you ask a model what to do about a soft Tuesday, it gives you an excellent synthesis of the industry’s median answer, which is the answer that is producing the industry’s median outcome.

It is not wrong. It is representative, and representative is the problem. The median answer in a business with this failure rate is not a good target. You are getting the consensus of a field whose consensus has not worked, delivered with more fluency and confidence than any individual member of that field could manage, which makes it considerably more persuasive than it should be.

That does not make the instrument useless for thinking. It makes it useless as an oracle and excellent as an adversary. Give it your architecture, your reasoning, your decision, and ask it to attack the position. Ask what your read is missing, what a Guest would say that you have not accounted for, what your reward structure is actually paying for. Used that way it is the best devil’s advocate an independent operator has ever had access to, because it will produce the objection your own dominant lens cannot generate.

That is why I install it as an adversary in the operator’s read discipline rather than as an advisor, and why I will not hand you a prompt that produces a plan.

What It Is Actually Best At Is The Third You Own

Now the constructive part, because none of the above is an argument for staying out.

The operator’s job runs in three parts. Two thirds is the production, front and back of house as one system during open hours, where hospitality gets produced and service gets executed. One third is admin: the financials, the schedule, the vendor management, the mix analysis, the labor model, the daypart strategy. Above all three sits the read that integrates the signals into decisions.

The admin third is where this technology earns its keep, and it is not a small prize. That third is where operators lose their evenings, where the work gets deferred until it is urgent, and where a small operation is structurally outgunned by a chain with a department for each function. Compress it and you have not just saved time. You have bought back the operator’s attention, which is the scarcest input in an independent operation and the one every good outcome depends on.

The same logic runs on the cast. Every minute of administrative load you take off a cast member is a minute available to produce hospitality, and that is the version of this technology I will argue for aggressively. Not AI standing in a person’s place. AI clearing the path and loading the person in it so they can do the part only a person can do.

And the read stays yours. Not as a sentiment about human judgment, but because whoever holds the read holds the architecture, and a read you have outsourced to a model trained on the industry’s median is an architecture you have handed to the median.

That is why I scope AI work to the admin third and the cast’s load first, and why I will build you anything that makes your people better in the moment and nothing that stands in for them in it.

The Diagnostic

Run these before the next purchase. Each has a specific move and a plain read.

Test one — the three-decisions test. Name three governing decisions that now get made differently than a year ago, and what changed about each. Fewer than three and you have a superstructure, not an integration, whatever the invoice says.

Test two — the refusal test. Name the work your operation will not automate and why, specifically. If the list is empty, your technology is being governed by availability rather than by design.

Test three — the coherence test. Name what your Guest contract promises and what your reward structure pays your cast for. If those point in different directions, every tool you add widens the gap, and you should be fixing the seam rather than buying.

Test four — the convergence test. Take your last four AI-produced outputs — a menu description, a review response, a promotional message, a social post — and ask whether any operator in your band could have produced the same thing. If yes, you paid to sound like everyone else.

Test five — the direction test. For each tool you run, ask whether it makes the operation better at accumulating transactions or better at building capability. Both are legitimate answers. Not knowing is not.

Test six — the supplant test. List everything the technology has taken off a person’s hands, then mark each one support or supplant, and mark the register it runs on. A supplant on the eating side is usually fine. A supplant on the dining side is a trade you made without pricing it.

Test seven — the adversary test. The last time you used a model on a real decision, did you ask it what to do or ask it to attack your reasoning. The first is consensus. The second is a read.

How the score sorts. Fail one or two and you have a scoping problem with a clear repair. Fail four or more and the stack is amplifying an architecture nobody designed, and the fix is upstream of every tool in it. Pass all seven and you are doing something almost nobody in this industry is doing, and you should expect your numbers to look strange against the benchmarks for a while.

What You Do Monday Morning

Take one decision you make every week. The schedule, the order, the promotion, the daypart call.

Write down the last three times you made it, what information you used, and what you decided. Then, next to each, write what a tool would have needed to know to make that call the way you made it. Not the data it would have pulled — the judgment. The thing about that cast member’s week, that Guest cohort, that vendor’s reliability, that neighborhood’s month.

Then sort the three into two piles: the ones where your list is short, and the ones where it is long.

The short-list decisions are your automation candidates, and you should move on them fast because they are costing you attention you need elsewhere. The long-list decisions are the architecture, and every one of them you hand over is a piece of the operation you no longer govern. That sort takes an hour, costs nothing, and it is a better technology plan than any deck you will be shown this year.

The Closer

The technology is real and it is the most useful instrument the independent operator has ever been handed. Nothing on this page argues otherwise.

But it is a multiplier, and a multiplier is an answer to a question you have to ask first. What is this operation built to produce. Answer that and the tool decisions get easy, most of them get small, and a few of them get very valuable. Skip it and you will spend real money making your operation more efficiently into the thing it already was.

AI did not change what your operation is. You are still the only one who can do that.

Digging Deeper

Every term used above is defined in my Knowledge Base: https://kb.jeffreysummers.com/

Terms used: AI As Amplifier, Superficial AI Superstructure, Integrated AI Architecture, Architectural Coherence, Two Roads, By Design Or By Default, Restaurant Architecture, Reward Structure Architecture, The Operator’s Read, The Production, Admin, Positioning Capital, Independent Advantage

The architecture taught in full, fundamental by fundamental: https://physics.jeffreysummers.com/

The Road 1 arbitrage prosecuted where it lives in the wild: https://hacksterism.jeffreysummers.com/