AI-Native Organizations: Buy or Build? Business Trade-offs Across the General Layer, Industry Layer, and Proprietary Layer

A Company’s FOMO

On Friday afternoon, the boss dropped a news link into the company group chat—100,000 Store Domains Connected to AI Agents with One Click—noting that a platform had enabled in-browser agent tool calling by default across nearly 100,000 store domains, allowing agents to invoke site features directly unless a merchant manually opted out. In the previous article, we unpacked the mechanism behind this: the platform can inject tools into 100,000 storefront pages without touching a single line of the merchants’ existing code. The boss tagged the tech lead and the product manager in the chat, asking when the company’s own business could become AI-native. To the boss, going AI-native is first and foremost a customer acquisition calculation: just as the entry point for customers finding services once shifted from search engines to app stores, it is now shifting toward conversational interfaces and in-browser agents, and every entry-point migration forces a recalculation of customer acquisition costs. The boss worries that competitors will be the first to take orders at this new entry point while the company’s own services remain invisible to external agents. Put on the spot, the tech lead and management team felt the pressure too—afraid of falling behind peers if they did nothing, yet unsure which layer of the stack deserved the budget if they acted. With Monday’s regular meeting looming and a decision expected, everyone’s instinctive reaction was to build something visible first just to test the waters.

To show results as quickly as possible, engineers spent half a day turning on the public interfaces bundled with their platform. Using a test agent to read the public product catalog, store locations, and FAQs from the official website, the team recorded a demo video and posted it to the weekly meeting group—making it look as though they had achieved an AI-native setup. Yet the platform’s default switch was only ever meant for reading public pages and searching keywords, whereas real business operations are tied to the API limits of legacy internal systems, role-based permission boundaries, compliance approvals, and state mutations. Put into daily operations, this demo falls apart immediately: when a returning customer checks annual contract pricing with tiered rebates, updates the shipping address on an order already in sorting, or verifies industry qualification credentials for a service, every request must connect back to internal systems and approval workflows—where an external agent, lacking both permissions and interfaces, stalls on the spot. Simply checking a default box in the admin console cannot solve any of these problems.

After hitting that wall, a team can easily swing to the opposite extreme. The tech lead and architects drafted an annual architecture proposal to build an in-house multi-protocol translation layer, cross-site agent authentication, and key exchange mechanisms, topped off with a custom multi-turn conversation state foundation. The company was already short-staffed and weighed down by a tangle of brittle legacy systems. Several core engineers were pulled off day-to-day feature work and spent over half a year heads-down, burning through a substantial chunk of the R&D budget. Just as the underlying protocols and conversation state engine finally started working—and before they had even been wired into a couple of real business workflows—cloud providers and website builders rolled out those exact general capabilities the following year as free, standard features for every merchant. Over half a year of hard work turned overnight into unmaintained duplicate infrastructure, while the internal approvals and legacy system interfaces that were actually bottlenecking the business remained untouched.

Looking at these two false starts side by side, management and tech leads realize they do not have to choose between flipping a default switch and building everything from scratch; beyond those two detours lies a third path: buying industry components that come packaged with domain rules and assembly instructions, and letting AI assemble them into the company’s own business workflows. In the past, teams argued over whether to buy or build the moment a requirement landed because they tried to apply a single approach to the entire problem before separating which layer of the business actually needed to change. To decide how the company will become AI-native, the boss and the tech lead must first break business capabilities down into the General Layer, the Industry Layer, and the Proprietary Layer, and then decide for each layer whether to use, buy, or build. Once that sequence is straightened out, Monday’s meeting stops being a mutual pressure session over timelines and becomes an exercise in splitting requirements across the three layers, choosing the right acquisition mode for each, and laying out a schedule with clear return on investment.

Why Buy vs. Build Is No Longer Enough: What Software Vendors Deliver Has Changed

