The hidden cost of a stitched AI agent stack

The policy changed once. The application changed in seven places.

A global distributor builds an AI supplier-refund application from specialized parts: a UI builder, a workflow engine, an identity provider, a policy service, a document index, a model gateway, an approval tool, background workers, the payments API and an observability platform.

A new rule arrives: refunds over $25,000 must keep the supplier's legal entity, get a second approval, use an approved regional model route, carry a stable operation ID and keep a payment receipt.

The rule is written once, in the policy language. Its meaning then has to be translated across the stack. The UI gets new fields and a new review summary. The workflow gets a branch, a wait and a resume rule. The approval tool gets a new decision state. The tool adapter gets record checks and an operation ID. The model gateway changes routes. The evidence pipeline adds joins. The worker needs a new event contract.

Most teams ship their change. One worker still reads the old approval event, where approval is a single boolean, and its mapping drops the legal entity. A refund case that started before the change resumes after it. The worker sees approved = true, signs in with a broad service credential and pays the refund.

Each team can point to its own release. Nobody can say which version of the application governed that case, or prove which combination of schema, mapping, identity, policy, approval, worker and route applied. The hidden cost is the work it takes to make all those releases mean one thing.

Is best-of-breed the problem?

No. The problem is the relationships between the products, which usually have no owner. Specialized products bring depth, independent scaling and choice. It's reasonable to pick separate systems for identity, data, models, workflow and observability.

The problem is that the relationships between them usually have no owner. The gateway owns model calls. The policy service owns decisions. The workflow engine owns scheduling. The approval tool owns tasks. None of them owns the whole chain: who asked, which data was permitted, what was proposed, which obligations applied, what the reviewer approved, which version resumed, what changed in the world, and what proves it.

That isn't just integration complexity. It's application meaning spread across systems that each see only their part.

Connected isn't the same as integrated

An API defines an endpoint. A schema validates shape. An event moves a message. A trace correlates calls. A policy service returns a decision. None of these, alone, carries what the relationship means.

Two systems can agree that amount is a number and disagree on whether it's gross, net, a cap or an estimate. Two services can share a user ID while one acts for the user and the other under a broad service identity. A policy decision can be right while its obligations never reach the point of action.

Where does the hidden cost land?

In six places, and most of them aren't on any invoice. Licenses, usage and infrastructure are visible. The larger cost builds up around the relationships between components:

Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. A stitched stack contributes to all three.

Every part works. The whole doesn't.

Point tools are tested against what they own, which is right. The hard failures happen when every component meets its own contract and the combination still breaks an end-to-end rule:

• Search returns authorized documents; a downstream mapping drops the tenant scope.
• Policy returns PERMIT; an adapter discards the obligations.
• The approval tool records the right reviewer; the resumed workflow executes a changed proposal.
• The payments API executes one valid request; a retry creates a second payment.
• The trace records every call; nothing proves why the final action was allowed.

You have to test the relationships that make the components behave as one system, not just each component.

A small change can travel a long way

Connector count understates the burden. One model route can be coupled to prompt rendering, output schemas, tool descriptions, provider region, retention policy, evaluation coverage, cost attribution and replay. Swap the endpoint without changing the HTTP contract, and you can still change what the application means across all of those.

That's why some "minor" upgrades need weeks of regression testing while larger internal changes stay contained. The burden grows with how far a change can reach, not with the number of connectors.

State and side effects are the most expensive seams

Stitching hurts most when several systems each hold their own view of the state. The workflow engine thinks a task timed out. The queue redelivers. The approval tool shows a decision. The payments API already committed. Observability records all of it without saying which state decides the next step.

Recovery then gets rebuilt in every worker and adapter: one retries on timeout, another de-duplicates by message ID, another makes a new operation ID, a fourth reverses by hand. The stack is connected, but the business operation has no single lifecycle. (See retries and idempotency for AI agents.)

Governance becomes a coordination exercise

In a stitched stack, one control lives in several forms. Tenant scope is a database filter, search metadata, a token claim, a cache-key prefix and an API parameter. Data residency is a router setting, a storage policy, a support-access rule and a telemetry destination. Approval is a task record, an event, a workflow variable and a downstream flag.

Each form can be correct while the control as a whole is incomplete. A private-route policy is bypassed by a fallback adapter that picks a public endpoint. A tenant filter protects the database but not the shared index. Without one place that owns these relationships, governance turns into release coordination, spreadsheets, exceptions and evidence gathering.

Nobody can name the version of the application

Each product has its own version: UI, workflow, schema, policy bundle, model route, index, approval form, worker build, API and telemetry config. A list of component versions isn't an application version. For a case that waited three days, you need to know which combination applied when it started, what changed while it waited, and what was rechecked before it committed. Without one published application version, every team reports its own state truthfully, and nobody can reconstruct the system that actually ran.

Integration doesn't require a monolith

The alternative to a stitched stack isn't one product that owns every database, model and tool. It's a governed core with a composable edge. Specialized systems keep doing what they're authoritative for. The cross-cutting relationships (authority, policy and its enforcement, approvals, durable state, side effects, versions and evidence) live in one runtime the work flows through.

McKinsey's April 2026 guidance on scaling agentic AI describes this as a shared execution layer that enforces enterprise rules and guardrails. That distinction matters: semantic integration, not physical consolidation.

Change is where the debt shows

A stitched application can look manageable while nothing changes. The cost appears when something does. A new schema field ripples into mappings and approval forms. A model-route change alters quality, data location, cost and evidence. A policy revision creates obligations at several enforcement points. A retry-policy change alters real-world side effects. A new event contract hits cases already waiting.

Testing only the changed component can't tell you whether the application still means the same thing. You need a change process at the level of the application: which relationships a change touches, which owners must review it, whether waiting cases are still compatible, and how to roll it back. (See The Hidden Cost of Speed to Change.)

Count cost per outcome, not per license

License and usage costs matter, but they're only part of the bill. A stitched stack also consumes engineering time on adapters, security time on cross-system authorization, operations time on queues and incidents, audit time on evidence, reviewers' time on exceptions and finance time normalizing several bills.

The right comparison isn't suite price against the sum of point-tool licenses. It's the full cost per valid, authorized, evidenced business outcome, including the coordination needed to make the stack behave as one system.

When a stitched stack is the right call

Composable architecture can be the right choice: existing investments, regulatory boundaries, data gravity and team structures can all argue for it. It's defensible when you can answer these before production:

Common anti-patterns

Ten rules for a composable AI stack

1. Define one authoritative application version, even when execution spans products.
2. Make every consequential boundary an explicit, versioned contract.
3. Carry authority, tenant, scope, purpose, state and policy across every boundary.
4. Declare which system is authoritative for each entity, decision and receipt.
5. Give every cross-component rule a named owner.
6. Gate changes at the application level, with migration for waiting cases.
7. Treat policy, approvals, retries and side effects as application semantics, not adapter details.
8. Join telemetry into one evidence model that ends at the confirmed outcome.
9. Measure cost per governed outcome.
10. Keep a governed core without owning every specialized component.

The application can't remain nobody's system

Best-of-breed components can stay best-of-breed. The application can't stay nobody's system. The hidden cost of a stitched stack is the cost of rediscovering what the system means every time it changes, fails or has to explain itself, during every release, policy change, approval, retry, incident, audit and cost review.