Coordination debt: why enterprise AI fails between systems, not inside them

Every component passed. The quote still broke policy.

A sales team uses an AI application to prepare software renewals. An account executive asks for a three-year proposal. A model maps the customer's language to product IDs. The CRM returns the account hierarchy and entitlements. A usage service supplies consumption. A pricing service proposes a discount. A policy engine says the discount needs VP approval. The VP reviews and approves. The quoting system writes the final payload, and the customer gets the quote.

Nothing fails. The model returns valid output. The APIs succeed. The policy engine decides correctly. The approval is real. The quoting system writes exactly what it receives. Every dashboard is green.

Finance later finds the quote is below the margin floor.

The application paused for hours waiting for approval. Meanwhile the product catalog published a new service mapping and pricing loaded a new cost basis. On resume, one step recalculated against the new catalog, while another reused the original policy decision and approval. The VP approved one proposal. The system committed a different one.

The model didn't hallucinate. No code threw an exception. Nobody exceeded their authority. The application failed in the space between locally correct components, because nothing preserved what the approval meant across time, versions and mappings.

Why do AI failures happen between components?

Because each component is tested against what it owns, while the business rule spans all of them. Local correctness doesn't add up to application correctness when the handoffs carry meaning nobody checks.

When an AI application misbehaves, the reflex is local. Tune the prompt. Add a validator. Add another agent, an adapter, a policy check, a retry, an approval, more logs. Each change can help. Each also creates another boundary whose meaning has to survive.

That's why some AI programs get harder to run as their parts improve. Models get stronger, services more reliable, the codebase gains controls, and the application gets harder to explain, because its meaning is now spread across prompts, schemas, mappings, rules, credentials, retrieval filters, approval payloads, model routes, event handlers and release versions.

A component can be right and still take part in a wrong outcome:

• JSON matches its schema but names the wrong entity, unit, currency or tenant.
• A service is authenticated but acts with more authority than the person who started the work.
• A retrieved document is relevant but stale, or outside the requester's permissions.
• A model extracts correctly; the next step reads it against a different taxonomy version.
• A policy decision is valid; its obligations never reach the action.
• An approval is legitimate; the proposal changes before the work resumes.
• A retry recovers a timeout and duplicates an irreversible effect.
• A trace shows the order of events but not why the outcome was allowed.

Correctness is a property of the relationships, not just the parts. Systems-engineering guidance such as NIST SP 800-160 and the NIST AI RMF says the same: trustworthiness and risk belong to the whole system across its lifecycle, not to individual components.

What is coordination debt?

It's the cost of cross-system meaning that is implicit, duplicated, unversioned or owned by nobody. You don't see it on an invoice; you pay it on every change, incident and audit.

Code is indispensable. It implements algorithms, integrations, domain services and interfaces. The problem isn't code. It's expecting separately written code to turn into an authoritative application model by accident.

Pairwise integration solves each handoff. Adapter A maps CRM fields into the workflow. B shapes the payload for the model. C turns model output into a policy request. D renders the approval summary. E creates the quote. Each is reasonable.

Now the application's meaning lives in five code paths, five release cycles, several teams and several sets of defaults. Each picks its own identifiers, error handling, version assumptions and authority context. A later change passes every local test and breaks the rule that spans them. (For where this cost lands in a multi-vendor stack, see the hidden cost of a stitched AI stack.)

AI raises the stakes on every handoff

The number of technologies matters less than how much rides on each handoff. A big application of stateless services with stable contracts can be easy to reason about. A small AI application can be much harder, because a few boundaries carry uncertain output, delegated authority, long waits or irreversible actions.

Coordination load rises with the number of team, provider and trust boundaries crossed; how variable the data or inference at each one is; how much authority is delegated; how long it is between proposal and action; how costly or irreversible the action is; and how many schemas, policies, models and mappings change independently.

Where does meaning get lost between AI systems?

In six recurring places: what data means, who is acting, which context was allowed, how decisions combine, whether it's still the same case, and what actually happened in the world.