When handed a requirement for agent integration, management and engineering teams often fall into the trap of immediately debating whether to buy or build. That dichotomy worked well in the past because the subject of debate was a self-contained software system with clear boundaries: you either bought an off-the-shelf system or hired people to write one from scratch. Connecting a business to agents, however, mixes three completely different layers inside a single requirement: on the outside are public interfaces given away for free by platforms, in the middle are industry workflows shared by every peer in the sector, and at the core are the permissions and risk controls of the company’s own legacy systems. When all three are tangled together, asking from the outset whether to buy or build the whole package naturally leads to a deadlock. Only by separating the three layers first can you decide whether each layer should be acquired by choosing to use, buy, or build.

External procurement can no longer be viewed through the old lens because what software vendors deliver has changed over the past few years. Previously, enterprises bought either turnkey systems with hardcoded workflows or static SDKs, leaving the buyer’s engineers to write all the code for calling APIs and stitching them into business logic. By 2026, vendors such as Cloudflare, Shopify, Stripe, and Vercel had begun delivering a new form of product: alongside underlying APIs and domain rules, they ship operational instructions and companion tools written specifically for AI, enabling the buyer’s AI to assemble business workflows directly according to in-house needs. Vercel uses skill packages to bundle and distribute installable capabilities and guidance so engineering know-how can be reused out of the box; Shopify’s AI Toolkit extends skills across the GraphQL Admin API, Functions, Polaris, Liquid, Hydrogen, and CLI so agents can read task-specific guidance on demand; and Stripe has released a companion plugin to uniformly configure protocols and skills.

The industry does not yet have a single standard term for this new mode of delivery. A 2025 essay, Beyond DRY: Reflections on AI-Native Software Engineering, drew an analogy to IKEA furniture. In the past, software vendors delivered finished chairs with fixed features that users could sit in right out of the box but could not adjust in height or color. Today, what software vendors deliver looks much more like an IKEA furniture kit: it contains core components that users cannot manufacture themselves, a detailed instruction manual written for an assembly robot, and an Allen wrench that lets the robot drive screws faster and more accurately. That essay called this combination a generative kernel, comprising three parts: a core kit (underlying interfaces and industry rules that outsiders cannot easily replicate), guiding knowledge (assembly guides and pitfall warnings written specifically for AI), and leverage tools (deterministic tools that encapsulate steps AI understands conceptually but is prone to getting wrong when writing raw code). When that long-form piece was written last year, this framework was still a theoretical extrapolation distilled from personal development experience; less than a year later, the products shipped by the major vendors above have all converged on this exact shape. Throughout the rest of this article, the term generative kernel refers specifically to this kind of bundled package delivered by Industry Layer vendors, rather than a new label for all three layers.

To understand how this IKEA-style kit lands inside an enterprise, we first need to distinguish between two fundamentally different ways AI participates in a business: the first is agent-driven runtime operations, where an agent dynamically invokes MCP tools on the spot while serving customers or handling tickets; the second is AI-driven software construction, where AI reads the vendor’s documentation and skill packages during development to write the code, while what ultimately runs in production remains a deterministic traditional software system that calls the underlying APIs statically. These two directions are completely different. Cloudflare Code Mode, Shopify Dev MCP, and Stripe Agent Skills all follow the latter path, using AI to dramatically accelerate the process of building systems. The first consolidates its entire cloud API surface into search() and execute(), exposing just two entry points so models can write code to call them directly; Shopify’s developer channel lets agents read the guidance mentioned above by task to build applications; and Stripe’s skill packages provide coding agents with up-to-date guidance for building payment integrations, ensuring the agent understands the rules before writing the integration code.

This shift in upstream delivery directly redraws the boundary between buying and building. In the past, buying an external SDK for custom development counted as building in-house because an SDK was merely raw semi-finished material; all the assembly knowledge—how to call the APIs, avoid edge-case traps, and stitch modules into a complete business workflow—lived entirely inside the heads of the buyer’s engineers. Now that vendors deliver core capabilities, industry rules, assembly knowledge, and tools as a single package—and hand the actual code assembly over to AI—the buyer’s team only needs to supply business intent, internal context, and proprietary data, and wire up the last mile. What used to be classified as in-house development on top of a purchased SDK now naturally becomes buying an industry generative kernel.

Once that boundary moves, technical decision-making splits from a single buy-or-build choice into a two-step judgment: first, identify where a capability belongs by dividing the stack into the General Layer, the Industry Layer, and the Proprietary Layer; second, decide how to acquire each layer by choosing among Use, Buy, and Build. Typically, you use the General Layer, buy the Industry Layer, and build the Proprietary Layer—but a typical acquisition mode is not the definition of a layer, and capabilities at any single layer can be used, bought, or built in-house. Nor is the General Layer something newly invented; it was always tucked inside the act of buying a platform and delivered quietly along with the underlying foundation, and teams only notice it as a distinct layer today because standardized agent-facing entry points have surfaced into plain view.

At this point, you might wonder why companies like Shopify and Stripe appear in our examples for the Industry Layer and then show up again later when we discuss the General Layer. In fact, the General Layer and the Industry Layer are not rigidly divided by vendor name; what matters is the nature of the enterprise’s relationship with that vendor. For instance, when a merchant hosts an online store on Shopify as a tenant on the platform, the public search and add-to-cart interfaces bundled for free with the storefront foundation belong to the General Layer; conversely, if an engineering team uses Shopify’s developer toolkit as a customer to build a custom application, or separately procures a suite of vertical components from a specialized software vendor, that forms a standalone supplier relationship, and the resulting toolkit belongs to the Industry Layer. The same vendor plays different roles depending on where the buyer sits.

This table illustrates the typical patterns rather than locking in how each layer must be acquired. Which layer a capability belongs to and how you acquire it are two separate questions; any given layer can be approached via Use, Buy, and Build. Before scoping and scheduling your next project, use the General Layer, Industry Layer, and Proprietary Layer to clarify capability ownership and liability boundaries first, and then decide layer by layer whether to use, buy, or build.

The General Layer: The Layer Platforms Have Already Paved for You

We have established the principle of first dividing capabilities into the General Layer, Industry Layer, and Proprietary Layer, and then deciding whether to use, buy, or build. Once an actual project planning meeting gets underway, however, management and tech leads rarely argue over the principle itself; instead, they clash over which layer a specific requirement belongs to and whether it deserves budget approval. The next three sections follow the path of an external request entering the company, working inward from the outermost General Layer to calculate the economics layer by layer. When an external agent approaches a company on behalf of a customer, the first thing it crosses is the General Layer. This layer is responsible for recognizing at the gateway or webpage that the visitor is an agent, completing security authentication, and enabling the agent to read public business information and initiate standard queries or booking requests. Whether a company is in enterprise services, professional consulting, or retail e-commerce, these outermost reception and basic interaction steps work the same way across a hundred different companies and involve neither industry secrets nor internal approvals.

In the past, engineering teams assumed they had to write custom code to wire up protocols at this layer too, but over the past few months—and even the past few days—the wind has shifted: network gateways, content management systems, and payment foundations are turning general agent connectivity into a free, built-in platform capability. Just on October 21, 2026, in Cloudflare’s case study with Commerce.com, Cloudflare enabled WebMCP—which turns webpage actions into in-browser tools—by default right at the network edge for nearly 100,000 domains; in the same year, the Abilities API and official MCP Adapter in WordPress 6.9 registered site capabilities as standard tools, Wix’s Site MCP allowed visitor agents to connect to individual websites, Stripe’s agent commerce protocol ACP and shared payment tokens took over the standard payment handshake, and Shopify’s Storefront MCP baked public catalog and checkout interfaces directly into its foundation. Because these infrastructure platforms host tens of thousands of businesses, the cost of developing a standard interface is amortized across every tenant, driving the marginal cost for any single enterprise close to zero; conversely, if an individual company pulls engineers to track low-level protocols and debug security handshakes on its own, it will spend months building something that has to be redone the moment external standards change. This gives enterprises a new option they never had before: for any requirement that falls into the layer of helping external agents find the company and execute public, standard actions, cut the in-house R&D budget right at the planning meeting and instead flip the ready-made switch in your gateway, content system, or payment platform console; even if your current foundation has not shipped that switch yet, aligning future platform selection and roadmaps with providers that support general agent connectivity is far more cost-effective than assigning your own people to build it from scratch.

Once the in-house R&D budget is saved, the only trap management needs to guard against at this layer is mistaking a free switch for a complete solution. When the news broke a few days ago about 100,000 domains connecting with a single click, many bosses immediately assumed that checking that box would make external orders start flowing in by tomorrow. In reality, the backend switch merely puts up a standard signpost by the side of the road so external agents can locate the company and read its public catalog; it neither guarantees heavy traffic on that road right away nor completes transactions that require internal network permissions and approvals. More importantly, the exposed fields, refresh intervals, and rate limits of that signpost remain entirely in the platform’s hands, and the day the company migrates off the platform over fees or compliance, that channel is revoked on the spot. The right posture toward the General Layer is simple: turn on the free switch when it is available, invest zero headcount in building your own, and never tie order-growth KPIs to it.

The Industry Layer: Buy the Generative Kernel, Not the Liability

As soon as an external or internal agent moves past public webpage queries and begins handling actual business transactions, it runs straight into industry-specific rules. A dental clinic booking an appointment must connect to a clearinghouse to verify insurance coverage; a property management service handling repair requests must triage tickets and dispatch technicians; a restaurant taking reservations must enforce deposit and cancellation policies. At this point someone might ask: since these industry rules look much the same across peers in the same sector, why not lump them into the General Layer instead of carving out a separate layer? The reason is that once the scope narrows from the entire web to a specific vertical, the executive calculus changes completely: horizontal platforms will no longer foot the bill for a niche vertical for free, so companies must pay out of pocket to procure solutions from vertical software vendors; moreover, even though peers share the same underlying industry rules, every business runs its own scheduling and customer intake sequence differently, making it impossible to solve the problem by checking a fixed switch in a backend console—the purchased components have to be reassembled into the company’s own workflows; most importantly, this step touches real transactions and fulfillment, where a miscalculated bill or a misreported status means someone has to pay out real money in compensation.

A single enterprise has no need to assign engineers to reverse-engineer clearinghouse APIs or domain rule libraries that industry peers have already figured out, so the most cost-effective way to acquire this layer is usually to buy—even though buying is merely the most common acquisition mode for the Industry Layer rather than its definition. Precisely because every enterprise must weave industry rules into its own distinct workflows, buying a turnkey module with hardcoded processes in the past meant filing a support ticket just to change a single field, while buying a bare SDK and writing everything in-house was far too slow. Today, the ideal approach is to procure the industry generative kernel discussed in the second section—that IKEA furniture kit: the vendor provides an industry core kit containing rule libraries and low-level connectors, guiding knowledge written for AI, and error-proofing leverage tools, while the buyer supplies business intent, internal context, proprietary data, and last-mile integration so AI can assemble workflows tailored to the company’s habits during development. Cloudflare, Shopify, Stripe, and Vercel, mentioned in the second section, have already proven out this delivery model across developer and e-commerce payment tooling. What the buyer receives is the generative capacity to continually assemble and adapt workflows, rather than a rigid system that cannot be changed.

In concrete vertical scenarios, an enterprise procures a generative kernel from a vendor so AI can assemble the workflow, while retaining authority over critical business decisions. For example, a dental clinic might procure a dental insurance generative kernel from a healthcare software vendor, complete with built-in insurance rule libraries, clearinghouse connectors, and AI assembly instructions for benefits verification. Instead of buying a finished module with every booking branch hardcoded, the clinic uses AI to design appointment verification and exception-handling flows around its own scheduling habits—such as holding a slot before verifying coverage for returning patients while verifying coverage before locking a slot for new patients—yet complex patient evaluations, special installment policies, clinicians’ medical judgments, and who pays when a deductible is miscalculated on a bill all remain decisions made by the clinic itself. In other sectors—such as property management firms interpreting ambiguous lease clauses or setting compensation standards for emergency forced-entry repairs, and restaurants waiving rescheduling fees for regulars or conducting allergen safety checks—those decisions likewise remain firmly under the enterprise’s own control.

