Why Agents Are Unbundling Vertical AI
The vertical AI firm is facing a specific economic problem: a general-purpose agent can now assemble tasks that its integrated application once coordinated. The question is not simply whether customers will use agents, but which coordination costs have fallen enough to make the firm’s bundle separable. Understanding that mechanism helps distinguish a genuine component opportunity from a workflow handoff whose hidden costs have merely moved elsewhere.
A vertical AI product once earned its place by doing several jobs together. It connected to the customer’s data, organized a domain workflow, applied specialized logic, produced an output, and handled the connective work between steps. The value of the product was partly in the intelligence of each step, but also in making the steps operate as one dependable service. General-purpose agents alter that last advantage first.
Why buying the bundle once beat assembling the parts
A customer needing AI-supported work in accounting, law, healthcare, procurement, or another specialized field has three broad choices. They can build the capability internally, buy an integrated vertical product, or assemble separate components from different providers. Building internally is usually difficult because the specialist provider has spread the fixed costs of domain expertise, model access, training data, evaluation, and engineering across many customers. The more important economic comparison is therefore between buying the bundle and assembling it in the market.
That comparison turns on coordination cost. A customer assembling components must first find the right provider, judge whether its output is reliable, connect it to the other components, handle errors that appear between calls, and maintain the connective layer as systems change. These are not all the same kind of cost. Finding and evaluating a provider is a search problem. Determining which component failed and how to repair the result is an enforcement problem. Agreeing on data structures, field names, date formats, and error signals is a bargaining problem expressed through technical interfaces.
An integrated vertical firm absorbs much of that work inside its own boundary. The customer pays a premium, but receives a preassembled workflow in which the provider has already chosen the components, reconciled their schemas, monitored their interactions, and assigned responsibility for keeping the path functional. The firm is not valuable merely because it owns a clever model. It is valuable because the customer does not have to coordinate a small market every time a domain task is performed.
The logic is Coasian in a practical sense. Firms internalize activities when directing them within one organization costs less than searching, contracting, coordinating, and monitoring through the market. A vertical AI product grew around the bundle because, historically, the market cost of assembling specialized capabilities exceeded the premium for receiving them together.
Consider a simplified task in which a customer needs information extracted from several documents, checked against a business record, and turned into a recommendation. Before a capable orchestrator, the customer might have needed a document tool, a data connector, an internal workflow, and a person or team responsible for reconciling failures. The vertical application could make those transitions part of one product. The customer might not even perceive the individual components; they experience a result and a maintained path to that result.
The bundle also makes failure legible. If an extraction is incomplete, a schema does not match, or a downstream step rejects an input, the integrated provider has an incentive to repair the connection because the customer bought an outcome rather than a collection of calls. That does not mean an integrated product never fails. It means the coordination burden has an identifiable owner. Under market assembly, the customer may have to determine whether the problem belongs to the model, the connector, the data, the transformation between them, or the workflow that assumed a different answer.
This distinction explains why a vertical firm’s workflow can be an economic asset even when it contains no novel algorithm. The workflow prevents repeated coordination. It bundles decisions about sequencing, validation, error handling, and maintenance that would otherwise be left to the customer.
Maintenance is where the bundle’s value becomes easiest to miss. A component assembly that works on launch day is not necessarily a functioning product months later. A provider can change a field name, a format, an error signal, or the meaning of a returned value. Another provider can fail in a way that leaves the next step technically reachable but substantively wrong. Someone must notice the change, determine which dependency is affected, revise the connection, and test the whole path again. An integrated vertical firm performs that recurring coordination inside its own boundary; a customer assembling components must either perform it themselves or rely on an orchestrator to do so.
This is also why the comparison is about more than engineering labor. When a workflow fails, the customer needs to know whether to retry, replace a component, ask for human review, or stop the process. The integrated product can encode at least part of that decision in its workflow and support model. Market assembly may lower the purchase price of individual capabilities while raising the cost of deciding what to do when those capabilities disagree. The bundle remains economical whenever that recurring cost is larger than the premium charged for integration.
How an agent changes the comparison
A general-purpose agent can take on part of that integration role. It can interpret a request, plan across files, call external tools, manipulate documents, and coordinate a sequence of actions. In effect, it performs the connective work that once made market assembly unattractive. When the agent can search for a capability, invoke it, interpret its response, and pass an acceptable result to the next step, the customer no longer needs a separate integrator for every workflow.
The change is not that coordination disappears. It is that some coordination becomes cheaper and more reusable. The agent can perform search at the moment a task is requested. It can translate among tools or ask for a different format. It can retry a failed call or route around a component that does not respond. It can hold the task’s immediate context while combining capabilities that previously lived in separate products. These actions lower the cost of assembly, but only when the agent can perform them reliably enough for the task at hand.
The conditions matter. If the agent cannot tell which provider is appropriate, cannot recognize a malformed result, or cannot determine whether an error came from the source or the connection, the old coordination cost has not vanished. It has moved to the customer, the platform operator, or a support relationship between them. If schemas remain incompatible, a supposedly simple tool call may still require custom glue. If the customer must manually reconcile every exception, the agent has automated the happy path without replacing the integrated product’s coordination function.
The result is an uneven shift in willingness to pay. Customers become less willing to pay a vertical firm for the parts an agent can assemble cheaply: routine retrieval, straightforward extraction, or a simple transformation whose correctness can be checked independently. They may remain willing to pay for the parts an agent cannot assemble cheaply, such as specialized evidence, accumulated context, reliable review, or an accountable decision. The product boundary therefore moves capability by capability rather than all at once.
This is the important limit of the phrase “the agent replaces the application.” An agent may replace the application’s role as a visible coordinator without replacing the domain assets or responsibility that made the application valuable. The economic question is not whether an agent can call a function. It is whether the customer can receive a defensible outcome without the vertical firm coordinating, maintaining, and standing behind the surrounding system.
A vertical firm should also distinguish a temporary reduction in assembly cost from a durable change in the market. Agents may improve rapidly, but customers still bear the consequences of an incorrectly assembled workflow. The relevant comparison includes the cost of checking outputs, assigning failures, maintaining instructions, and adapting the workflow when the domain changes. A component is attractive when those costs are low enough to be absorbed by the customer or orchestrator. An integrated product remains valuable when those costs are difficult to transfer.
Three ways an orchestrator can reach the vertical firm
The next question is how the agent and the vertical firm relate. The relationship is not a single market form. Three patterns can coexist.
In an open-protocol relationship, access is governed by a public specification, developer terms, or standardized rules. A vertical firm exposes a capability in a form that an orchestrator can discover and call without negotiating a relationship tailored to that particular firm. This lowers the friction of connecting many providers. It also makes the component available to a broad ecosystem rather than limiting it to one negotiated integration.
In a curated commercial partnership, the orchestrator and vertical firm negotiate a relationship. The agreement may address integration duties, support, data use, promotion, or termination, but it does not necessarily give the vertical firm a share of transactions. The parties exchange some of the flexibility of open access for more explicit commitments.
In a revenue-sharing arrangement, the commercial terms explicitly connect the vertical firm’s economics to transactions or marketplace activity. The arrangement can give the specialist a formal participation in the value generated through the orchestrator, although the percentage or fee alone does not determine how much demand the specialist receives.
These forms matter because the mechanism of dependence differs. An open-protocol participant typically receives reach through standardized access but not the protections of a relationship-specific contract. A curated partner can negotiate terms, while a revenue-sharing partner can negotiate both integration and commercial participation. Neither arrangement changes the underlying economic fact that the orchestrator may be the place where users discover, request, and evaluate the work.
The open-protocol case is especially important for vertical firms because standardization makes participation easy to expand. A firm can tell itself that it has preserved its product: the domain service still runs, the data remains in its systems, and the agent merely calls an API. But the customer may now encounter the service only through the orchestrator. The agent chooses when to invoke it, how to describe its result, and whether to use it again. The vertical firm has become easier to reach, but its position may depend on decisions it does not control.
That dependency is not a reason to reject every open protocol. It is a reason to separate distribution from ownership. A component firm may rationally accept the orchestrator as its channel if the task is modular and the economics of broad adoption outweigh the loss of a standalone interface. The firm then needs to compete on reliability, accuracy, latency, price, permissions, and interoperability. Its risk is becoming interchangeable with another component once the agent can assemble similar results from elsewhere.
For an accountability-bound firm, the same choice has a different meaning. If the orchestrator owns the surface where a conclusion is requested and accepted, the vertical firm may no longer control the context in which that conclusion is evaluated. The firm can still provide a high-quality capability, but the customer’s coordination costs have been reduced by moving the workflow outward. The part left inside the vertical firm may be precisely the part that is easiest for a general model to approximate.
The mechanism therefore ends at a decision boundary, not at the first successful tool call. If the agent can assemble a result and the remaining checks are cheap, the vertical firm may have found a legitimate component market. If assembly succeeds only because a specialist preserves evidence, review, authority, and exception handling behind the scenes, then the agent has lowered the cost of initiating work without replacing the accountable system.
The following analysis examines what happens after that boundary moves. Interoperability may improve while the orchestrator gains control over discovery, routing, and substitution. The vertical firm must therefore ask not only how cheaply its service can be called, but who controls the surface that decides when it is called and what complementary assets make its result worth trusting.