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 placed on top of a workflow nobody has written down — and then a quarterly review asking why the business result never arrived. The individual purchases are usually defensible. What decides whether any of it compounds is the stack underneath them.

The diagram below is the stack I use when I scope work at ML LABS: seven plain layers resting on one control boundary. It is a reading instrument rather than a product architecture — a way to find the layer that is actually limiting a company before spending again on the layer that is easiest to buy. Read it from the bottom, because 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 directly above, and they are the layer buyers treat as the whole stack. A model is an engine you selected: open or closed, hosted or local, general or narrow, each with cost, latency and a change schedule you do not control. The evidence you keep about that choice — the cases it handles, the cases it fails, the comparison against the alternative — is more durable than the choice itself, because engines get replaced and evaluations carry over.

The engineering literature has been consistent on where the cost actually lands. 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). A decade later, buyers still price the small fraction and inherit the rest.

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 particular business uses for a particular exception. It is the layer between raw records and a usable answer, and it is the one most commonly assumed rather than built. A retrieval index alone is not this layer — an index without provenance, freshness and scope rules is a faster way to reach an outdated document.

When knowledge is missing, the symptom is a system that is right in the demonstration and wrong in the meeting. It answers generically because the specific context — this customer's contract, this site's exception, last quarter's decision — never reached it. The people who hold that context then keep working the way they always did, beside the new system rather than through it.

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

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

Agents Need A Workflow Around Them

Workflows are the path work actually travels: the triggering event, the states in between, the handoffs and the exception route when a step cannot complete. Most operating pain lives here, and most of it predates AI. If the handoff between two departments is undefined today, an agent will simply reach the undefined handoff faster.

Agents are the layer that acts — software taking steps inside limits you stated in advance. The limits are the product: which actions are permitted, which require a person, what evidence the reviewer sees, and how an action is stopped or reversed. The voluntary AI risk-management framework is useful background for placing that oversight deliberately rather than adding an approval button to every screen (NIST, 2023).

Retries deserve specific attention at this layer, because an agent that acts twice is a different failure from an agent that answers badly. The engineering treatment of safe retries through idempotent APIs describes the pattern an operator should demand before consequential actions are enabled (Featonby, n.d.).

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 — someone still approves the packet, releases the order, escalates the case or accepts the risk. Design that moment explicitly: what the owner sees, what they can override, and what is recorded when they do.

Outcomes are the top layer and the only one a business is actually funding. Name the measure before building: exceptions resolved without a supervisor, time from a triggering event to an agreed next state, volume absorbed without adding cost. Then keep the components visible beside the total, because a single improved average often hides a queue that moved rather than closed.

Adoption statistics cannot substitute for that measurement. Reported AI use across business functions tells you the market is moving, not that a specific workflow improved (Census Bureau, 2026). The accountability framework organized around governance, data, performance and monitoring is a better lens for asking what changed after release (GAO, 2021).

Seven Layers, Seven Failure Modes

The table is a diagnostic aid, not a maturity score. Read down the third column and mark the descriptions your team recognizes — the highest marked row is usually where the next investment belongs, regardless of which layer a vendor is currently selling you.

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

The Boundary Under The Stack

Under all seven layers sits the boundary that decides who may reach the system and what happens when something goes wrong. It carries 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 it is a demonstration, whatever it cost.

Supplier conversations get sharper at this layer. The secure software development recommendations provide vocabulary for asking how changes are reviewed, dependencies maintained and vulnerabilities handled (NIST, 2022). Ask for practices and responsibilities for the deployed system — naming a framework is not evidence of following it.

Nobody Owns The Middle Layers

Data has an owner. Models have an enthusiastic sponsor. The middle — knowledge, workflows, agents — frequently belongs to nobody with authority to settle a disagreement between two departments. That vacuum, not model quality, is what stalls the majority of programs I am asked to review.

If the business cannot name who decides the completion rule, who approves an exception and who grants the access, a build will encode the disagreement and run it faster. Resolve ownership first. Waiting for that answer is a decision about dependency, not an absence of ambition.

First Steps

1. Walk one real record end to end and mark, on each of the seven layers, whether it is built, assumed or absent.
2. Write the one decision the workflow exists to support, with the person who owns it named in the sentence.
3. Pick the lowest absent layer and scope a bounded release against it, with its manual fallback documented.

Build One Column, Not One Layer

Build a narrow column through all seven layers instead of a complete platform at one. Take a single workflow, give it real data, a chosen model, the context it needs, stated limits, a named decision owner and a measured outcome — then run it with access, audit and rollback in place from the first day. A thin column that reaches production teaches you more about your operation than a broad layer that never touches it.

That sequencing is how ML LABS accelerates adoption, integration and leverage: each column delivered lifts the ceiling on the next one, until the stack itself becomes the company's capability rather than a collection of purchases. When the work needs an operator to scope, build and run that column alongside your team, the AI engineering partnership is built for exactly that continuing responsibility.

References

1. Sculley, D., et al. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems, 2015.
2. Tabassi, E. Artificial Intelligence Risk Management Framework 1.0. NIST, 2023.
3. Featonby, M. Making Retries Safe With Idempotent APIs. Amazon Builders' Library, n.d.
4. U.S. Census Bureau. Large Firms With at Least 20 Employees Biggest AI Users. 2026.
5. U.S. Government Accountability Office. Artificial Intelligence: An Accountability Framework. GAO-21-519SP, 2021.
6. Souppaya, M., Scarfone, K., and Dodson, D. Secure Software Development Framework Version 1.1. NIST SP 800-218, 2022.