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:
Over the last seven articles, I’ve examined what happens when enterprises assemble AI capabilities one vendor at a time:
Every one of these layers exists because it solved a real problem. And every one created new problems by operating in isolation.
The pattern is the same one that cost the data quality industry trillions: build capability first, bolt on governance second, spend years managing the gaps between point solutions.
We built something different.
AICtrlNet is a governed AI orchestration platform. HitLai is the commercial product built on it.
Instead of stitching together five vendors, it’s one platform that handles multiple layers of the stack — with governance built into the execution path, not bolted on from outside.
Here’s what that means in practice:
It does the work. This isn’t a governance tool that monitors other systems. AICtrlNet’s AI agents execute workflows, process documents, interact with external services, make decisions, and take actions. The work gets done inside the platform — not in five separate tools with custom integrations between them.
It governs inline. Every action the AI takes is evaluated before it executes. Allow, deny, or escalate — resolved in the execution path, not flagged by an external monitor after the fact. The same platform that does the work also governs it. No seams between the “doing” layer and the “governing” layer because they’re the same layer.
It gives you the AI Dial. Not a switch between “manual” and “full auto.” Per-workflow, per-agent, per-department autonomy levels that adjust over time based on demonstrated performance. Your support team at full autonomy for Tier 1. Your legal team at human-approval-required. Your finance team at supervised-with-escalation. All running simultaneously, all governed through the same policy engine.
Prof. Mohanbir Sawhney at Kellogg School of Management (Northwestern) observed in a public exchange that orchestration without governance that adapts as AI maturity grows is essential for agents to be trusted. He referred to this concept as Governed AI Orchestration — and we agree. We colloquially call it the AI Dial: the infrastructure that lets you set, adjust, and evolve how much autonomy your AI has, with the governance built into every position.
| Frankenstein Layer | What It Does | What AICtrlNet Does Instead |
|---|---|---|
| AI Governance (SurePathAI, etc.) | Monitors AI from outside | Governance is inline — every action evaluated before execution |
| RPA (UiPath, etc.) | Brittle scripts for structured tasks | AI-driven browser automation + workflow agents — intelligent, self-healing |
| AI Assistants (Copilot, etc.) | AI inside one vendor’s ecosystem | AI agents that work across any system, any channel, any API |
| Automation (Zapier, etc.) | Connector catalog | AI-native orchestration with governance on every step |
| Autonomous Agents (OpenClaw, etc.) | Full autonomy, no governance | Graduated autonomy — the AI Dial per agent, per task |
One platform. One audit trail. One AI Dial. No seams.
The insurance company from Part 1 — the one with the five-vendor stack — could replace it with:
No seams. No context loss at handoff points. No silent failures between systems. When something goes wrong, the full decision chain — data considered, rules applied, autonomy level, outcome — is in one log, not five.
The bank from Part 7 — the one with the governance gap at the seams — could replace their stack with:
The compliance team gets one dashboard. The CISO gets one audit trail. The business line leaders get AI that actually does the work. And the integration team? They’re not stitching five vendors together anymore.
The integration objection — “but do you connect to X?” — is what drives enterprises to the connector catalog model (Zapier, n8n) in the first place. If you can’t connect to the tools people use, none of the governance architecture matters.
So we designed for universal reach:
Established ecosystems. Connections through major automation platforms unlock thousands of integrations without building each one individually.
Any API. AI agents that can discover, evaluate, and connect to new services on the fly. Not a roadmap item. Not a future release. In the conversation where you need it.
Any web application. Browser automation that navigates any system a human can use — legacy apps, internal tools, government portals. If it has a URL, the AI can reach it.
Every layer has the same governance. The same AI Dial. The same audit trail. Whether the AI is calling an established API, generating a new integration at runtime, or navigating a legacy web application through a browser.
We didn’t build a governance layer. There’s no separate “governance product.” The governance is the system. You don’t buy airbags separately from the car.
We didn’t build another automation tool. We built an orchestration platform where AI is the collaborator — making decisions, processing documents, taking actions within the boundaries you set.
We didn’t build for one autonomy level. Different tasks, different teams, different stages of trust require different positions on the AI Dial. Simultaneously. Adjustable over time.
We didn’t build a closed ecosystem. Three layers of reach — established integrations, self-extending agents, browser automation — mean the answer to “do you connect to X?” is always yes.
Enterprise AI leaders face a real decision:
Path A: The Frankenstein Stack. Five vendors, five contracts, five governance stories. Each evaluated in its own category. Each good at its job. Together: a complex, fragile system where risk lives in the seams and nobody owns the gaps. Integration tax that grows every quarter. Audit trails that don’t correlate. Governance that monitors but doesn’t prevent.
Path B: Governed AI Orchestration. One platform that does the work and governs it. The AI Dial set per task, per team, per workflow. One audit trail. No seams. Universal reach. Governance that’s built into every action, not bolted on from outside.
The data quality industry spent 20 years proving that bolt-on quality doesn’t work. The AI governance industry is at year 2 of the same cycle.
You don’t have to repeat the pattern.
AICtrlNet Community Edition is free and open source. Standard Docker infrastructure, local AI model support, the full AI Dial. No credit card, no sales call, no lock-in.
HitLai is the commercial product — additional capabilities, expert setup assistance, and enterprise features for organizations that want to move faster.
The Frankenstein stack assembled itself because each tool solved the problem in front of it. But the system-level problem — governed AI orchestration — requires a system-level solution.
That’s what we built.
This is Part 8 of 8 in The Frankenstein Stack series. Read the full 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.
]]>Picture this scenario at a mid-size financial institution:
A customer submits a complex insurance claim. Here’s what the Frankenstein stack does:
The claim is approved and paid. Three weeks later, audit discovers the recommendation was based on incomplete data — the RPA bot failed silently on step 3, returning partial records. The autonomous agent didn’t know the data was incomplete. The governance tool logged the recommendation but not the data quality issue. The automation platform just passed data through. Copilot’s initial summary was fine.
Now: which system is accountable?
The governance tool says it logged everything it was configured to monitor. The RPA vendor says the bot executed its script correctly (it did — the legacy system returned partial data). The automation platform says it routed correctly. The agent says it evaluated the data it received.
Everyone is right within their silo. The failure happened in the seam between them.
Every enterprise integration creates a seam — a boundary between systems where data, decisions, and context cross from one vendor’s domain to another. In the Frankenstein stack, these seams multiply:
| From | SEAM | To |
|---|---|---|
| Copilot | custom integration | Automation Platform |
| Automation Platform | custom integration | RPA |
| Automation Platform | custom integration | AI Agent |
| AI Agent | custom integration | Governance Tool |
4 seams in a 5-tool stack. Each seam is: a custom integration that can break, a governance gap that nobody owns, a context loss where decision rationale disappears, and an audit trail discontinuity. Nobody’s job to govern the seams.
The governance tool monitors what happens inside the AI tools it knows about. But the decisions that matter — “should this data be trusted?”, “is this handoff complete?”, “does this agent have the full context?” — happen between tools. In the seams.
When a decision crosses from one system to another, context gets stripped. The automation platform passes a data payload to the AI agent, but the payload doesn’t include why Copilot flagged the claim as complex, or which policy rules the human reviewer was concerned about. The agent makes a decision without the full picture — and nobody knows context was lost, because nobody’s monitoring the seam.
In a unified system, context travels with the decision through every step. In the Frankenstein stack, each handoff is a lossy compression.
The RPA bot in the scenario above didn’t throw an error. It returned data — just not all of it. The legacy system timed out on a query and returned a partial result set. The bot faithfully passed that partial data along. No alert. No flag. No governance event.
Silent failures at seams are the most dangerous because they look like success. Every system reports healthy. Every action logged. The failure only surfaces weeks later when a human catches the downstream consequence.
When an outcome involves five systems, accountability diffuses. The CISO asks “how did this happen?” and gets five vendor-specific answers that each explain their piece but none explain the whole. The incident response becomes a forensic exercise in stitching together five audit trails that were never designed to correlate.
The EU AI Act (Article 14) requires human oversight of high-risk AI systems. But which system in the Frankenstein stack is “the AI system”? The governance tool? The autonomous agent? The automation platform that orchestrated the workflow? When regulators ask “who was responsible for this AI decision?”, the answer can’t be “five vendors, collectively, sort of.”
Beyond governance gaps, the Frankenstein stack imposes a compounding maintenance burden:
Custom integrations between every layer. Each connection between vendors is a custom integration — API calls, data transformations, authentication handshakes. When any vendor updates their product, the integrations can break. A team of engineers whose full-time job is keeping the stitches intact.
Version coupling. When the governance vendor releases a new API version, does the automation platform still connect? When the RPA vendor changes their bot execution model, does the orchestration layer still trigger correctly? Every vendor moves at their own pace, and the enterprise absorbs the coordination cost.
Testing the whole stack. Each vendor tests their own product. Nobody tests the assembled stack end-to-end. The enterprise has to build and maintain integration test suites that span all five systems — or accept that they’re flying without a net at the seams.
Research consistently shows that integration costs consume a disproportionate share of enterprise IT budgets. When the integration is between five AI/automation vendors — each with their own data models, authentication schemes, and governance assumptions — the cost compounds.
The instinct is to put the governance vendor in charge of the seams. “That’s what we bought them for — govern everything.”
But governance tools are designed to monitor AI behavior within their configured scope. They observe model outputs, flag anomalies, generate compliance reports. They’re not designed to:
A governance tool monitoring the Frankenstein stack from the outside is like a security camera watching a building with five different lock systems — it can record what happens, but it can’t prevent a failure that occurs in the handshake between two systems it doesn’t control.
The seam problem disappears when there’s one system instead of five.
When the same platform that orchestrates the workflow also:
…there are no seams. No handoffs between vendors. No context loss at boundaries. No silent failures in custom integrations. No accountability gaps when something goes wrong.
One execution path means one audit trail. One governance layer means every action — whether it’s an AI decision, a document extraction, a legacy system interaction, or a human approval — is evaluated through the same policy engine with the same context.
The AI Dial works because it’s one dial for the whole system, not five dials for five systems that nobody calibrates together.
If you’re assembling — or have already assembled — a Frankenstein stack, here are the questions worth asking:
Who owns the seams? Not who owns each tool — who owns the spaces between them? Who’s accountable when a failure crosses vendor boundaries?
Can you reconstruct a decision end-to-end? If a customer complaint leads to a regulatory inquiry, can you show the full decision chain — from initial data to final action — in a single, coherent audit trail? Or do you need to stitch together five vendors’ logs?
What’s your integration maintenance budget? Not the vendor licenses — the engineers keeping the connections alive. That number tends to grow faster than anyone expects.
Is the assembled stack simpler than a unified platform would be? Five vendors, each simple individually, can produce a system that’s far more complex than one platform that handles multiple layers. Complexity hides at the boundaries.
The Frankenstein stack looks rational in procurement — each vendor won their category evaluation. But the system-level costs — governance gaps, integration tax, accountability diffusion, silent seam failures — often exceed the cost of any individual vendor.
The question isn’t whether each tool is good at its job. It’s whether five good tools make a good system.
This is Part 7 of an 8-part series on The Frankenstein Stack. Next: One Platform, One AI Dial.
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:
In the previous articles, I examined tools that don’t do enough — governance platforms that only monitor, RPA that only executes scripts, automation tools that only move data between connectors.
Now let’s look at the opposite problem: AI that does too much, too freely.
The autonomous agent movement — OpenClaw, Perplexity Computer, frameworks like CrewAI and AutoGen — represents a fundamentally different philosophy. Instead of tools that require human orchestration, these are AI systems designed to act independently. Navigate websites. Execute code. Make decisions. Take actions.
The capability is real. The governance is not.
OpenClaw exploded onto the scene as an open-source autonomous AI agent platform. Over 160,000 developers gave it access to their systems — root-level access, in many cases. The agent could browse the web, execute code, manage files, and interact with services autonomously.
Then its creator, Peter Steinberger, joined OpenAI. The move validated the autonomous agent thesis — if OpenAI wanted the person who built this, the paradigm clearly mattered.
But the validation came with a question nobody was answering: who governs what these agents do?
OpenClaw had 15+ messaging adapters, broad integration support, and an active community. What it didn’t have was:
It was a switch, not the AI Dial. And the switch was stuck on “full auto.”
For developers experimenting on their laptops, this was fine. For enterprises considering deploying autonomous agents in production — handling customer data, making financial decisions, interacting with external services — “full auto with no governance” is a non-starter.
Perplexity started as an AI search engine — a better way to find and synthesize information. But their “Computer” product crossed a significant line: from answering questions to taking actions.
AI that searches for information is relatively low-risk. AI that navigates your browser, fills out forms, clicks buttons, and executes transactions on your behalf is fundamentally different. The blast radius of a wrong answer in search is “I read incorrect information.” The blast radius of a wrong action in computer use is “AI submitted a form with incorrect data to a government agency” or “AI purchased something I didn’t authorize.”
Perplexity Computer represents the broader trend of AI breaking out of the chat box and into the operating system. Anthropic’s computer use, Google’s Project Mariner, and similar initiatives are all pushing in the same direction: AI that doesn’t just advise but acts.
The capability is impressive. But the governance model for most of these is essentially: the user watches the screen and hopes the AI does the right thing.
That’s not governance. That’s supervision by a human who can’t process information as fast as the AI acts.
Beyond individual products, an entire ecosystem of agent frameworks has emerged:
CrewAI — Multi-agent orchestration where specialized AI agents collaborate on tasks. Each agent has a role, a goal, and tools. The framework handles agent-to-agent communication. What it doesn’t handle: enterprise-grade governance over what each agent decides and does.
AutoGen (now AG2) — Microsoft’s multi-agent conversation framework. Agents negotiate, plan, and execute through structured dialogues. Powerful for complex reasoning tasks. But the governance model is coded into each conversation — there’s no centralized policy engine that evaluates every action before it executes.
LangChain / LangGraph agents — The most widely adopted framework for building AI agent applications. Rich tooling, massive ecosystem. But governance is DIY — every team implements their own approval logic, their own audit trails, their own escalation paths. There’s no built-in AI Dial.
The common pattern across all of these: the frameworks optimize for capability, not for governed capability.
Agent Frameworks: Capability vs. Governance
| Framework | Capability | Governance | Quadrant |
|---|---|---|---|
| CrewAI | High | Low | High capability, low governance |
| AutoGen AG2 | High | Low | High capability, low governance |
| LangChain | High | Low | High capability, low governance |
| Perplexity Computer | Very High | Low | High capability, low governance |
| OpenClaw | High | Low | High capability, low governance |
| Enterprise need | High | High | Where enterprises need to be |
Every framework is in the top-left quadrant: high capability, low governance. Enterprises need the top-right.
The instinct when looking at these frameworks is: “We’ll use CrewAI/LangChain for the agents, then add our governance tool on top.”
This is the Frankenstein pattern again. And it fails for the same reasons bolt-on data quality failed:
The speed problem. Autonomous agents make decisions in milliseconds. A governance layer monitoring from outside can’t evaluate and intervene faster than the agent acts. By the time the monitoring tool flags an issue, the agent has already sent the email, submitted the form, or made the API call. Governance needs to be in the execution path, not observing from the outside.
The context problem. An external governance tool sees what the agent did — but not why. What data did it consider? What alternatives did it evaluate? What confidence level did it have? Without that context, governance becomes pattern-matching on outputs: “this looks unusual, flag it.” When governance is inline, the context travels with the decision.
The scope problem. The governance vendor monitors the AI tools it knows about. But autonomous agents are designed to discover and use new tools at runtime — self-extending into services, APIs, and websites that didn’t exist when the governance tool was configured. How do you monitor an agent that’s accessing a service you don’t even know it connected to?
The autonomy problem. These frameworks have one mode: autonomous. There’s no mechanism to say “handle Tier 1 tasks autonomously but escalate Tier 2 for human review.” There’s no AI Dial — no graduated autonomy that matches different trust levels to different task types. It’s full auto or you don’t use agents.
Enterprise AI leaders face a genuine dilemma:
The autonomous agent paradigm is real and valuable. AI that can research, plan, and execute multi-step tasks — navigating systems, processing documents, making decisions — is the future of enterprise operations. Denying this is like denying the internet in 1998.
But deploying these agents in production without governance is reckless. A customer service agent that autonomously resolves complaints is powerful — until it offers a $10,000 refund on a $100 order because it optimized for customer satisfaction without a policy boundary. A financial agent that processes transactions is efficient — until it executes a trade that violates compliance rules because nobody defined the guardrails.
The question isn’t whether to use autonomous agents. It’s how to use them with the right level of human involvement for the right tasks at the right time.
That’s the AI Dial — graduated autonomy per task, per agent, per workflow. Some agents at full autonomy for low-risk, well-understood tasks. Some agents at supervised autonomy for higher-risk decisions. Some tasks always requiring human approval.
But most agent frameworks don’t give you the AI Dial. They give you a switch. And if the enterprise flips that switch to “full auto” without the governance infrastructure to match, we get the Zillow story again — at scale, across every department, with AI agents that are faster and more confident than any algorithm Zillow ever deployed.
The autonomous agent movement got the capability right. AI should act, not just advise. The work should get done.
What’s missing is the orchestration layer that governs how agents act:
This isn’t about limiting what agents can do. It’s about creating the infrastructure that lets enterprises actually deploy them — at scale, in production, with the confidence that the AI Dial is set to the right position for every task.
Without that infrastructure, autonomous agents remain a developer tool — impressive in demos, too risky for production.
This is Part 6 of an 8-part series on The Frankenstein Stack. Next: Who Governs the Seams?.
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:
Zapier boasts over 7,000 app integrations. Make (formerly Integromat, acquired by Celonis for ~$1.45 billion) has 1,500+. n8n, the open-source alternative, has 400+ nodes and growing.
These are impressive numbers. They’re also the wrong metric.
The number of connectors tells you how many apps the platform can connect to. It tells you nothing about what the platform can think about. And that’s the gap that connector catalogs are trying to close with “AI features” — and failing.
Zapier, Make, and n8n share the same fundamental architecture: trigger → action chains. Something happens in App A (trigger), the platform moves data to App B (action). You can chain multiple steps, add filters and conditional logic, and build surprisingly complex workflows.
But the intelligence in these workflows is entirely pre-defined by the human who built them. The workflow doesn’t understand what it’s doing. It doesn’t make decisions. It doesn’t handle exceptions it wasn’t programmed for. It moves data along a path that a human mapped in advance.
| Step | Type | What Happens |
|---|---|---|
| 1 | Trigger | New email arrives |
| 2 | Filter | If subject contains “invoice” |
| 3 | Action | Extract attachment |
| 4 | Action | Send to Google Sheets |
| 5 | Action | Notify in Slack |
This is a pipeline. It moves data. It doesn’t understand the data. It doesn’t make decisions. It doesn’t govern itself. When it fails, it stops.
This architecture is powerful for well-structured, predictable workflows. Move new leads from Typeform to Salesforce. Post new blog entries to Twitter. Sync calendar events between platforms.
It breaks down when the workflow requires intelligence — understanding context, making judgment calls, handling the unexpected, governing consequential actions.
Every connector catalog is rushing to add AI. Zapier has “AI actions” and an AI chatbot builder. n8n has AI nodes for LLM calls, text classification, and embeddings. Make has AI scenarios.
But adding an AI node to a connector catalog is like putting a jet engine on a bicycle. The AI node can do something intelligent at one step in the chain — summarize text, classify an email, extract entities — but the workflow architecture around it is still a rigid, pre-defined pipeline.
The AI doesn’t orchestrate the workflow. The workflow orchestrates the AI. The AI is a tool in the pipeline, not the intelligence driving it.
Here’s the difference:
AI as a node in a connector catalog: “When a new email arrives, use GPT to classify it as billing/support/sales, then route it to the right Slack channel.”
The human designed the routing logic. The AI just classifies. If the email doesn’t fit the three categories, the workflow breaks or routes to a default. No judgment. No escalation. No governance.
AI-native orchestration: “When a new customer interaction arrives — from email, WhatsApp, web chat, or phone — understand the intent, assess the complexity, check the customer’s history, determine whether to resolve autonomously or escalate based on the configured autonomy level for this interaction type, execute the resolution within governed boundaries, and log the full decision chain.”
The AI is the orchestration. It understands context, makes decisions, handles exceptions, and operates within governance guardrails. The workflow adapts to the situation rather than following a rigid path.
That’s the difference between a connector catalog with AI features and an AI-native orchestration platform. It’s not about the number of integrations. It’s about whether intelligence is a feature of the pipeline or the architecture of the system.
Zapier’s business model tells the connector catalog story clearly. They charge based on “tasks” — essentially, the number of times data moves through a workflow step. More volume, higher cost.
In 2023-2024, Zapier restructured pricing in ways that drew significant user backlash — removing features from lower tiers and increasing costs. The community response was vocal: for enterprises with high-volume workflows, the task-based pricing becomes expensive quickly.
But the deeper problem isn’t the price — it’s what you’re paying for. You’re paying per data movement. Per pipeline execution. Per trigger-action step. The cost scales with volume, but the intelligence doesn’t scale at all. Running the same rigid workflow a million times costs a million times more but delivers zero additional insight.
An AI-native platform doesn’t charge per data movement because the value isn’t in moving data — it’s in making decisions. Processing a million customer interactions where 600,000 are resolved autonomously, 300,000 are resolved with human review, and 100,000 are escalated — all governed by the AI Dial — is fundamentally different from running a million identical trigger-action chains.
n8n deserves separate mention because its architecture is genuinely better than Zapier’s for complex workflows. It’s self-hostable (important for data-sensitive enterprises), developer-friendly, and capable of sophisticated branching and error handling. The community is strong and the tool is popular for AI-adjacent workflows — chaining LLM calls, processing documents, building agent-like sequences.
But n8n is still a workflow execution engine, not an AI orchestration platform. The AI nodes are nodes in a workflow — tools you wire up, not intelligence that drives the process. And governance is entirely absent: no approval workflows, no audit trails for compliance, no configurable autonomy levels, no AI Dial.
For developers building AI prototypes and internal tools, n8n is excellent. For enterprises that need governed AI orchestration across production systems — with compliance, audit trails, and graduated autonomy — it’s a starting point that requires significant custom development to become production-ready.
We actually integrate with n8n — our platform adapter was tested live against a real n8n instance, 6/6 tests passing. n8n is a good workflow engine. But a workflow engine is one component of what enterprises need, not the complete solution.
The gap in connector catalogs isn’t the number of connectors. It’s four capabilities that are absent from the architecture:
AI should determine the path, not just execute a step in a pre-defined path. When an exception occurs, the system should decide how to handle it — not fail and create a support ticket. When context matters, the system should use it — not ignore it because the workflow was designed for the average case.
Consequential actions — approving a refund, sending a customer communication, updating a financial record — need governance. Not a separate governance tool monitoring from outside. Inline evaluation: should this action proceed? Does it require approval? At what autonomy level is this workflow operating?
Connector catalogs have zero governance. Every action in the pipeline executes without evaluation. There’s no mechanism to say “auto-approve under $500, require manager approval over $500” — because the platform doesn’t have a concept of governed action.
Different workflows need different autonomy levels. A lead routing workflow might be fully automated. A customer complaint resolution workflow might require human review at certain steps. A financial processing workflow might need approval for transactions above a threshold.
Connector catalogs offer one mode: automated. The workflow runs or it doesn’t. There’s no graduated autonomy, no per-step configuration, no ability to increase or decrease human involvement based on the situation.
When the app you need isn’t in the catalog, you wait. Zapier adds integrations based on demand. n8n depends on community contributions. Make adds to their marketplace over time.
An AI-native platform doesn’t wait. Self-extending agents can research an API, generate an integration, validate it, and activate it — in minutes. Browser automation can interact with any web application that has a URL. The integration ceiling doesn’t exist.
If your organization is using Zapier, Make, or n8n — or evaluating them — they might be the right fit for simple, well-structured automations between mainstream apps. Not everything needs AI-native orchestration.
But ask these questions:
Do your workflows need to make decisions? If the workflow encounters an exception, does it need intelligence to handle it — or is “fail and create a ticket” acceptable?
Do your workflows need governance? If the workflow processes financial data, customer information, or compliance-relevant actions, does someone need to approve, audit, or configure the autonomy level? Connector catalogs can’t do this.
Are you hitting the integration ceiling? If you need to connect to an internal tool, a niche SaaS product, or a legacy system without a connector — are you waiting months for the integration to appear? Or do you need it now?
What’s the total cost? The connector catalog plus the AI tools you added for intelligence plus the RPA for legacy systems plus the governance tool for compliance. That assembled stack might cost more — and deliver less — than a single platform that handles orchestration, intelligence, governance, and reach in one layer.
The connector catalog solved the problem of connecting apps. The next problem — AI-native orchestration with governance — requires a different architecture, not more connectors.
This is Part 5 of an 8-part series on The Frankenstein Stack. Next: Autonomous Agents Without Guardrails.
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:
Microsoft Copilot for M365 costs $30 per user per month — on top of existing Microsoft 365 licensing. For a 1,000-person enterprise, that’s $360,000 per year for AI that drafts emails, summarizes meetings, and generates PowerPoint slides.
The early results were mixed. Bloomberg reported that some enterprise customers pulled back after initial pilot phases, reducing seat counts rather than expanding. CIO surveys showed satisfaction below expectations. The pattern: impressive in demos, underwhelming in daily use for many tasks, and difficult to justify the ROI at $30/seat when the productivity gains were incremental.
This isn’t a Copilot-specific problem. Google Gemini for Workspace faces similar challenges — lower adoption, similar quality concerns, and a smaller enterprise installed base. ChatGPT Enterprise has hundreds of thousands of users but remains primarily a chat interface — powerful for individual tasks, limited for business process orchestration.
The AI assistant category isn’t failing. But it’s hitting a ceiling that no amount of feature updates can fix — because the ceiling is architectural.
Credit where it’s due. AI assistants are genuinely useful for individual productivity:
BCG’s research confirmed the pattern: AI assistants deliver real productivity gains — 10-20% for specific tasks — particularly for knowledge workers doing repetitive content creation and information synthesis.
The problem isn’t what they do. It’s what they can’t do.
AI assistants help individuals with individual tasks. They don’t orchestrate multi-step business processes across systems.
Here’s the gap:
What Copilot can do: Draft an email summarizing a customer complaint, pull data from a SharePoint document, suggest a response template.
What Copilot can’t do: Receive the complaint from WhatsApp, pull the customer’s history from the CRM, check the return policy in the knowledge base, draft the response, route it for manager approval if the refund exceeds $500, execute the refund in the billing system, update the CRM, and send the confirmation — all as one governed workflow.
That second scenario is what enterprises actually need. It’s not individual task assistance. It’s multi-system, multi-step orchestration with governance at every decision point.
| AI Assistance (Copilot, Gemini, ChatGPT) | AI Orchestration | |
|---|---|---|
| Scope | One user + one task + one system | Multi-step process + multiple systems + governance |
| Who drives | Human initiates every action | AI initiates, executes, and manages the workflow |
| Boundaries | AI helps within the application | Crosses application boundaries |
| Governance | No governance beyond vendor guardrails | Inline governance at every decision point |
| Autonomy | Vendor-controlled | The AI Dial: configurable autonomy per step |
| Value | 10-20% productivity on individual tasks | Entire processes automated end-to-end |
The ceiling: No amount of Copilot features bridges this gap. Assistance and orchestration are different architectures.
McKinsey’s 2024 global survey found that 72% of organizations had adopted AI in at least one function — but most usage was at the individual task level, not embedded in processes. The ceiling is visible in the data: organizations adopt AI assistants quickly, then stall when trying to move from individual productivity to process transformation.
The second ceiling is vendor lock-in. Each AI assistant lives inside its vendor’s ecosystem:
Microsoft Copilot works across Word, Excel, PowerPoint, Outlook, Teams, and SharePoint. Impressive breadth — within Microsoft. But your CRM might be Salesforce. Your project management is Jira. Your financial system is NetSuite. Your customer support is Zendesk. Copilot can’t orchestrate across these boundaries.
Google Gemini for Workspace works across Gmail, Docs, Sheets, Slides, and Meet. Same story, different ecosystem. Even less enterprise penetration than Microsoft.
ChatGPT Enterprise is ecosystem-agnostic but interaction-limited. It’s a chat interface. It can help you think and draft, but it doesn’t connect to your business systems, trigger workflows, or execute multi-step processes.
The enterprise doesn’t live in one vendor’s ecosystem. It lives across 300-400+ SaaS applications (per Productiv and Zylo SaaS management data). An AI assistant that only works inside one vendor’s suite is helpful for tasks within that suite. It’s irrelevant for cross-system business processes.
This is the Frankenstein stack contribution of AI assistants: they handle one layer (individual productivity within one ecosystem) but force the enterprise to add other tools (automation platforms, RPA, custom integrations) for everything else. The AI assistant becomes one more tool in the stack, not a replacement for the stack.
The third ceiling is governance. With AI assistants, governance is whatever the vendor decides it should be.
Microsoft determines what Copilot can and can’t do. Google determines Gemini’s guardrails. OpenAI sets ChatGPT Enterprise’s usage policies. The enterprise has limited ability to customize these guardrails to their specific compliance requirements, risk tolerance, or industry regulations.
For example:
The AI Dial — configurable, per-task, per-department autonomy that adjusts over time — doesn’t exist in the AI assistant model. The vendor sets the dial position. You get what you get.
For regulated industries — financial services, healthcare, insurance — this is a fundamental problem. The EU AI Act requires enterprises to maintain human oversight mechanisms that they control. Relying on a vendor’s built-in guardrails, which the enterprise can’t audit or customize, may not satisfy regulatory requirements.
Many enterprises hit the AI assistant ceiling and respond by adding an automation platform — Zapier, n8n, Make — to bridge the gap. Copilot handles the individual tasks. The automation platform handles the cross-system workflows.
This is the Frankenstein stack assembling itself in real time:
Each addition is logical in isolation. Together, they create the five-vendor, five-audit-trail, five-governance-story stack from Part 1 of this series.
The root cause: the AI assistant was never designed to be an orchestration platform. It was designed to help individuals within one vendor’s ecosystem. When the enterprise needs more — cross-system workflows, graduated governance, multi-step processes — the AI assistant doesn’t scale up. The enterprise scales out, adding tools.
If your organization is using AI assistants — or evaluating expansion — here are the questions:
What percentage of your AI use is individual tasks vs. process orchestration? If most of your value comes from “draft this email” and “summarize this meeting,” the AI assistant is working. If you need “process this claim end-to-end across four systems with governance,” you’ve hit the ceiling.
What happens when you need to cross ecosystem boundaries? Can the AI assistant trigger actions in your CRM, your billing system, your legacy apps? Or do you need another tool for that? Every additional tool is another layer in the Frankenstein stack.
Who controls the governance? Can you set different autonomy levels for different departments? Can you require approval workflows for high-risk AI actions? Can you audit the AI’s reasoning? If the vendor controls all of this, your governance is someone else’s product decision.
What’s the total stack cost? Not just $30/seat for Copilot — the full cost including the automation platform you added to bridge the gaps, the RPA you kept for legacy systems, and the governance tool you bought to monitor everything. That total is the real cost of the AI assistant ceiling.
The AI assistant isn’t the problem. It’s a good tool for individual productivity within a single ecosystem. The problem is expecting it to be the enterprise AI strategy when it was never designed for orchestration, governance, or cross-system automation.
This is Part 4 of an 8-part series on The Frankenstein Stack. Next: Connector Catalogs Are Not AI Platforms.
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:
UiPath went public in April 2021 at $56 per share, peaked near $90, and has since collapsed to the $12-20 range. The company that was supposed to be the future of enterprise automation lost over 80% of its peak market value.
The stock tells a story the RPA marketing won’t: the model is struggling.
UiPath’s founder Daniel Dines stepped down as CEO in mid-2023. His replacement, Rob Enslin, lasted roughly six months before departing. Dines returned to a company that was already pivoting away from the very category it created — rebranding from “Robotic Process Automation” to “AI-powered automation.”
When the market leader is running from its own category name, the category has a problem.
Strip away the marketing and RPA does one thing: scripted screen interaction. A bot watches what a human does — click here, type this, copy that, paste there — and replays those actions. It’s sophisticated macros. Record the steps, run them on a schedule, handle the simple exceptions.
For structured, repetitive, high-volume tasks — data entry, report generation, invoice processing with consistent formats — this works. It works well enough that UiPath, Blue Prism, and Automation Anywhere built a multi-billion dollar market on it.
But the limitations are inherent to the architecture:
Brittle by design. RPA bots interact with user interfaces. When the UI changes — a button moves, a field is renamed, a page layout updates — the bot breaks. Industry estimates suggest 20-40% of total RPA program cost goes to bot maintenance. Deloitte and others have reported that many enterprises stall at 50-100 bots because the maintenance burden grows faster than the value delivered.
No intelligence. An RPA bot follows a script. It doesn’t understand what it’s doing, can’t handle exceptions it wasn’t programmed for, and can’t adapt when conditions change. If an invoice arrives in an unexpected format, the bot fails. If a customer request doesn’t match the predefined categories, the bot fails. If the legacy system responds slower than expected, the bot may fail silently — returning partial data without flagging the issue.
No governance. RPA bots execute without governance guardrails. There’s no inline evaluation of whether an action should proceed. No approval workflow before a bot submits a form or processes a payment. No AI Dial — it’s fully automated or off. The governance tool in the Frankenstein stack doesn’t typically monitor RPA actions because RPA isn’t an “AI system” in the governance vendor’s taxonomy.
Expensive at scale. License costs per bot, infrastructure to run bots, center of excellence teams to manage bots, developers to fix broken bots, governance teams to audit bot actions. Multiple analyst reports have cited that 30-50% of initial RPA projects fail to meet ROI expectations.
RPA is being squeezed by two forces simultaneously:
Microsoft Power Automate is bundled with Microsoft 365. For enterprises already on M365 — which is most of them — basic automation is effectively free. Why pay UiPath per-bot licensing for simple task automation when the productivity suite you already own includes it?
Power Automate isn’t as capable as UiPath for complex RPA scenarios. But for the 60-70% of RPA use cases that are simple data movement and form filling, it’s good enough. And “good enough plus free” beats “better but expensive” every time.
AI fundamentally changes what automation can do. Instead of scripting screen interactions step by step, AI can:
This isn’t hypothetical. Browser automation powered by AI (Playwright, similar frameworks) can navigate any web application — the same legacy systems RPA bots interact with — but with intelligence. The AI understands what it’s looking at, not just where to click.
RPA vs. AI-Powered Automation
| Dimension | RPA | AI-Powered |
|---|---|---|
| Interaction model | Scripted clicks | Contextual navigation |
| Document handling | Template-based | Format-agnostic |
| Exception handling | Fails or skips | Makes judgment calls |
| UI changes | Bot breaks | AI adapts |
| Maintenance | 20-40% of cost | Self-healing |
| Intelligence | None | AI-native |
| Governance | None built-in | Inline (AI Dial) |
| New integrations | Custom development | AI generates adapter |
Bottom line: RPA automates clicks. AI-powered automation automates work.
Blue Prism — once positioned as the “enterprise RPA” alternative to UiPath — was acquired by SS&C Technologies in March 2022 for approximately $1.6 billion. SS&C is a financial services technology conglomerate. Blue Prism became one product in a large portfolio.
The significance: a pure-play RPA company couldn’t sustain independence. It was absorbed into a larger entity where RPA is a feature, not the product. This is the trajectory of technologies that become commoditized — they don’t die, they get absorbed into platforms.
Automation Anywhere, the other major RPA pure-play, has been privately held and reportedly evaluating an IPO for years without executing. Meanwhile, it’s pivoting messaging to “AI + Automation” — distancing from “RPA” the same way UiPath is.
When all three major RPA vendors are either losing value (UiPath), absorbed (Blue Prism), or pivoting away from the category name (Automation Anywhere), the market is sending a clear signal.
Here’s the Frankenstein stack problem specific to RPA: RPA bots are ungoverned.
The AI governance tool (Credo AI, Arthur AI, etc.) monitors AI models — LLMs, ML classifiers, recommendation engines. It doesn’t monitor RPA bots because they’re not “AI” in the governance vendor’s taxonomy.
But RPA bots are making consequential decisions every day. They’re processing payments, updating customer records, filing regulatory documents, extracting data from systems. These actions have real business impact — and they’re executing without:
The governance tool watches the AI. The AI assistant has Microsoft’s guardrails. But the RPA bot? It runs its script, and nobody in the governance architecture is watching.
This is the seam problem from Part 7 of this series — risk lives in the gaps between systems, and the RPA layer is entirely in the gap.
If your organization uses RPA today — or is evaluating it — here are the questions that matter:
What’s your actual maintenance cost? Not the license fee — the total cost including developers fixing broken bots, the center of excellence overhead, and the business impact when bots fail silently. Most enterprises dramatically undercount this.
What happens when the UI changes? If the answer is “a developer fixes the bot,” multiply that by every application your bots touch, and ask how often those applications update. That’s your ongoing maintenance liability.
Can your bots handle exceptions? Not the exceptions you’ve pre-programmed — the ones you haven’t anticipated. What happens when the input doesn’t match the template? When the system responds differently? When data is incomplete? If the answer is “the bot fails and creates a ticket,” you’re paying for automation that regularly creates manual work.
Is your RPA governed? Does anyone audit what the bots are doing? Is there an approval workflow before a bot processes a payment or updates a customer record? Can you reconstruct why a bot took a specific action? If the AI governance tool doesn’t monitor RPA, you have an ungoverned automation layer in your stack.
Could AI-powered automation do this better? For each RPA workflow, ask: would an intelligent system that understands context, adapts to changes, handles exceptions, and has governance built in — deliver better results at lower maintenance cost?
The answer isn’t always yes. There are high-volume, perfectly structured tasks where scripted automation still makes sense. But for the growing majority of enterprise processes that involve variability, judgment, and multiple systems — RPA is a solution from a previous era being maintained past its useful life.
RPA won’t disappear overnight. There are millions of bots running in production, and enterprises won’t rip them out tomorrow. But the trajectory is clear:
Simple automations are being absorbed by platform-native tools (Power Automate, built-in workflow features in SaaS applications). No need for a separate RPA license.
Complex automations are being replaced by AI-powered approaches — browser automation with intelligence, document understanding that doesn’t need templates, workflow orchestration that handles exceptions.
The governance gap is being addressed by platforms that govern all actions inline — whether those actions are AI decisions, document processing, browser interactions, or API calls. One governance layer. One AI Dial. Not a separate governance tool that monitors some systems and ignores others.
The enterprises that get ahead of this curve won’t be the ones adding more bots. They’ll be the ones replacing brittle scripts with intelligent automation that governs itself — and reducing their Frankenstein stack by one vendor in the process.
This is Part 3 of an 8-part series on The Frankenstein Stack. Next: Your AI Assistant Has a Ceiling.
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:
Jensen Huang, CEO of Nvidia — the company that makes the chips powering most AI — says the opposite: every past technology has brought more prosperity. Andy Jassy, CEO of Amazon, says replaced jobs will create new ones.
I’ve been building AI systems for nine years. I hold multiple patents. I’ve shipped AI into healthcare, finance, logistics, and retail. And I think both sides are wrong — because they’re both talking about someone else’s problem.
Schulman runs Verizon. 100,000 employees. $20 million retraining fund. His AI conversation is about how to restructure a giant enterprise without breaking society.
That is not your conversation if you’re running a 12-person accounting firm, a dental practice, a logistics company with three dispatchers and a warehouse.
Your conversation is simpler and more urgent: if you don’t figure out how to use AI soon, your competitor who does will eat your lunch. Not because they’re smarter. Because five people using AI right are doing the work of fifty.
The media is giving you two choices:
Option A: AI takes everyone’s jobs. Schulman’s version. Prepare for mass unemployment. Hope your government handles retraining. Brace for the backlash.
Option B: AI creates more jobs than it destroys. Jensen’s version. Relax. Prosperity is coming. Technology always works out.
Neither of these helps the owner of a 20-person business trying to decide whether to let their office manager use ChatGPT to draft client emails.
There is a third option nobody in the C-suite of a Fortune 100 company is talking about:
Option C: Use AI to multiply the team you already have. Safely. With humans in control at every step.
Not replacing your people. Multiplying them.
I wrote about this in detail a few weeks ago: a team of 5 doing the work of 50 by having AI handle the routine — scheduling, data entry, first-draft communications, status reporting — while humans focus on judgment, relationships, and the work that actually grows revenue.
The math is real. Across five typical roles in a small business, we found 51 hours per week of repetitive work that follows the same pattern every time. That’s more than an entire FTE consumed by tasks that AI can do at dial-speed.
Candor.
He’s right that too many CEOs are pretending AI is a pure upside. The 55% of Americans who told Quinnipiac that AI will bring “more harm than good” aren’t wrong to be anxious. They’re watching companies cut tens of thousands of jobs while their CEOs talk about “unlocking new levels of growth.”
Schulman is saying: tell the truth. That matters.
But here’s what he’s missing: the truth for a small business is fundamentally different than the truth for Verizon.
Verizon can afford a $20 million career-transition fund. You can’t.
Verizon can hire an AI strategy team. You don’t have one.
Verizon can absorb the risk of getting AI adoption wrong. For you, one bad AI mistake — a wrong invoice, a leaked client file, a hallucinated legal citation — could cost you a customer you can’t afford to lose.
The thing that’s missing from both Schulman’s warning and Jensen’s optimism is the mechanism.
How do you actually adopt AI without either:
The answer is a dial, not a switch.
Watch — AI observes and shows you what it could do. You learn what it’s good at.
Suggest — AI drafts. You decide everything. You build confidence in its judgment on specific tasks.
Act with approval — AI does the work and waits for your sign-off. You catch the 2% that’s wrong.
Handle routine — AI runs the stuff it’s proven it can handle. You focus on exceptions and growth.
You move up when the AI earns your trust on a specific task. You move back down any time. Every action is logged. Every decision has a human in the loop or a human who chose to remove themselves from the loop after seeing enough evidence.
This isn’t theoretical. This is how our platform works. This is what “governed AI” means in practice: not a policy document, but a mechanism that matches AI autonomy to demonstrated competence.
If you’re running a small business, here is the honest version of the Schulman talk:
AI will change your industry. Not 20-30% unemployment, but the businesses that use AI well will outperform those that don’t. That gap is already opening.
Your people are your advantage. They know your customers, your processes, your market. AI doesn’t replace that knowledge. It multiplies it — if you give it the right structure.
The risk isn’t AI. The risk is uncontrolled AI. Staff using ChatGPT with client data. Automations running without oversight. AI tools making decisions you didn’t approve. That’s what creates the horror stories. Governed AI — with the dial, with approval gates, with audit logs — eliminates those risks.
Start this week. Pick one workflow. The most repetitive, most time-consuming, lowest-judgment task in your business. Set the dial to “suggest.” Let AI draft. Your team reviews. See what happens.
You don’t need a $20 million retraining fund. You need a safe first step.
Schulman is half right. CEOs should be honest about AI disruption. Full stop.
But the other half of the truth — the half that matters to the 33 million small businesses in America — is that AI isn’t coming for your people. It’s coming for the businesses that don’t learn to use it.
The question isn’t “will AI take jobs?” The question is: will your business multiply, or will it fall behind?
That answer is in your hands. And the dial is right there.
Related reading:
]]>