Meaning. A customer_id is a parent account in one system and a legal entity in another. A "confidence" is a calibrated probability in one place and a ranking score in another. Schemas validate structure; they don't prove two sides agree on what it means.

Authority. A user starts the work, a worker fetches data, a model proposes, an approval service records consent, a background job commits. If only the last service credential survives, the requester, tenant, purpose and expiry are gone. Zero trust and OAuth token exchange give the building blocks; the application has to carry authority to every action. (See AI agent identity and delegated authority.)

Context. A model can't tell from content alone whether a document was allowed for this user, tenant, purpose or date. Relevance isn't authorization. Freshness isn't provenance.

Decision. Models classify and recommend; code enforces thresholds; policy constrains both; people resolve ambiguity. Without explicit decision types, probabilistic output becomes business logic by default.

Continuity. Schemas, models, policies and data change while a case waits. The application must decide what stays frozen, what refreshes, what gets rechecked, and what change invalidates an earlier approval. A correlation ID doesn't answer any of that.

Consequence. The step from recommendation to action needs an operation ID, a side-effect class, a retry posture and proof of the final effect. Trace context correlates calls. It doesn't explain why the request existed or under whose authority it ran.

Does fixing coordination mean replacing our stack?

No. Specialized systems keep doing what they're authoritative for. What changes is that the relationships between them are defined once and owned, instead of rebuilt in each adapter.

That home is logical. It doesn't have to be one database or one product. Its defining property is authority over the relationships, not ownership of every part. McKinsey's April 2026 guidance on scaling agentic AI describes the same idea as a shared execution layer that enforces enterprise rules and guardrails.

What it is, and isn't:

Ownership has to follow the relationships

Coordination problems persist because org charts mirror components. The model team owns models, data owns pipelines, IAM owns identity, security owns policy, app teams own services, operations owns incidents, business owns approvals. Everyone can do well while nobody owns the relationships that make it one behavior.

A coordination-first model doesn't centralize implementation. It names owners for shared meaning: platform architecture for the application model, publishing and the extension contract; domain teams for schemas and business invariants; security for reusable policy semantics; identity for principals and delegation; data teams for classification, provenance and freshness; operations for side-effect handling and incident evidence. The question shifts from "who owns this service?" to "who owns what this handoff means?"

Before adding another component, audit the handoffs. For each consequential boundary, ask the six questions above, plus two more: what happens on timeout, and who owns compatibility when either side changes?

Back to the quote

In a coordination-first design, the approval isn't a generic completed task. The published application version binds the catalog, pricing contract, mapping, policy, proposal schema and model route. The approval references the exact proposal fingerprint and the facts the VP saw. A material change to mapping, cost basis, discount, margin, currency, customer entity or policy obligation invalidates the approval. On resume, each dependency is explicitly kept, refreshed or rechecked, or sent back for approval. The quote write carries a stable operation ID and evidence linking it to the approved proposal.

No single safeguard fixes the scenario. Making the relationships authoritative does.

Common anti-patterns

Ten rules for paying down coordination debt

1. Give every case one identity across UI, workflow, approval, tool call and evidence.
2. Make every consequential boundary a typed, versioned contract.
3. Carry the requester's authority, tenant and purpose to every action.
4. Record why each piece of context was allowed, not just what it said.
5. Mark which results are advisory and which are binding.
6. Bind waiting cases to the version and proposal they started with.
7. Decide explicitly what to keep, refresh or recheck on resume.
8. Classify side effects and give each one a stable operation ID.
9. Record evidence as the work runs, through to the confirmed outcome.
10. Name an owner for every cross-system rule.

The result: fewer unowned boundaries

Enterprise AI is still a coding problem. Teams need good software, secure services, strong models and careful domain logic. But those capabilities don't compose into trustworthy behavior on their own. The harder problem is preserving meaning as work crosses models, data, policy, tools, people, providers and time.

The answer isn't less code or more agents. It's fewer unowned boundaries: one place that defines what the handoffs mean, and evidence that ties every outcome to the authority, context, decisions, versions and actions that produced it.