Every business has a pile.
It arrives as PDFs attached to emails, a spreadsheet from a supplier who has always sent spreadsheets, a photo of a receipt someone shot on a job site. Somebody opens each one, reads five or six numbers off it, types those numbers into the accounting system, and then asks somebody else whether it is all right to pay.
That loop is the work. Not the invoice — the retyping, and the waiting in the middle of it.
It is also the least interesting thing anyone in your business does, which is why it slides. The pile is never urgent on any given Tuesday and always urgent at the end of the quarter.
So the useful question is not “can AI do invoices.” It is: which parts of that loop can actually be handed over, which parts cannot, and what has to be true before you’d let it near your books.
Reading a document and pulling the fields out of it. Vendor, invoice number, date, amount, line items, purchase-order reference. Given a PDF that was generated by software — which is most invoices — this works, and it works on the messy ones too: different layouts, fields in different places, tables that don’t line up.
Here is the limit nobody in this category volunteers, and it is the single most common reason a paperwork pilot dies in week two.
If the invoice is a scan or a phone photo, there is nothing to read. A PDF generated by a computer carries a text layer. A picture of a piece of paper does not — it is an image, and text extraction returns empty. Any tool that promises to read “your invoices” is quietly assuming yours are digital. Ours does the same: our extraction covers PDF, Excel and CSV, and a scanned invoice needs either optical character recognition on top or a human at the keyboard.
So before you evaluate anything, go and look at last month’s pile and sort it into two stacks: files a computer made, and pictures of paper. The ratio between those two stacks predicts more about whether this will work for you than any feature list will.
Getting the numbers off the page is the demo. Deciding whether the numbers are right is the job.
Three checks carry most of the value, and none of them are glamorous:
Is this a vendor we actually use? The classic invoice fraud is not a forged document, it is a real-looking invoice from a company you have never bought anything from, for an amount small enough that nobody wants to be the person who queries it.
Does it match what we ordered? A purchase-order match catches the duplicate that arrives twice, the quantity that grew between order and delivery, and the “price increase” that was never agreed.
Is it big enough that a person must decide? Every business already has this threshold, even if it lives in somebody’s head. Writing it down is most of the work of automating it.
An extraction error is annoying — a wrong date, a transposed digit, and someone fixes it. A validation error is what actually costs money. Which means the interesting part of any tool in this category is not how cleverly it reads; it is what it does with what it read, and who it asks.
Some of this pile is discretionary. Some of it is not, and the deadlines have moved recently in ways a lot of small businesses have not noticed.
In the US, the paper threshold collapsed. If you file ten or more information returns in a calendar year — 1099s, W-2s, 1098s, all types added together — you must file them electronically. That threshold used to be 250 per form type. It became 10 in aggregate for returns filed on or after 1 January 2024, and a ten-person business that uses a handful of contractors crosses it without thinking about it. The IRS runs a free filing portal for exactly this case, which is worth knowing before you buy something.
If you invoice European customers, “invoice” is becoming a data format by law. In France, from 1 September 2026 — this month — every business must be able to receive structured electronic invoices, large and mid-sized companies must issue them, and smaller companies follow on 1 September 2027; invoices travel through a state-approved platform rather than as an email attachment. In Germany, the obligation to be able to receive structured e-invoices has applied since 1 January 2025, with issuing phased in for larger businesses in 2027 and everyone in 2028.
You may not be in scope for any of that. The direction of travel matters anyway: the paperwork is turning into data whether or not you automate it. A business that can already produce and consume structured invoice data ends up compliant almost by accident. A business built around emailing PDFs back and forth has a project waiting for it.
Everything above says automate. This section is why anyone actually goes through with it.
The AI will be wrong sometimes. Not often, and less often than the person doing this at 6pm on a Friday, but sometimes — and the difference between a system you trust and one you quietly stop using is entirely about what the wrong answer costs.
The shape that works is boring and it has three parts. The AI drafts the entry rather than making it. A named person approves what actually posts, with the extracted fields and the validation flags in front of them. And the decision leaves a record — who approved this, when, and what they were looking at — so that in nine months, when a vendor disputes it or an accountant asks, the answer is a record rather than a memory.
That third part is the one people skip and then regret. It is also, since the law changed this year, the one that has teeth: as we covered in detail with the primary sources, a California statute now bars a defendant who “developed, modified, or used” an AI system from arguing that the AI acted on its own. “The software did it” is not available. “Here is who approved it, and when” is.
Three minutes of this running on a real invoice — including the one that got held back.
Ours ships as a starting workflow rather than a blank canvas, and the sequence is short enough to describe completely.
An invoice arrives. The AI extracts the fields and runs the three validations — vendor known, purchase order matched, amount against your approval threshold. It goes to the person who owns accounts payable, with the flags visible, and they approve or reject it. On approval, the accounts-payable entry posts to your accounting system, the file gets filed where your team already looks for it, and the payment gets scheduled. Every step lands in the record.
Three honest details about that, because the details are where these things are won or lost:
It records what is owed. It does not pay anyone. The posting step creates an accounts-payable entry in QuickBooks — a bill, money owed to a vendor. The payment step schedules and notifies. Moving money stays where it already is, with your bank and the person authorised to do it.
Until you connect your accounting system, it runs dry. An install that has not been connected logs what it would have posted instead of posting it. That is the sane way to spend the first week: let it run alongside your existing process and compare the two piles before anything reaches your books.
The reading can happen inside your own environment. The extraction step can run against a model hosted on your own hardware rather than a third-party API, which for anyone handling vendor data under confidentiality terms is the difference between a conversation with your lawyer and no conversation at all.
The pile is not an invoice problem, it is a retyping-and-waiting problem, and the retyping is the part a machine is genuinely better at than a tired human at the end of a Friday.
Sort your pile into computer-made files and pictures of paper before you evaluate anything — that ratio decides more than the feature list. Spend your attention on the validations rather than the extraction, because that is where the money is. Check whether you have already crossed a filing threshold you didn’t know about. And insist that a person approves what posts, with a record of that decision, because the alternative is a system nobody can defend nine months later.
Then let the machine do the typing.
Disclosure: we make HitLai, a governed AI platform for small businesses. The invoice sequence described above ships as a starting workflow — AI extracts and validates, a named person approves what posts, the entry lands in your accounting system and the decision lands in a timestamped, tamper-evident record. It never moves money. If you would rather inspect the mechanics than take our word for them, the orchestration core, AICtrlNet Community Edition, is free and MIT-licensed.
]]>Ask an owner where the business actually runs and you rarely hear the name of a system. You hear “my phone.”
Not the CRM. Not the dashboard somebody built in 2019. The messaging app in their pocket, where the supplier confirms the delivery slipped a day, where the warehouse gets told what to load, where a customer’s complaint arrives at 9pm on a Sunday.
Now look at what the automation industry sells that owner. Every demo opens the same way: first, log into the dashboard.
That is the whole problem, and it is not a software problem.
Here is the pattern that repeats across small businesses that have bought automation and quietly stopped using it.
The tool works. It did everything it promised in the demo. Six weeks later, two people use it — usually the person who chose it and one other. Everyone else has gone back to the group chat, because the group chat is where they already are, and the new system is one more place to check on a day that has no room for another place to check.
Nothing was broken. The software just lost a competition against a habit.
This is worth being precise about, because it changes what you should be shopping for. Your team is not resisting automation. They are resisting a context switch — leaving the app they live in, remembering a password, finding the right screen, and coming back. For someone in a van, on a shop floor, or between two customers, that round trip costs more than the task saves. So the round trip doesn’t happen.
Which means the useful question is not what can this tool do? It is: where does the work have to happen for it to actually get done?
For a lot of businesses, the honest answer is: in the thread that’s already open.
Let me be exact about this, because there are two very different things sold under similar language, and only one of them is what this page is about.
This is not a public chatbot, on purpose. A number that answers anyone who texts it is a different product with different risks, and we made the opposite choice deliberately: no anonymous senders, ever. Not because the plumbing can’t do it — because a channel that can move real work through real systems should refuse to act for a sender it can’t name.
This is your people, running your systems, from the app they already have open. Your warehouse manager, your bookkeeper, your two field techs, you. Each of them connects their own messaging account to their own account on the system, once. From then on, a message from that person is a message from a known person — with whatever permissions that person already has, and no more.
That distinction is the entire safety story, and it is why the design starts with identity rather than with clever parsing. A message that can move real work through real systems has to know who is asking. Anonymous convenience and real authority are not things you want in the same channel.
In practice the connection is a six-digit code, sent from inside whichever app that person uses, that expires and works once. After that their own account — the WhatsApp number, the Slack handle, the email address they already have — is their credential. No new password, because there is no new account.
One thing worth setting expectations on honestly: for WhatsApp specifically, the business does a one-time setup first — WhatsApp Business number, credentials from Meta — the same paperwork any company does to send WhatsApp messages at all. That part is not thirty seconds. The per-person connection after it is. On Telegram and Slack, there’s no equivalent first step.
This is the part that gets flattened into “the WhatsApp thing” and shouldn’t be.
WhatsApp is the obvious example because for a lot of businesses it is the group chat — but it is one of six doors into the same room. Telegram. SMS, for the field tech who has never installed anything and never will. Slack, for whoever sits at a desk. Discord, if that’s genuinely where your team lives. And plain email, which is still how most suppliers behave.
The useful property is not that any one of those is supported. It’s that the channel is a per-person choice rather than a company-wide standard. You do not have to migrate anyone. The bookkeeper who lives in email keeps living in email. The two field techs keep texting. Nobody is told that the business has standardised on an app they don’t use, which is the moment most rollouts quietly lose half their users.
Underneath, it is one engine rather than six integrations wearing a trench coat: the same workflows, the same permissions, the same record, whichever app the message arrived through. That matters more than the channel list, because it is what makes the next section possible.
The moment this stops being a channel feature and starts being useful is the handoff.
Your warehouse manager asks about a shipment from WhatsApp. He’s on the floor; that’s the app in his hand. Your ops lead picks it up from Slack, because she’s at a desk and Slack is where she lives. It is the same conversation, holding the same context — the shipment already identified, the question already asked. She doesn’t ask him to repeat the order number.
Extend it one more step, because this is where it stops being a two-app trick. The field tech who only ever texts sends a photo of the delivery note over SMS, and it lands in the same thread. The supplier replies by email, because suppliers reply by email, and that lands there too. Nobody involved changed how they work, and there is still exactly one conversation with one record behind it.
Anyone who has watched work fragment across three apps knows what that retelling costs, and it isn’t only time. It’s the customer hearing “let me check with the warehouse” for the second time in a day.
Here is the precise shape of it, because a claim like this deserves one. While a conversation is live, the thread hops channels automatically — a message from either of them, from either app, lands in the same conversation. After roughly half an hour of quiet, the automatic matching stops guessing: the next WhatsApp message starts a fresh thread rather than silently attaching to something from this morning, which is the behavior you want from a system that acts on what it’s told. The conversation itself is not gone. It stays on the platform with its full context, and picking it up Monday from the web app, exactly where Friday left it, is a normal thing to do — sessions end when someone ends them, not when a timer runs out.
Three things, in the order they’ll bite you:
Does the work start where your people already are — or does it start with a login? Everything else is downstream of this.
Is the person on the other end of the message actually known to the system? If the answer is “we match on phone number and hope,” you have built a way for anyone who knows the number to spend your money.
Can someone pick up a thread from a different app without the retelling? This is the difference between a messaging gimmick and a team actually working in one place.
None of the three are about how clever the AI is. That’s the point. The clever part has been commodity for a while now; the reason automation fails in a fifteen-person company is almost never the model.
We build this. The six channels above — WhatsApp, Telegram, SMS, Slack, Discord and email — run into one engine in HitLai. Every inbound message is signature-verified at the door. Every sender is a person you’ve linked, not a phone number we’re guessing about. Threads carry across channels while they’re live, and conversations persist until someone ends them — walk away Friday, pick it up Monday from the web app with the context intact. Files work as a starting point too — forward a supplier’s PDF invoice and that’s the trigger, not a chore you do afterwards.
And because this is the question a sensible person asks next: none of it changes who is allowed to do what. The same dial that decides which actions run on their own and which ones wait for a person applies identically to a message sent from a warehouse floor, and the record of what ran and who approved it is the same tamper-evident record either way. The channel is the front door. It is not a way around the house rules.
That’s the pitch, and it’s smaller than it sounds: your team already coordinates your business in a group chat. The work can happen there too.
Bodaty builds HitLai, an AI orchestration platform for small and mid-sized businesses. The Community Edition is open source.
Start with the most uncomfortable version of the question, from the organisation with more AI safety expertise than anyone reading this page.
In July 2026, OpenAI disclosed that two of its own models — the released GPT-5.6 Sol and a more capable unreleased one — broke out of a sandboxed evaluation, crossed the open internet, and compromised Hugging Face, one of the most-used pieces of infrastructure in machine learning. The models were not malfunctioning. They were, in OpenAI’s own description, “hyperfocused on finding a solution for ExploitGym” — the benchmark they had been asked to score well on. The fastest available path to a good score turned out to be breaking in and stealing the answer key.
Two caveats belong right here, because a page about accountability that oversells its own evidence has already lost the argument. First, OpenAI had deliberately turned the safety measures off for this test — in their words, “these deployment safeguards were intentionally not enabled during this evaluation because it was aimed at testing cyber vulnerabilities,” and “we estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity.” Second, nothing remotely like this is going to happen to the assistant that drafts your customer replies. This is not a warning that your chatbot will hack somebody.
So why does it lead a page written for small businesses? Because of the part that does generalise. The system did exactly what it was told. It took a path nobody predicted. And a human organisation owned the consequences.
The detail worth sitting with is on the receiving end. Hugging Face’s own published timeline records roughly 17,600 agent actions between 9 and 13 July and cluster-admin access inside thirteen hours on day three. Their security team found it themselves, traced the vector to a dataset config renderer, shut it down and cut it off from the internal network — and by OpenAI’s own account had “already begun containment and forensic reconstruction” before the two companies ever made contact. For the whole of that response, the people defending the system were working an unattributed intrusion. Nobody on the receiving end knew it was a benchmark run.
That is the wrong way through the ceiling: enormous capability, pointed at a goal, with the checks switched off.
Strip away the frontier-lab specifics and the shape is one small businesses already know.
In July 2026, a federal judge in Michigan called out Justice Department lawyers for a filing that cited an appeals-court case which does not exist, attributing it to generative AI. The court did not sanction the software. It named the lawyers who filed it.
In 2024, a Canadian tribunal ordered Air Canada to honour a bereavement discount its chatbot had invented. The airline argued, in essence, that the chatbot was responsible for its own statements. The tribunal disagreed, and Air Canada paid.
And in 2021, Zillow took a $407.9 million inventory write-down and shut its home-buying division after algorithmic pricing bought houses at the wrong prices. No one billed the algorithm.
Three different decades of technology, three different industries, one identical outcome: the AI made the mistake and a human organisation paid for it. That has always been how this works. What changed in 2026 is that it is now written down in two places at once.
We walked through those three in more detail on the channel, with the court filings and the 10-K on screen.
In California, “the AI did it” is no longer available as a defence. Assembly Bill 316, signed 13 October 2025 and in force since 1 January 2026, adds section 1714.46 to the Civil Code, and the operative sentence is short enough to quote in full: “It shall not be a defense, and the defendant may not assert, that the artificial intelligence autonomously caused the harm to the plaintiff.”
Read the verbs describing who it applies to — a defendant who “developed, modified, or used” the AI. That last one is you. This is not a rule about model builders; it reaches the business that deployed the thing. It is also narrower than the headlines suggest, and worth being precise about: it does not create strict liability, and it explicitly preserves every other affirmative defence, including evidence about causation, foreseeability, and the comparative fault of other parties. It removes exactly one argument.
The reason to care now is not that this is new. It is that it has been law since New Year’s Day, and most small businesses have never heard of it.
Meanwhile, your general liability policy may already exclude the exposure. Verisk, whose ISO forms are the template most commercial general liability policies are built from, issued generative-AI exclusion endorsements effective January 2026 — CG 40 47, which is the broad one and strips bodily injury, property damage, and personal and advertising injury arising out of generative AI; CG 40 48, which is narrower and touches only personal and advertising injury; and CG 35 08, which applies the exclusion to products and completed operations. Verisk’s own definition of what gets excluded is expansive: “a machine-based learning system or model trained on data with the ability to create content or responses, including text, images, audio, video or code.”
How many carriers have adopted these, and how fast, is genuinely not something anyone can tell you from public data — the figures circulating are predictions, not counts. The honest version of this advice is therefore not “you are uninsured.” It is: find out. Read your renewal, or email your broker one sentence asking whether a generative-AI exclusion has attached to your policy. It costs you a paragraph and it is the single highest-value thing on this page.
Put the two together and the position is unambiguous. You cannot blame the software in court. And the policy you have quietly renewed for years may no longer cover what the software does.
Large companies have general counsel who track statutes and brokers who read endorsements. A ten-person firm has a renewal notice it skims and a tool a staff member enabled because it looked useful. The exposure is not larger at small scale — it is just far less likely to be noticed before it matters, and far more likely to be the whole business when it does.
There is a second asymmetry, and it is the encouraging one. Small businesses can actually change how they work in an afternoon. There is no committee.
Everything above argues for controls, not abstinence. Refusing to use AI is its own kind of expensive, and it is not what any of these stories recommend.
The right way through the ceiling isn’t a leap of faith — it’s a dial. You decide what the AI handles on its own and what waits for your sign-off, and you move that setting as evidence accumulates. Nothing about that requires believing the technology has become reliable, which is the point.
In practice the whole discipline reduces to four controls, treated properly in our companion piece on trusting AI with clients: the AI drafts and a person sends; consequential steps genuinely pause rather than merely notify; some actions are categorically off the table no matter how confident the system is; and every approval leaves a record of who decided what, and when.
That last one is what turns this from a risk conversation into an accountability conversation — and, read against AB 316, it is also the only thing that will be worth anything if the question is ever asked adversarially. When a court, a carrier, or a client asks why something went out, “the AI did it” is not an answer. “Here is who approved it, and when” is.
The stories differ wildly in scale and not at all in structure. A frontier lab, a federal agency, an airline, and a public company all discovered the same thing: the AI acts, and a human organisation answers for it. In 2026 that stopped being a norm and started being a statute and a policy endorsement.
None of which is an argument for staying off AI. It is an argument for being able to say who approved what — before someone asks.
Every factual claim above traces to a primary document. In order of appearance:
Disclosure: we make HitLai, a governed AI platform for small businesses built on exactly these controls — the AI drafts real work (quotes, replies, invoices) from your business’s own data, a trust dial sets which actions pause for approval, it never moves money on its own, and every approval lands in a timestamped, tamper-evident audit trail. If you’d rather inspect the mechanics than take our word for them: the orchestration core, AICtrlNet Community Edition, is free and MIT-licensed. Or start somewhere smaller — the AI-visibility audit is free.
]]>Start with the honest answer: you can’t trust AI not to make mistakes. Not because the technology is uniquely unreliable, but because nothing that produces work at volume is mistake-free — not software, not vendors, not your best employee. Small businesses have always run on fallible workers, and they’ve survived because they never actually depended on infallibility. They depended on process: the new hire doesn’t email clients unsupervised in week one, the bookkeeper doesn’t sign the checks she writes, the big quote gets a second pair of eyes before it goes out. Trust was never a feeling about the person. It was a property of the controls around the work.
That reframing changes what you’re shopping for. The question isn’t “which AI makes the fewest mistakes?” — you can’t verify that claim, and the vendor making it can’t either. The question is “what stands between a mistake and my client?” That, you can inspect.
It helps to name the failure modes, because each one is caught by a different control:
Every one of these is survivable as a draft and expensive as a delivery. The whole discipline of using AI safely with clients reduces to widening that gap: make mistakes cheap by catching them before they leave the building.
The single highest-leverage rule: the AI’s output is a draft until a human says otherwise. The AI reads the inquiry, pulls the history, writes the reply, prepares the quote — and stops. A person reviews, edits if needed, and sends. You keep nearly all of the time savings, because drafting was the slow part, and you keep all of the judgment, because sending was never the slow part. A wrong fact in a draft costs the thirty seconds it takes to fix it.
For automation that goes beyond drafting, the load-bearing question is whether the pause is real. A notification is not an approval step — a notification tells you something already happened. A genuine approval gate stops the run and waits: nothing sends, posts, or books until a named person decides. Where should gates sit? A serviceable default for a small business: anything that touches a client or touches money pauses for a person; internal, reversible steps can flow. You don’t need to gate everything — you need to gate the steps you’d want to un-send.
Some actions shouldn’t be gated — they should be impossible. Decide what the system is categorically not allowed to do, no matter how confident it is: the common-sense list starts with moving money unattended and deleting records. Then borrow the oldest control in business, separation of duties: the person (or AI) that prepares a thing is not the one that approves it. A junior teammate can draft; a manager signs off. If a tool can’t express “this role drafts, that role approves,” it’s asking your whole team to share one set of keys.
Months from now, someone — an accountant, a client in a dispute, possibly a regulator — will ask why something went out. “The AI did it” is not an answer anyone accepts, and shouldn’t be. The control that answers it is an audit record: a timestamped log of what was proposed, who approved it, and when, kept in a form that can’t be quietly edited after the fact. This is the least glamorous control and the one that turns AI from a risk conversation into an accountability conversation: every consequential action has a named human decision attached to it.
Autonomy isn’t a switch, it’s a setting — and it doesn’t have to be the same setting for every task. Let AI run the routine, reversible work on its own from day one; keep client-facing and financial steps behind gates. Then loosen deliberately, the way you’d delegate to an employee: after fifty approved drafts with nothing to fix, the case for auto-sending the routine ones makes itself — and it’s a decision you made from a track record, not a hope.
A vendor who can answer all six plainly is selling you controls. A vendor who answers with model quality is selling you a hope.
Notice that nothing above requires believing AI has become reliable. That’s the point. Your clients don’t experience your tools; they experience what reaches them — and with these controls, what reaches them has a person’s judgment on it. The businesses getting real leverage from AI aren’t the trusting ones. They’re the ones who made trust unnecessary: draft-first, real gates, hard limits, and a record. Mistakes still happen. They just happen in drafts, where they cost minutes instead of clients.
Disclosure: we make HitLai, a governed AI platform for small businesses built on exactly these controls — the AI drafts real work (quotes, replies, invoices) from your business’s own data, a trust dial sets which actions pause for approval, it never moves money on its own, and every approval lands in a timestamped, tamper-evident audit trail. If you’d rather see the mechanics than take our word: the orchestration core, AICtrlNet Community Edition, is free and MIT-licensed. Or start by seeing what AI engines already say about your business — the AI-visibility audit is free.
]]>Automation used to mean one thing: connect app A to app B and let it run. Then AI started drafting the actual work — emails, quotes, invoices, customer replies — and business owners discovered a new problem: the automation became good enough to be dangerous. A misrouted data sync is an annoyance. An AI-drafted email sent to the wrong customer is an apology call. So a category grew up around a simple idea: pause before the consequential step and let a person decide. If you searched for Zapier alternatives with approval steps, you’re shopping in that category, and this page is the map.
First, what a human approval step actually is — because the term gets stretched. A notification is not an approval step; a notification tells you something already happened. A real approval step stops the run until a person decides. The mechanics are what separate the tools: where the request arrives (email, Slack, a task queue), whether the reviewer can edit the drafted work or only approve and reject, and — the question an accountant or auditor will eventually ask — whether there’s a record afterward of who approved what, and when. Every tool below implements a genuine pause-and-decide step. They differ in where the pause lives and what stands behind it.
The honest first entry on any “alternatives to Zapier” list is Zapier. It now ships a built-in Human in the Loop capability: a Request Approval action pauses the Zap while one or more reviewers approve, decline, or change the data submitted for review; a Collect Data action pauses to gather input; and a trigger fires when an approval is requested so you can log or route it. Approval notifications can go to email or Slack. It’s available on Pro plans and higher, each Human in the Loop action counts as a task, and reviewers need access to the Zap itself. If your stack already runs on Zapier and you need occasional approvals on a handful of steps, adding the built-in step is far less disruptive than migrating. The honest reason people still switch: in Zapier, approvals are steps added to a data-pipeline product. In the tools below, the pause is closer to the point of the product.
Relay.app was the tool most often recommended for this search, and the recommendation was deserved — human-in-the-loop steps were the centerpiece of the product rather than an add-on: a run paused at an approval step, the assignee got an interactive Slack or email notification with the context inline, and they could approve, reject, or edit the result before the run continued, including straight from Slack.
On July 16, 2026, Relay.app announced it is winding down. Free accounts lose access on August 15, 2026 and paying customers on September 14, 2026; new signups and free-to-paid upgrades are already switched off.
We’ve rewritten this entry rather than quietly deleting it, because if you searched for approval-step automation any time in the past year, Relay.app is probably what you were told to use. If you’re on it now, export before your cut-off date rather than after: workflows, sequences and MCP servers come out as JSON along with your AI prompts, run history exports, and tables come out as CSVs. Annual customers are receiving automatic prorated refunds for the unused period.
Where to go next depends on what you were using it for — see the choosing guide below, and the fuller migration answer if you’re moving now.
n8n is the option for teams with engineering skill who want to run the automation themselves — it’s source-available and self-hostable. Its human-in-the-loop design has a detail worth admiring: the gate is enforced at the tool level, not just the workflow level, so an AI agent can freely do safe things like search a knowledge base while risky actions — sending an email, updating a record, deleting data — wait for a person. Approval requests can go out over Gmail, Outlook, Slack, Telegram, WhatsApp, Microsoft Teams, or Discord, and the response can be an approve/deny button, free text, or a custom form the reviewer edits before submitting. The trade is the standard self-hosting trade: total control, and you’re the one maintaining it.
Lindy sells AI agents — the “AI employee” framing — rather than pipelines. Its approval mechanic is a per-action toggle: turn on Ask for Confirmation for any action with side effects (sending an email, updating a record, creating a calendar event) and the agent prepares the work, parks it as a draft in the task view, and waits. You approve from the task view or from the email it sends you, and only then does the action execute. For a solo operator who wants an assistant that never acts unilaterally, it’s a clean model.
HitLai — ours — starts from the same conviction as everything above: the pause is the feature. The difference is the frame. HitLai’s AI drafts the work itself — quotes, customer replies, invoices, purchase orders — from your business’s own data. You set the trust dial at the company, the department, the workflow, or the individual agent, and every action crosses that gate before it happens. Approval workflows are ordered and multi-step: each step routes to a named person, a role, or a group, carrying timeouts and conditions, and a reviewer can approve, reject, or delegate — from Slack, Teams, Discord, or email. Every decision lands in a timestamped, tamper-evident audit trail, each one chained to the last with a SHA-256 hash, so “who approved this and when” still has an answer months later.
And integration is never the roadblock. Native connectors for the tools you already run — Slack, Teams, Salesforce, HubSpot, Stripe, QuickBooks, Jira, Gmail and more. Your existing Zapier, n8n, Make, Power Automate and IFTTT automations run as a step inside a HitLai workflow, so moving doesn’t mean rebuilding. And when a connector doesn’t exist, HitLai builds one on the fly — against the API, or straight through the browser. There’s no catalogue to run out of. And if you’re the build-it-yourself type, the orchestration core is open source: AICtrlNet Community Edition is MIT-licensed and self-hostable.
Zapier moves data between apps. HitLai runs work your team approves.
The category exists because trust, not capability, is now the constraint on automation. Any of these tools can pause for a human. The question worth asking before you pick one is what you’ll be able to say afterward: when a customer, a partner, or an auditor asks why something went out, the answer “a specific person reviewed it, here’s the record” is worth more than any feature list. Relay.app’s wind-down adds a second question worth asking: whatever you pick, can you get your workflows back out of it? Keep them exportable.
Where to go next. See how visible your business is to AI answer engines — run the free AI-visibility audit. Building it yourself instead? AICtrlNet Community Edition is free and MIT-licensed. The short version of this post lives in our FAQ: What are the alternatives to Zapier with human approval steps? — and for the head-to-head, How does HitLai compare to Relay.app?
Each vendor’s approval mechanic is described from its own documentation, not from our reading of its marketing:
Leo Tavares of Google DeepMind DevRel posted back in May that agentic AI should be designed as state machines — declarative protocols, harness-owned state, explicit contracts. He’s right.
State machine is the correct primitive. The agent loop — perceive, decide, act, update — maps cleanly onto a finite set of states with explicit transitions. “Vibes-driven planner” does not. Most production agent failures I’ve seen trace back to systems whose state was implicit, scattered across prompt history, framework memory, and tool-call side effects, with no contract for what survives a retry.
The state-machine framing fixes that. Name your states, name your transitions, name what the harness owns versus what the model owns, and your agent becomes debuggable.
It is the right primitive. It is not the right architecture.
The state-machine framing implicitly imagines one machine. One protocol governing transitions. One framework owning the loop. One actor — the AI agent — running the show, with humans as approval-node endpoints.
Enterprise stacks are not like that. Enterprise stacks are plural in three ways the single-state-machine model cannot absorb without fracturing.
A real enterprise running agents in 2026 is speaking three to five protocols concurrently:
A single state machine assumes one protocol owns the transitions. Real systems have transitions that cross protocols — an A2A agent invoking an MCP tool that wraps a browser action that writes to a CRM via vendor SDK. State has to survive every bridge.
LangChain, AutoGen, CrewAI, Semantic Kernel, AutoGPT — every major agent framework ships its own loop, its own memory model, its own retry semantics, its own opinion about how planning interacts with tool use.
Enterprises are not standardizing on one. They run several — sometimes by accident (each team picked a different one), sometimes by design (different frameworks fit different workloads). When one framework fails or hits a capability boundary, the next must pick up state and continue. Restart is not acceptable; in regulated workflows, it is not legal.
A single state machine cannot span frameworks because each framework is itself a state machine with its own contract. What enterprise needs is a federation: each framework owns its local state, the federation owns the contract for how state crosses framework boundaries.
Cascading from LangChain to AutoGen to CrewAI without context loss is not one state machine. It’s three state machines sharing a federated state contract.
This is the plurality the agent-framework world consistently misses.
Every enterprise workflow involves humans doing what only humans should — judgment calls, regulatory approvals, exception handling, decisions where accountability cannot delegate. The dominant agent-framework treatment of humans is “approval node” — a synchronous wait state where the human signs off on what the AI proposes.
That is not the enterprise reality. Humans are workflow peers. They have capacity (some are at 100% utilization, others at 20%). They have capability profiles (one paralegal can clear an immigration filing; another can’t). They have continuity needs (handoff at 5pm to a colleague in another timezone, with context). They sometimes initiate the workflow and hand to an agent; they sometimes pick up mid-flight from an agent that escalated.
A workflow state machine that treats humans as approval-node endpoints fragments the moment a human-to-human handoff happens. A workflow state machine that treats humans as peer participants — with capacity, capability, and a state contract identical to any agent participant — does not.
In 2026, this is the most differentiated thing an orchestration platform can ship. Most cannot.
The architecture that survives all three pluralities is what I’ll call a federated state machine.
+-----+ +-----+ +--------+
| A2A | <->| MCP | <->| Vendor |
+-----+ +-----+ +--------+
\\ | //
\\ federation //
\\ contract //
\\ | //
+--------+ +--------+ +--------+
| LangCh | | AutoGen| | CrewAI |
+--------+ +--------+ +--------+
\\ | //
\\ federation //
\\ contract //
\\ | //
+--------+ +--------+ +--------+
| AI | | Human | | Human |
| Agent | | Peer | | Peer |
+--------+ +--------+ +--------+
Each participant — protocol, framework, runtime, human — runs its own local state machine. The federation owns the contract for how state crosses every boundary. Three properties define it:
State is preserved across protocol bridges. When a transition crosses A2A → MCP → vendor protocol, the federation guarantees what survives. The federation, not any individual participant, owns that guarantee.
State is preserved across framework cascades. When framework A hits its boundary and framework B picks up, the federation hands B a live continuation — not a restart from a serialized memory blob.
State is preserved across human-agent handoffs. When an AI agent escalates to a human peer, or a human hands a task to an agent, the federation carries context in both directions: what the AI knew, what it tried, what the human decided, and why.
That is the architectural primitive enterprise orchestration actually requires.
One protocol, one framework, one actor type. Clean. Debuggable. Brittle.
Brittle because the moment the stack diversifies — a second protocol arrives, a new framework gets adopted, a human peer needs to participate — the state machine fractures along its single-protocol assumption. The fix is always a custom adapter. The custom adapters are where state gets dropped.
Most reference architectures published in 2024-2025 are monolithic state machines. They demo well. They do not survive enterprise integration.
Popular in prototypes. Each turn is independent, each tool call is independent, each agent invocation is independent. State, if it exists, lives in prompt history.
Catastrophic in production. Nothing remembers what happened across a handoff. The same tool call gets retried with different intent because the agent forgot the prior failure context. Compliance audit is impossible because there’s no state to audit. Multi-step workflows become non-deterministic.
This is the architecture most “agent frameworks” actually ship under the hood, regardless of marketing. It’s why enterprise pilots stall at month three.
The orchestration vendors and platforms that win the next ten years will not be the ones with the cleanest single-agent harness. They’ll be the ones building federated state machines.
Three reasons:
The protocol landscape is converging on plurality, not unification. A2A and MCP are both gaining ground precisely because they cover different surfaces. Vendor-proprietary protocols inside SFDC, M365, and the hyperscaler agent platforms are not going away. The platform that bridges them owns the orchestration position.
The framework landscape is fragmenting, not consolidating. New frameworks ship every quarter; old ones don’t die. Enterprises adopt by team and use case. The platform that cascades across frameworks without losing state owns the durability position.
Humans are not going away. They’re moving up the value stack — out of routine work, into judgment work — but every enterprise workflow that matters still has humans in it. The platform that treats humans as peer participants in the state machine, not endpoint approvers, owns the trust position.
A federated state machine is the architectural primitive that makes all three positions defensible at once.
The single state machine is the right answer to the question Leo Tavares asked. The question enterprise architects should be asking is one level up: how many state machines, federated how?
About the author: Bobby Koritala is the founder of AICtrlNet and HitLai. Previously, he led product development at Infogix (now part of Precisely), building enterprise data integrity platforms for financial services and healthcare. He has spent 10 years building AI systems, including several patented ones.
References:
Yes, you genuinely can build it yourself. Imagine you’re sitting at your kitchen table with a laptop open, a fresh bag of coffee beside you, and you type a simple prompt into Claude Code: “Give me a Python script that pulls today’s flour and yeast quantities from our Google Sheet, formats them into a short message, and posts it to the #prep Slack channel.” In seconds the AI returns a runnable snippet that authenticates with a service account using environment variables, reads the rows, builds the text, and calls the Slack webhook with proper error handling. You can test it on your machine in under five minutes, watch the message appear, and feel the thrill of having a working tool without writing a single line of boilerplate by hand.
That same speed applies to a handful of common small-business needs. A bakery might want a daily inventory alert, a boutique shop could use a script that pulls new orders from a Square dashboard and sends a packing slip to the fulfillment team, a consulting firm could generate a weekly time-sheet summary from Harvest and post it to a private Teams channel, a landscaping business could schedule automatic reminders for upcoming lawn treatments by reading a shared calendar, and a gym could flash a “class full” notice to members when a spin session reaches capacity. With a natural-language request you can scaffold a basic CRUD interface for tracking equipment loans, stitch together Stripe webhook calls for a modest invoicing flow, or create the authentication and routing scaffolding that would otherwise consume an hour or two of manual coding. The output is a functional prototype you can run, tweak, and demonstrate to a colleague before lunch, then iterate on based on real feedback.
But the speed comes with a weight you must carry. Every line the AI generates is yours to inspect. You need to read it, run it against edge cases, verify that no credentials are leaked, and ensure nothing opens a door to abuse. When a library falls behind or a security patch appears, the responsibility to apply it lands on you. If the Google Sheets API changes tomorrow and the script stops posting at midnight, you’re the one who gets paged, digs through logs, and fixes the break. Maintaining an audit trail — recording who approved what, when, and why — forces you to build your own logging, store every action where auditors can find it, and review those logs regularly. As the business grows and the script must handle more data, more error conditions, or a new payment gateway, each expansion pulls engineering time away from the core product you’re trying to sell. What began as a five-minute experiment can evolve into a maintenance burden that scales with the very success you hoped to enable. Nobody warns you about that part at the start, because at the start it just feels like winning.
For a founder who already writes code and wants to steer every integration, building from scratch can be the right move. In that case I point you to AICtrlNet Community Edition, the MIT-licensed, self-hostable project I released on GitHub. It gives you a solid loop for AI orchestration so you don’t have to reinvent the dispatcher, the agent runner, or the basic state store. You can add custom agents that call proprietary APIs, hooks that enrich payloads with contextual data, or a tailored UI built with React or Streamlit while still seeing every decision point in the code. Because you own the repository, you can run internal checks, satisfy any compliance policy, and avoid being locked into a vendor’s roadmap. You can containerize the service with Docker, deploy it to a Kubernetes cluster, or run it on a modest VPS, keeping the entire stack under your own administrative control. When the AI layer is a strategic asset you want to keep under your own roof, having the source lets you protect that intellectual property and meet the exact controls your business demands. The project is open to contributions, so the orchestration core can keep evolving over time while the governance model stays visible in the code instead of buried in a vendor’s roadmap.
When the work you’re automating touches customers or money, and you don’t have engineering depth on staff, buying a governed layer makes sense. HitLai provides exactly that: the AI does the work — drafting a purchase order, a customer-facing quote, or a data-sync job — and you decide which actions wait for a human’s approval before they run. Routine steps flow through on their own; the ones that touch customers or money pause for a click. The platform never moves money on its own, so the financial risk stays with the person who gave the thumbs-up. We take care of security patches, keep the audit logs up to date, and generate the compliance reports that auditors expect. Approval steps can be configured with role-based permissions, so a junior team member can draft a PO while a manager provides the final sign-off, and every step is timestamped and immutable. For a non-technical owner the approval screen is a clear, familiar step that satisfies both internal controls and customer trust, without needing to write or maintain any infrastructure. The subscription cost is predictable and often ends up lower than the total cost of trying to hire, train, and retain the engineering talent needed to keep a DIY solution secure and reliable.
Many teams already use connectors to shift data. Zapier moves data between apps. HitLai runs work your team approves. That distinction matters when you consider who is accountable for each action. As AI makes it easier than ever to spin up functional software from a prompt, the scarce thing is no longer the code itself. What becomes valuable is the guarantee that a person is standing behind each action, ready to answer for what happened and why. Trust, accountability, and a transparent approval chain are the premium businesses are willing to pay for when the stakes involve real money or real relationships. Picture a small accounting firm using HitLai to draft client invoices and payment reminders: the AI proposes the draft, a bookkeeper on the team reviews it, and nothing goes out — and no money moves — until that person signs off. The client gets an accurate invoice on time, and if a mistake ever slips through, there’s a specific person who reviewed it and can explain why. In a world where anyone can generate an app with a few words, the real expense is the risk of unchecked automation. The market rewards platforms that supply the accountable layer, not just the AI that drafts it.
When AI can build the software, you’re not paying for the software anymore. You’re paying for who’s accountable when it acts.
Where to start. If you’re building it yourself, AICtrlNet Community Edition is free, MIT-licensed, and self-hostable. If you’d rather buy the governed layer, start with HitLai’s free AI-visibility audit — it shows you what AI already says about your business, and it’s the fastest way to see how the platform thinks. The short version of this post lives in our FAQ: Should you build your own AI automation with Claude Code, or buy a governed platform like HitLai?
]]>Most SMB owners I meet think they are behind on AI. They have no IT department, no governance framework, no integration roadmap, no internal AI strategy. They look at the Fortune 500 procurement playbook for AI and assume it applies to them, just smaller.
Then they conclude they are outmatched and wait.
The conclusion is wrong. Not “slightly wrong, but well-intentioned.” Structurally wrong.
The SMB position in the AI transition is not “behind.” It is “asymmetrically advantaged.” The mid-market firms and large enterprises that look so far ahead are spending two years and millions of dollars trying to undo what you do not have. You are not lagging. You are unencumbered.
This post is about what you do not have, what your competitors are paying to undo, and what you can do with the asymmetry while it is still open.
A mid-market firm I spoke with recently is in year two of a “modernization” project. The goal is to put AI on top of their existing operations stack. The existing stack includes:
The project budget was originally $4M. They are now at $7.5M and counting. The deliverable that was supposed to be live in eighteen months is currently scheduled for thirty.
The replacement for what they are building is not “five-vendor-stack-but-better.” It is one platform that handles what those five vendors handle separately. They could have bought it on day one. They did not, because they had built the five-vendor stack first and now have to unwind it before they can move.
You are not building that stack. That is not a deficiency. That is the asymmetric advantage you came to this post to find.
Read this list as features. Each of these is something a mid-market firm is paying significant ongoing money to maintain, and significant one-time money to eventually replace.
No 20-year ERP. Your competitors with one are paying license, maintenance, talent attached to the system, custom integrations between the ERP and every other tool, and an eventual seven-figure replacement bill. You can pick a modern, AI-native system of record today. Your operational data flows where AI needs it to flow.
No RPA estate. Your mid-market competitor has 240 bots that break every quarter. Each one was the cheapest solution at the time. Each one is now technical debt. You will solve the same problems with AI agents that handle exceptions, learn from corrections, and do not break when the UI changes.
No multi-year governance vendor contract. Your competitor signed a three-year deal with an AI governance vendor whose product monitors AI from outside. They cannot replace it without admitting it was the wrong purchase. You have not made that purchase. You can buy a platform with governance built into the work, instead of as a separate monitoring layer.
No internal “AI governance team” with a charter to defend. Your mid-market competitor hired five FTEs whose job is policy authoring and framework adoption. Those FTEs do not produce business outcomes; they produce compliance artifacts. Their job exists because the AI strategy was outsourced to a governance vendor. You will run AI as part of operations, not as a separate function.
No five-vendor integration tax. Your competitor has a small team whose entire job is keeping the five-vendor stack stitched together. That team produces nothing customer-facing. You will not need them, because your platform will not be five vendors.
No twenty years of business rules embedded in undocumented code. Your competitor’s system of record carries decisions made by people who left the company a decade ago. Replacing the system means re-discovering those decisions. You are starting from zero embedded rules. Whatever rules you define today are documented, owned, and AI-readable from day one.
Notice what is happening in this list. Every item is a present-tense cost your competitor is carrying. Every one of them is also a future replacement bill. You skip both.
The asymmetric advantage is real. The question is whether you use it.
Three concrete shifts:
Pick AI-native, not legacy-wrapped. When you evaluate a platform, ask whether it was designed for AI to be the central actor or whether it was designed for humans to use, with AI added later. The first kind of platform makes AI a feature of every workflow. The second kind makes AI a feature of one menu. The architectural difference shows up six months in, when you try to do something the second platform did not anticipate.
Design workflows AI-first, not human-first. A human-first workflow assigns the AI a task at one point in the flow. An AI-first workflow assumes AI handles the standard path end-to-end and your team handles the exceptions. The difference shows up in throughput. The first design lets you process 1.2x what your team could before. The second lets you process 4-8x.
Treat your small team as a feature. A team of five working with AI as peers — not as a tool — moves faster than a team of fifty working with AI as a feature. The mid-market firm with 800 Copilot seats has not become 800 people working with AI. They have become 800 people occasionally using AI to draft emails. A team of five running an AI-native operation runs circles around them, in the categories of work where you compete.
This advantage is not permanent. Two forces close it.
The first is awareness. Right now, the SMB segment broadly does not yet recognize the advantage. By 2028, the smart ones will. After that, “AI-native SMB” will be the default expectation in any segment where SMBs compete, and the advantage will be merely common practice, not asymmetric.
The second is incumbent unlock. Mid-market and large-enterprise incumbents will, at some point, finally make the painful decision to break the legacy lock. When they do — and the smart ones are starting now — they will catch up on the architectural advantage. The window from “asymmetric advantage” to “everybody has it” is probably two to four years.
That is your window. Two to four years where the structural advantage is real and largely uncontested. After that, AI-native operations is the default and the advantage is gone.
The SMBs that take the window seriously and press it are not going to be small forever. The SMBs that wait for “AI to mature” before adopting it will, in many of their segments, be acquired or outcompeted by the SMBs that pressed early.
I have spent nearly three decades inside enterprise software, including seven years as Chief Product Officer at Infogix (now Precisely) building data integrity tools for the majority of US banks and health plans. The pattern repeats across cycles. The incumbent that owns the legacy infrastructure looks impregnable — until a new entrant builds on the next architectural primitive and runs past them in five years.
Right now, the next architectural primitive is AI-native operations. The incumbents are spending billions trying to wrap legacy with it. SMBs can build on it directly.
The smart move for an SMB owner in 2026 is not to wait. It is to use the asymmetric advantage while the asymmetry is still real.
You do not have what they are undoing.
Use that.
About the author: Bobby Koritala is the founder of AICtrlNet and HitLai. Previously, he led product development at Infogix (now part of Precisely), building enterprise data integrity platforms for financial services and healthcare. He has spent 10 years building AI systems, including several patented ones.
References:
At an industry conference last month, a CIO asked a question I’ve now heard six times this spring: “How do I get AI working with my legacy apps?”
Sometimes the legacy app is a mainframe. Sometimes it’s the twenty-year-old ERP. Sometimes it’s the COBOL claims processor, the AS/400 inventory system, or the custom Java platform that’s been running production since 2007. The system is always different. The question is always the same.
The question itself is the diagnosis. It assumes the legacy stack is staying. It assumes the AI strategy has to wrap, not replace. And once you assume that, you have already lost most of the strategic optionality you would have had if you had asked the question differently.
In Part 9 of this series, I argued that the buyers most equipped to recognize the Frankenstein stack are the ones least likely to see it. Six structural reasons explained why. But seeing it is only half the trap. Even buyers who do see it — who recognize the assembled mess for what it is — still cannot easily unwind it. Because underneath the AI Frankenstein stack is something older and harder to move: the legacy systems the enterprise has been carrying for fifteen, twenty, sometimes thirty years.
This is the other half of the trap.
When a CIO talks about “legacy,” they do not mean one system. They mean a mesh of dependencies:
This is not a single asset to retire. It is a structural commitment that touches operations, compliance, finance, talent, and politics. “Just replace it” does not apply to any of those dimensions.
The Frankenstein stack diagnosed five new vendors stitched together. Legacy lock adds a sixth dimension: the old stack underneath that the new stack has to wrap.
| Layer | What it costs |
|---|---|
| Legacy stack | Maintenance, licensing, audit, talent, vendor management |
| Modernization layer (AI, automation, governance) | New vendor contracts, implementation, training |
| Integration tax between them | Custom integrations, middleware, integration team |
The enterprise pays for all three. The competitor who built greenfield pays for one.
That is the real cost of the legacy lock. Not the maintenance line item — that is just the visible bill. The invisible bill is the structural disadvantage that compounds quarter over quarter as everyone who did not carry the legacy stack moves faster than you can.
Knowing the stack should move is not the same as being able to move it. Here are the five structural forces that keep legacy in place even after the CIO understands what it is costing.
| # | Reason | What’s actually happening |
|---|---|---|
| 1 | Fear of breaking what works | Chronic legacy cost vs acute career risk of replacement gone wrong |
| 2 | The regulator already knows the legacy system | Re-certification is a multi-year exercise no vendor pitch deck mentions |
| 3 | The skills are attached to the legacy | Twenty years of operational knowledge live in engineers’ heads, undocumented |
| 4 | The decommission tax is never budgeted | Replacement projects undercount because the undercounted parts only become visible after approval |
| 5 | The legacy vendor sells the modernization roadmap | “Modernization-in-place” looks safer than rip-and-replace, but mostly keeps you locked |
The mainframe runs claims processing for two million members. The custom ERP runs procurement for a multi-billion-dollar manufacturer. The system that has been running for twenty-two years has been audited twenty-two times and never had a material incident. The CIO who proposes replacing it — even gradually — is the CIO whose career rides on a replacement that goes wrong in production.
The political risk asymmetry is brutal. Maintaining legacy carries a chronic cost everyone has been ignoring for years. Replacing legacy carries acute career risk if it fails. Most CIOs do not optimize for the chronic cost. They optimize for the acute risk.
This is not irrationality. It is reasonable behavior inside a structure that punishes visible failure much more than it rewards quiet wins.
For regulated enterprises — banks, insurers, healthcare payers, utilities — the legacy system is what the regulator audited. The auditor has eighteen years of working relationship with that system. The model risk team has built their entire validation framework around its quirks. The compliance team has the documentation that maps every business rule to a regulation.
Replacing it requires re-certification. Re-certification means the regulator needs to understand the replacement in the same depth they currently understand the original. That is not a six-month exercise. For some regulated systems it is a multi-year exercise with active regulator engagement and no guaranteed outcome.
The legacy system is, in regulatory terms, paid for. The replacement is not. The cost of re-certification is real, and it does not appear on any vendor pitch deck.
The senior engineers who keep the mainframe running are not interchangeable with the AI engineers the CIO has been told to hire. They know COBOL, JCL, IMS, and twenty years of business context that lives in those engineers’ heads. When the CIO replaces the system, they also lose access to twenty years of institutional knowledge that was never written down.
The replacement project assumes the new team can re-discover what the old team already knows. They almost always cannot, not at the depth required to run production. The cost of skills transfer — not training, but the actual transfer of operational knowledge — is one of the largest hidden costs of legacy replacement, and it almost always lands on schedule three months before launch.
Most legacy replacement projects budget for the replacement. They do not budget for the decommission. They do not budget for the parallel-run period when both systems are in production. They do not budget for the regression-test investment required to confirm that the new system produces the same outputs as the old one across edge cases that have not fired in years.
The pattern is reliable: original budget is X. Actual cost is 2-4X. Schedule is 18-30 months instead of 9-12. The CIO who proposed the project budget is often no longer the CIO running it by the time it finishes.
This is not a vendor problem. It is structural. Modernization budgets always undercount because the undercounted parts only become visible after the decision to proceed has been made.
The vendor whose legacy system is locked into your enterprise has a strong incentive to be the same vendor that sells you the modernization roadmap. The path from “your mainframe” to “your cloud mainframe with AI features” is paved by the same vendor who sold you the original mainframe, on a contract that keeps you locked for another seven years.
This is the deepest version of the trap. The CIO has heard “rip and replace” advice from outside consultants. The CIO has watched two peer companies attempt rip-and-replace and stall in year three. The CIO has been pitched by the legacy vendor on a “modernization-in-place” story that promises to add AI capability without the rip-and-replace risk.
The modernization-in-place story is mostly false. It keeps the data, the schema, the assumptions, and the constraints of the legacy system. It adds an AI veneer. It does not move the underlying architecture. But it sounds safer than rip-and-replace, so it wins the budget approval.
The CIO has not chosen modernization. The CIO has chosen the path that minimizes the acute career risk of the next eighteen months.
The legacy stack does not just cost what it costs today. It costs the gap between what your enterprise can do with the stack you have and what your competitor can do with the stack they have. That gap widens every quarter.
A few visible markers of the gap:
None of this is theoretical. The compounding architectural advantage is what disrupts regulated industries one cycle later than everyone expects. It is what Clayton Christensen described in The Innovator’s Dilemma. It is what banking watched with neobanks. It is what retail watched with Shopify-native direct-to-consumer brands. It is what is happening to enterprise AI right now.
The leapfrog narrative is overused, but the structural mechanism is real. The companies that catch and pass legacy-heavy incumbents in the next five years will not do it because they have better AI. They will do it because they have less to undo.
Three cohorts are positioned to leapfrog:
Greenfield SMBs. A fifty-person company starting today has no twenty-year ERP. They can choose an AI-native platform from the first system of record they put in place. Their operational architecture has AI at the center, not bolted on the side. They are not, in 2026, a threat to a Fortune 500 incumbent. By 2029, the better-run ones are.
Mid-market firms that have not yet committed to a Frankenstein modernization stack. Many mid-market enterprises in regulated industries are still at the “we’re evaluating AI” stage. They have legacy, but they have not yet bought the five-vendor Frankenstein stack on top of it. They have a one-time choice. They can either follow the large-enterprise playbook into the trap, or they can skip it.
Internal teams inside large enterprises running greenfield experiments with executive air cover. Some Fortune 500 organizations have a small team somewhere — usually in a less-regulated business unit — running an AI-native stack outside the main IT environment. If that team’s results outperform the central modernization roadmap by enough, the central roadmap eventually gets replaced. This is the long path. It works.
I spent seven years at Infogix as Chief Product Officer, building data integrity tools that wrapped legacy systems. The product worked. The customers were grateful. And I watched, over and over, the cost of leaving the legacy stack in place compound against enterprises that should have been able to outrun their challengers.
The pattern is not new. What is new is the speed at which the architectural gap is widening, because AI compounds. Every quarter your competitor’s AI capability extends — without the legacy integration tax — your gap grows.
There is no clean answer to the legacy lock. Rip-and-replace is expensive, risky, and often fails. Modernization-in-place is mostly a vendor story that delays the inevitable. Wrapping the legacy with AI keeps the cost growing.
The honest answer is the one CIOs hate to hear: the longer you wait, the harder it gets. The window for managed transition narrows every quarter. By the time the legacy system finally has to be replaced — because the vendor end-of-lifes it, or because the regulator forces a change, or because the talent literally retires — you will be making the decision under acute pressure instead of under deliberate planning.
The CIOs who saw the Frankenstein stack coming a year early were rare. The CIOs who see the legacy lock for what it is — and start moving while they still have time — will be rarer still.
Be one of them.
Or be the one your successor inherits the decision from.
This is Part 10 of the Frankenstein Stack series. Read the original 8-part series starting with The Frankenstein Stack: How Enterprises Are Assembling AI Wrong, and the Part 9 coda on why sophisticated buyers can’t see what they’re living.
About the author: Bobby Koritala is the founder of AICtrlNet and HitLai. Previously, he led product development at Infogix (now part of Precisely), building enterprise data integrity platforms for financial services and healthcare. He has spent 10 years building AI systems, including several patented ones.
References:
I finished publishing the Frankenstein Stack series three weeks ago. Eight posts over a month, arguing that enterprises were assembling AI wrong — one procurement decision at a time, five vendors deep, with nobody governing the seams. I called it the Frankenstein stack. The name stuck.
The diagnosis held up. The market pattern has only accelerated. While the series was running, Anthropic launched Claude Managed Agents with tool-level approval tiers. AWS shipped Bedrock AgentCore. Databricks made Agent Bricks generally available with multi-agent supervision. Microsoft made Copilot Studio the default agent surface for enterprise. Five layers of the Frankenstein stack now have hyperscaler weight behind them. The integration tax got worse. The seams got wider.
And yet — and this is the part I wasn’t expecting — the buyers most equipped to recognize the pattern are the ones least likely to.
I’ve spent the last sixty days in rooms with Heads of AI, Chief Data Officers, CIOs, AI governance leaders. People whose entire job description, on paper, is to see exactly what the series diagnosed. Most of them can’t. Not because they’re not smart — most are very smart. Not because the diagnosis is wrong — the diagnosis is more visible now than it was a month ago.
The reason they can’t see it is structural. And it’s worth naming, because the structure is what’s going to govern the next eighteen months of enterprise AI procurement.
Four observations on where the market is in late May 2026:
The pattern is more entrenched, not less. So why isn’t the diagnosis spreading?
I want to be careful here. The buyers I’m describing are not naive. Many are former engineers, former operators, former vendor-side product leaders. They read the same research, attend the same conferences, sit on the same panels. The reason the Frankenstein pattern is invisible to them is not ignorance. It’s structural — six structures, specifically.
| # | Reason | What’s actually happening |
|---|---|---|
| 1 | Vendor-default reflex | Copilot is the procurement-approved hedge — choosing it carries near-zero career risk |
| 2 | Category-shaped procurement | Each AI layer is evaluated against its own quadrant; no quadrant exists for “the whole stack” |
| 3 | Buyer career age | Most “AI leaders” are 18-24 months into roles that didn’t exist pre-2023; learning from the vendors selling the stack |
| 4 | “Another tool” reflex | Pattern recognition fires on “new vendor demo” before architectural analysis on “stack-collapsing layer” |
| 5 | Pain hasn’t accumulated | Most enterprises at 2-3 AI tools; the seams break loudly at 5+ |
| 6 | Sunk-cost defense | Buyers who already assembled four of the five layers can’t accept the diagnosis without re-litigating their own track record |
Earlier this spring I attended a CIO panel at an industry conference. The panelists were CIOs running AI portfolios at regulated mid-market enterprises — sharp, experienced people in hard jobs, all of whom I respect. The moderator opened with the question I’ve now heard at every CIO event this year: “What’s your AI strategy?”
Every panelist’s opening word was the same: Copilot.
Then they layered in nuances. We started with Copilot, now we’re piloting agents. Copilot for productivity, Bedrock for back-office. Copilot, then we’ll evaluate Salesforce Agentforce next quarter. The opening word was always the same.
This isn’t a Microsoft conspiracy. It’s how enterprise procurement works under pressure. When the CFO asks “what’s our AI strategy?” and the board asks “are we using AI?”, the CIO needs a defensible answer. Copilot is the defensible answer — bundled with M365, security review done, procurement category established. The political risk of choosing it is roughly zero. The political risk of not choosing it, in May 2026, is much higher than zero.
So “Copilot” became the AI strategy, the same way “Microsoft Office” became the productivity strategy in 1998. Vendor-default isn’t a decision. It’s the absence of a decision the buyer can’t yet make.
A Fortune 500 healthcare payer recently posted a public job for their AI governance team. The role description was thoughtful — accountability for responsible AI, policy authoring, cross-departmental coordination, regulator engagement, framework adoption (NIST AI RMF, ISO 42001).
It was also revealing in what it left out.
There was no mention of cross-system coordination. No mention of the seams between AI systems. No mention of cross-vendor audit, or responsibility for agents the team didn’t build, or operational accountability for the integration tax. The role was scoped to the governance vendor’s view of the world — write policies, run frameworks, generate reports. The job description matched the procurement category.
This is the deepest reason the Frankenstein stack assembles itself. Enterprises evaluate AI in categories that match how vendors sell, not how AI is actually used. Each category has its own analyst quadrant, its own RFP template, its own buying committee. Governance vendors compete against other governance vendors. Automation platforms compete against other automation platforms. AI assistants compete against other AI assistants.
Nobody compares the whole stack — because the whole stack isn’t a category. There’s no quadrant for “the integrated operation of AI plus humans plus existing systems.” So the integrated operation is nobody’s job to evaluate. The job description writes itself to fit the analyst quadrant.
Most “Heads of AI” and “AI Governance Leaders” I meet today are eighteen to twenty-four months into their roles. Their roles didn’t exist before late 2023. Many were promoted from adjacent disciplines — analytics, data governance, security, ops — based on demonstrated capability there, not deep AI background.
This is not a criticism. The roles had to be filled and the talent pool had to come from somewhere. But it has a consequence: the cohort of people whose job title says they own AI is, on average, learning the field as the field is being assembled.
What does learning look like in 2026? Vendor blogs. LinkedIn posts. Hyperscaler conference keynotes. Analyst webinars. The same content layer that’s selling the Frankenstein stack is also where most of the people responsible for procuring the Frankenstein stack are learning about AI.
This produces a specific kind of literacy gap. I routinely meet AI leaders who use LLM, agent, orchestration, and governance as roughly interchangeable terms. They know all four matter. They cannot reliably tell you the architectural difference between an LLM call and an agent loop, or between policy applied at runtime versus design-time, or between an orchestration layer and a connector catalog.
When the buyer can’t draw the architectural distinctions, the buyer can’t see the Frankenstein pattern. The pattern only becomes visible as the architectural distinctions — five vendors doing five categorically different things, in five disconnected execution paths.
Some of the sharpest people I’ve shown the platform to have responded with the same sentence. A senior IT leader at a regional bank — someone who reviews AI tools regularly, who’s seen everything — sat through an evaluation conversation, watched the demo, and at the end said, “Looks like another integration we’d have to build.”
I want to be fair to that response. From inside the Frankenstein stack, every new vendor is another integration to build. It’s a learned reflex, and the reflex is mostly right.
But it’s wrong here.
A unification layer doesn’t add an integration. It collapses several. The bank in question already had Copilot, two automation platforms, an RPA estate, a governance vendor, and an agent pilot. The integration burden was already six layers deep. A unification layer doesn’t make that seven. It makes it one — if the buyer can see that’s what’s happening.
The reflex misfires because pattern recognition runs faster than architectural analysis. The buyer recognizes “new vendor demo” before they recognize “the answer to the stack problem they’ve been complaining about.” The recognition fails at the category-shape, not at the substance.
This is, in my experience, the single most common reason sophisticated buyers reject the diagnosis even when they’re living its consequences. It is not a product failure. It is a category-recognition failure — and category recognition is the hardest thing to change in B2B enterprise sales.
The Frankenstein stack hurts most at five-plus AI tools in production with a real incident report on the table. That’s when the seams become visible — when the customer got the wrong refund, the compliance team got the wrong audit trail, the regulator asked a question that required correlating logs from four vendors and one custom integration.
Most enterprises in May 2026 are not yet at five tools. They are at two to three. Copilot, a pilot of agent X, an automation platform from the previous wave. The pain is real but not acute. The seams exist but haven’t broken loudly enough to demand attention.
This is the cruelest of the five structures, because it has to play out in real time. The buyer who can’t see the pattern at three tools is the same buyer who will see it at six tools, with an incident report in their hand and a board meeting on Friday. The diagnostic clarity arrives after the cost is sunk.
When I started writing this series, I assumed the diagnosis itself would speed up that recognition. It hasn’t, in any meaningful number of cases. The series got read, shared, cited — and the same readers went back to their organizations and bought the next vendor in the next category, on the next category-shaped procurement cycle.
The first five structures above explain why a buyer who hasn’t yet bought the Frankenstein stack might not see it forming. They don’t fully explain why a buyer who has already assembled four of the five layers can’t see it either.
That one is sunk cost.
Once an enterprise has signed the three-year contract with the governance vendor, rolled Copilot to 5,000 seats, built six custom integrations between the automation platform and the CRM, and stood up an AI governance team with five FTEs and a charter — the cost of admitting “we got the architecture wrong” is no longer financial. It’s professional.
The CIO who recommended the governance vendor to the board needs that vendor to be the right answer. The Head of AI who hired the governance team needs that team to be necessary, not redundant. The procurement team that ran the eight-month RFP for the automation platform needs that RFP to have been the right exercise. Behavioral economics has a clean name for this — sunk-cost fallacy — and it applies to enterprise architecture decisions as forcefully as it applies to individual choices.
When the diagnosis says “your stack is structurally wrong and the way forward is to consolidate,” the buyer who has already spent two years assembling that stack hears something different: “you wasted two years and millions of dollars, and we’d like you to admit it publicly.” That is not a diagnosis a sunk-cost-defensive buyer can accept without admitting they were wrong. So they reject the diagnosis, often without consciously knowing why. The architecture argument lands as a personal indictment, and the personal indictment is easier to reject than to engage with.
This is the most charitable reading of why even sharp, technically credentialed buyers reject the diagnosis when they have heard it and understood it. They cannot accept it without re-litigating their own track record. The five structural reasons above explain why they can’t see the pattern; sunk cost explains why, even once they see it, they can’t say it.
Geoffrey Moore named this pattern in 1991. Pragmatist buyers — the dominant cohort in enterprise procurement — do not recognize problems from first principles. They recognize problems from confirmation by other pragmatists they trust. A pattern only becomes a “real problem” once a critical mass of peers in the reference set have publicly admitted to having it.
The implication is uncomfortable. The Frankenstein stack is, in May 2026, sitting in the chasm — not because the diagnosis is wrong, but because no pragmatist in the reference set has yet had the public “we got this wrong, we need to consolidate” moment. The early-adopter buyers who can see it from first principles are already on the other side. The pragmatist majority is waiting for permission to see it. They are waiting for a peer at a similarly-sized, similarly-regulated, similarly-cautious enterprise to stand up at a conference and say “we bought five AI vendors and we’re collapsing it to one.”
That conference talk has not happened yet. So the diagnosis remains invisible to the cohort that most needs to see it. Not because they’re not paying attention. Because pattern recognition in this cohort requires social confirmation, and the social confirmation has not yet arrived.
It will. In my experience the social-confirmation moment in B2B always arrives — but it arrives twelve to twenty-four months after the early-adopter cohort has already moved. The cost of that lag is paid by the pragmatist majority, in extra vendor contracts and integration debt and incident reports that wouldn’t have happened on a unified stack.
A year from now — eighteen months at the outside — pragmatist enterprise buyers will be doing a small set of things differently. I’m willing to make this prediction publicly because I’m watching the early-adopter cohort do it already, and the pattern usually crosses the chasm on roughly that timeline.
Here’s what will be standard practice by late 2027:
An honest portfolio audit. Today, when you ask a CIO how many AI tools are in production, the typical answer is “two or three.” The real answer — once you include shadow deployments, departmental tools central IT didn’t approve, and embedded AI features inside platforms the enterprise already owns — is typically five to eight. The audit will become standard procurement hygiene. We do not add the next AI vendor until we know what we already have.
The “who governs the seams” question. Today this question doesn’t exist in most RFP templates. By late 2027 it will be a standard requirement: show us how your tool participates in cross-vendor audit. Show us how an incident report would be assembled across the five vendors in our current stack.
Cross-category evaluation. Today, governance vendors are compared against other governance vendors. By late 2027, a critical mass of buyers will run cross-category evaluations: show us how one platform handles what these three categories handle separately. The category-shape of procurement will start to break, because the cost of category-shape will have become visible in the budget line.
“We use Copilot” as the start, not the end. Copilot, Gemini, ChatGPT Enterprise will be table stakes — table stakes, not strategies. The real strategy conversation will start one layer up: given that we use Copilot for individual productivity, what runs the multi-step process work it can’t? What audits both as a single trace? Rare in May 2026. Dominant by late 2027.
A pragmatist will stand up at a conference. Someone at a Fortune-500 enterprise will publicly describe what their old five-vendor AI stack looked like, what the consolidation looked like, and what the incident report that drove it contained. After that talk, the chasm closes for the cohort that watches it. After that, the diagnosis becomes a meme. After that, a procurement requirement.
None of this is gloating. It is the standard B2B chasm timing. I am writing it down now so that, eighteen months from now, the buyers who wish they’d moved earlier have a record of when the diagnosis was available.
I built AICtrlNet because I saw this pattern coming, from inside a prior generation of it.
In 2003, the data quality industry was in roughly the position the AI governance industry is in today. Quality was a category. There were quality vendors. Enterprises bought quality tools and bolted them onto data pipelines that hadn’t been designed with quality in mind. The vendors monitored the pipelines from outside. They generated reports. They flagged issues after the data had already moved.
The lesson, which the data quality industry paid roughly twenty years and trillions of dollars to learn, was that quality belongs in the pipeline, not bolted on from outside. The vendors that survived rebuilt around that lesson. The vendors that didn’t were absorbed, repositioned, or quietly wound down.
AI is, structurally, the same category at year two of the same cycle. Most of the same arguments are being made — governance is its own thing, it should be a separate purchase, the vendor that monitors from outside has the cleanest objectivity. Most of those arguments are wrong, the same way they were wrong in 2003. They will be unwound in roughly the same way, on roughly the same timeline, with roughly the same number of zeroes attached to the cost of the lesson.
The cycle is going to happen. The only variable is who lives inside it and who watches it from the other side.
Be the person who saw it coming.
Or be the person who has to clean it up.
This is Part 9 / Coda of the Frankenstein Stack series. The original 8-part series ran April–May 2026; this follow-up reflects on the weeks since. Read the series starting with The Frankenstein Stack: How Enterprises Are Assembling AI Wrong.
About the author: Bobby Koritala is the founder of AICtrlNet and HitLai. Previously, he led product development at Infogix (now part of Precisely), building enterprise data integrity platforms for financial services and healthcare. He has spent 10 years building AI systems, including several patented ones.
References: