The Seven Layers Of An AI Adoption Stack

Most AI programs are bought one layer at a time. A model here, a retrieval service there, an agent on top of a workflow nobody has written down — then a quarterly review asking why the result never arrived. Whether any of it compounds depends on the stack underneath.

The framework below is the stack I use to scope work at ML LABS: seven layers resting on one layer of controls. It is a way to find the layer limiting a company before spending on the layer that is easiest to buy. Every layer performs only as well as the one beneath it.

Start At Data And Models

Data is the base because everything above it inherits its defects. The practical question is not whether records exist but whether they can be retrieved, joined, trusted and explained — who wrote a field, when, and under what rule. A company that cannot answer those questions for its own records will not get a defensible answer out of a model reading them.

Models sit above, the layer buyers treat as the whole stack. A model is an engine you selected, with cost, latency and a change schedule you do not control. Evidence about that choice is more durable than the choice itself, because engines get replaced and evaluations carry over. The analysis of hidden technical debt in machine learning systems found the model to be a small fraction of the code and effort in a real deployment (NeurIPS, 2015).

Knowledge Is The Skipped Layer

Knowledge is everything the model needs to know that is not in its weights: policies, product rules, prior decisions, the vocabulary a business uses for a particular exception. It is the layer most often assumed rather than built. When knowledge is missing, the symptom is a system right in the demonstration and wrong in the meeting. The specific context — this customer's contract, this site's exception, last quarter's decision — never reached it, so the people who hold it keep working beside the new system rather than through it.

A model without your context is a stranger with excellent grammar.

Building this layer means naming its sources, deciding what supersedes what, and recording where each answer came from. That record is what lets a reviewer accept an output, and it is what lets you improve the system when a reviewer rejects an output.

Agents Need A Workflow Around Them

Workflows are the path work actually travels: the trigger, the states in between, the handoffs and the exception route when a step cannot complete. If the handoff between two departments is undefined today, an agent will reach the same undefined handoff, only faster.

Agents are the layer that acts — software taking steps inside limits you stated in advance. The limits are the product itself: which actions are permitted, which require a person, what evidence the reviewer gets to see, and how an action is stopped or reversed.

Decisions Turn Output Into Outcomes

Decisions are the calls the system exists to support, each with a named owner. An output is not a decision on its own — someone still approves the packet, releases the order, escalates the case or accepts the risk. Design that decision moment explicitly: what the owner sees, what they can override, and what the system records when they do so.

Outcomes are the top layer and the only one a business is funding. Name the measure before building: exceptions resolved without a supervisor, time from trigger to an agreed next state, volume absorbed at no added cost. Keep the components visible beside the total: one improved average often hides a queue that moved rather than closed.

Seven Layers, Seven Failure Modes

Read down the third column and mark the descriptions your team recognizes. The highest marked row is usually where the next investment belongs, whatever layer a vendor is selling.

Most companies are two layers away from the value they expected, and the two layers are almost never the ones listed on the invoice. Knowledge and workflows are the usual gap, because both of them require an internal agreement that no supplier can sell you.

The Controls Under The Stack

Under all seven layers sit the controls that decide who may reach the system and what happens when something goes wrong. They carry access, audit and rollback: which identities can read which records, what was shown to whom, and how a wrong action is reversed. A stack without those controls is a demonstration, whatever it cost to build.

Nobody Owns The Middle Layers

Data has an owner. Models have an enthusiastic sponsor. The middle layers — knowledge, workflows, agents — frequently belong to nobody with the authority to settle a disagreement between the two departments. That vacuum, not the model quality, is the thing that stalls the majority of the programs that I am asked to review. If the business cannot name who decides the completion rule, who approves an exception and who grants access, a build will encode the disagreement and run it faster. Resolve ownership first.

First Steps

1. Walk one real record end to end; mark each layer built, assumed or absent.
2. Write the one decision the workflow supports, with its owner named in it.
3. Scope a bounded release against the lowest absent layer with a manual fallback on file.

Build One Column, Not One Layer

Build a narrow column through all seven layers instead of a complete platform at one. Take one workflow with real data, a chosen model, the context it needs, stated limits, a decision owner and a measured outcome — run it with access, audit and rollback from day one.

Each column delivered raises the ceiling on the next one, until the stack becomes the company's own capability rather than a collection of separate purchases. The AI engineering partnership is built to scope, build and run that column alongside your team.

References

1. Sculley, D., et al. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems, 2015.