When what you are procuring shifts from fixed software to an IKEA-style generative kernel, what bosses and tech leads scrutinize at the negotiating table has to change as well. Buying software used to mean ticking boxes down a feature checklist; now that you are buying semi-finished components and an instruction manual for your own AI to assemble workflows, the first step is to test in real edge cases how cleanly that kernel actually fits together: when confronted with rescheduling recalculations, partial cancellations, or abnormal holds, can AI generate working code smoothly, or does it only look good in the vendor’s demo video while forcing engineers to rewrite code by hand every day once connected to legacy internal systems? Second, calculate both entry and exit costs before signing: how many interfaces must be modified across the last mile to connect with internal legacy systems, and if you decide to switch vendors next year, can your accumulated rule configurations, interaction logs, and audit trails be exported in full in a standard format? Finally—and where there is zero room for ambiguity—draw a clear line on liability in the contract: the vendor is responsible only for software defects, downtime, and API failures, whereas how specific business rules are set and who pays when a bill is miscalculated remain operational consequences borne on the enterprise’s own shoulders. Software capabilities can be bought with money, but business judgment regarding your own customers and operational liability must stay in-house; that is the bottom line of buying capability, not liability, at the Industry Layer.

The Proprietary Layer: Write Only Unique Judgment and Legacy System Patches

Following the progression of the previous two sections—once the public switches at the General Layer are turned on and the generative kernels at the Industry Layer are purchased and assembled—what remains is the Proprietary Layer that the company must keep firmly in its own hands. When many engineering teams hear that the Proprietary Layer should be built in-house, their knee-jerk reaction is to propose rewriting the ten-year-old legacy ERP or core business system. In reality, however, the aging system sitting in the server room is not the same thing as your core. In an agent-connected architecture, the Proprietary Layer that a company truly must write itself is remarkably thin, consisting mainly of two things when broken down: business judgments where large language models cannot be allowed to improvise, and the adaptation patches and safety guardrails built directly against legacy systems.

Consider business judgment first. Behind every agent, whether external or internal, sits a large language model. And large language models are inherently probabilistic—and can even be led astray by adversarial or manipulative phrasing in external prompts. Think of an industrial distributor deciding which long-standing customer gets a special discount exception, what the gross margin floor is for each product category, or whether a returning customer with past-due history can still be approved for credit terms; or a dental clinic deciding which special-circumstance patients qualify for installment plans and who absorbs the loss if a bill is miscalculated. These business rules differ completely from one company to the next; they are both trade secrets that cannot be exposed to external platforms and financial commitments where a single miscalculation forces the company to pay out of pocket. Formulas for pricing and risk control therefore cannot be written into prompts for a large language model to guess at by feel, nor handed off to generic external plugins; instead, the company’s own engineers must lock down the parameter ranges, calculation formulas, and return structures in deterministic code, encapsulating them as strictly typed tools with rigid inputs and outputs. When reviewing a large credit order, for instance, the function should accept only the customer ID and order amount passed in by the model and return the remaining credit limit and historical overdue days, while whether the order is approved—and for how much—is decided entirely by deterministic code, leaving the model zero room to improvise over real money and risk red lines.

Once the business judgment is made, the next step is actually writing the result into the company’s database. Many outside developers assume this is nothing more than calling an API, but anyone who has worked inside an established enterprise’s server room knows that while purchased industry kits assume they are talking to modern systems available for reads and writes at any hour, what sits underneath most enterprises is a ten-year-old legacy system full of quirks no outsider could possibly know. A platform understands general interfaces and a vertical vendor understands industry workflows, yet no outside vendor knows that your company’s finance system locks the database every night from 2:00 a.m. to 4:00 a.m. to run end-of-day reconciliation. That kind of institutional baggage is never documented in any public manual; it lives only in the heads of veteran employees. In-house engineers must place a patch layer in front of the legacy system to intercept and queue order-modification requests arriving from agents in the middle of the night; if external programs are allowed to write straight into the database unbuffered, the next morning’s financial reconciliation will be thrown into chaos. Beyond accommodating the quirks of legacy systems, this layer of code also serves as the final safety guardrail: routine small-value queries and standard operations can pass through automatically, but the moment a request involves excessive discounting, a large payout, or bulk order changes, the system must slam on the brakes, suspend the request, and route it to a supervisor for manual approval.

Once the Proprietary Layer is narrowed down to business judgment functions and legacy-system patch guardrails, the tech lead can confidently strip the most cash-burning in-house infrastructure projects from the roadmap. Low-level protocol translators that shift every few months, cross-site communication, and global identity authentication are public highways already being paved by browser makers, payment gateways, and cloud platforms—if a single company assigns a handful of engineers to chase those standards, whatever they build will be outpaced by platform upgrades before it ships; as for general-purpose agent state machines and visual workflow foundations, the open-source community already offers mature frameworks ready for off-the-shelf use, and reinventing them behind closed doors adds nothing to the company’s competitive moat while saddling it with long-term maintenance debt. Looking back at the division across the General Layer, Industry Layer, and Proprietary Layer, although the Proprietary Layer is typically built in-house, the point is to keep proprietary knowledge and ultimate liability inside the company—not to build an entire stack from scratch. A company can readily use existing frameworks or bring in external teams to assist with development, so long as its unique business judgments are encoded as strongly typed functions beyond the reach of large language models and its legacy systems are wrapped in battle-tested patches and guardrails. Platforms handle the general channels, vendors supply the generative kernels, and the company holds the line on business judgment, operational liability, and the final layer of patches and guardrails.

FOMO and Reversibility: What to Do First, and What to Do Later

Back at Monday’s morning meeting, when the boss asks how soon the company can connect to agents, there are only a handful of engineers available to mobilize, and underneath sit legacy ERP systems, compliance approval chains, and core systems that cannot afford downtime. Confronted with the industry-wide anxiety of the AI-native era, the easiest mistake for a boss and tech lead to make is pouring a large budget straight into custom integrations for one specific external agent entry point. A look at the actual state of underlying interface standards and leading entry points makes it clear why now is not the time to place heavy bets. Underlying browser interface standards remain fragmented: WebMCP is still in the Origin Trial stage in Chrome and Edge, with the trial scheduled to run into early 2027, while WebKit behind Safari and Firefox have yet to signal adoption. Meanwhile, the leading entry points keep changing course: OpenAI has already marked ChatGPT Atlas as deprecated, and in March of this year it shifted the focus of Instant Checkout toward merchant Apps inside ChatGPT, retaining only ACP as the connectivity layer. With low-level standards still unsettled and major entry points pivoting every few months, spending scarce R&D budget on custom interfaces built purely for external entry points carries a high risk of having to scrap everything and start over after the next platform redesign.

A sound roadmap proceeds from the inside out, keeping every step reversible. Externally, secure your position at zero cost: at the General Layer, turn on the built-in default switches in your Cloudflare, WordPress, Wix, Stripe, or Shopify consoles, lock down high-risk write permissions, and add a logging layer at the gateway to distinguish genuine external agent calls from web crawlers and human browsers; as long as those logs show no steady, sustained volume of real external agent calls and browser and industry standards have yet to converge, the team neither builds low-level protocols in-house nor reorganizes R&D around hypothetical external traffic. Internally, aim for day-one impact: focus engineering effort on piloting Industry Layer generative kernels with low exit costs and writing the Proprietary Layer’s deterministic business judgment functions and legacy-system patch guardrails, while making your own frontline customer support, sales operations staff, and internal agents the very first users. These employees spend every day flipping between spreadsheets, entering orders, and chasing approvals across multiple aging ERP systems; putting these strongly typed tools and legacy system patches into the hands of internal staff and internal agents first saves manual verification hours and reduces order-entry errors from day one. Even if external customer agent traffic takes another year to materialize, this investment will generate steady, tangible returns through internal efficiency gains alone; and when external demand truly scales, the team can simply select a safe subset from a battle-tested internal tool library and expose it externally—ready to advance when the market arrives, and fully protected if it waits.