The AI Layer Model: a shared map for AI systems
Understanding an AI system starts with knowing which part of the stack we are talking about. Before integrating a tool into an existing stack, we need to know what it does, what it depends on, and where it fits.
A model, a runtime, an agent framework, and a fully assembled assistant can all be described as an “AI tool.” That label alone doesn't tell us which part of the system we are looking at.
I developed the AI Layer Model to make those distinctions easier to discuss. It provides a shared reference map for placing components, describing how they fit together, and identifying security controls and ownership.
The model, examples, and a mapping skill are collected in the AI Layer Model repository on GitHub. That is the home for the public model and its version history; this post is the introduction.
Both answers can be technically correct
If I ask where we are and you answer “Earth,” you are technically correct. But that answer doesn't help us find the room we needed. We need a map at a useful scale.
You can run into the same issue when you ask someone how they are using AI. One person might tell you which agent platform they use. Another might tell you which model they load into Ollama. Both answers are technically correct, but they look at the world of AI at very different scales.
Even a more specific question can hide that distinction. “What are you using for inference?” might get Qwen as one answer and Ollama as another. Which model are we talking about? What is loading and serving it? A shared map helps us locate the answer and ask the right questions without memorizing every product.
Nine layers, grouped into three planes
The model separates responsibilities into nine layers. I group those layers into three planes to make the stack easier to work through:
- Substrate — L1–L2: the hardware and the runtime that loads and executes the model. Where does the computation happen, and what software runs it?
- Cognition — L3–L6: the model, how a call uses it, the context available to it, and the tools it can request. Which model is doing the work? What can it see? What can it do beyond generating text?
- Systems — L7–L9: the control loop, orchestration, and interface or delivery. What happens next? How do separate parts coordinate? Where does the person or another system receive the result?
Identity, governance, safety, evaluation, and observability cross the entire stack. They don't become someone else's concern just because a diagram puts them off to the side.
This was inspired by the OSI model's usefulness as a shared reference. The AI layers are their own model, with their own responsibilities. The numbering is a way to organize questions, not a claim that AI follows the networking stack or that every request travels through nine steps in order.
Follow one ordinary task
Consider an assistant asked to “find a time and draft a meeting invite.”
We can choose a model at L3 and configure how we use that model at L4. The request and attendee information are context at L5. A calendar lookup is a capability at L6; the returned availability can become context for a later call.
The L7 control loop decides whether to look something up, draft the invite, or stop. L8 can coordinate separate pieces of work when the design needs that. L9 is where the draft appears for a person to review. The whole thing still runs on hardware and a runtime at L1 and L2.
A real product can cover several of these responsibilities. An agent is an assembly of pieces across layers. It may bring together a model, context, tools, and a control loop. An individual system may need less than that, or it may coordinate several such assemblies. The map should help us explain those differences.
You can't secure what you can't place
This is where the map becomes useful to me as a security practitioner. An unsafe model artifact can put the runtime at risk. Malicious retrieved content can redirect behavior. A bad decision can have far too much authority when a tool has permissions it doesn't need. Those problems have different control points, and an attack path can cross several layers.
“Secure AI for us” may land on one team, or even one person. But that ask can hide runtime operations, application boundaries, data access, identities, tool permissions, and model behavior. The map gives us something concrete to point to when we explain the scope of that work.
We already have a wealth of expertise in these areas: application security, platform and cloud security, identity, data security, and more. A shared map helps us bring the right people into the conversation and work out who can change a control, who operates the component, and who checks the handoff.
Try placing something on it
Take one AI system you work with. Place its components on the map, including where a product spans several layers. Follow a real task through it: what information comes in, what gets called, and where does the result go? Then pick a boundary and check whether it holds.
The repository also includes a mapping skill for use with an agent. Give it a tool or system to examine, and it can help work through the responsibilities, dependencies, and layers involved. Its result is a reasoned starting point to check against documentation and your deployment, rather than a security certification.
This is a reference model and an active discussion. There are other ways to describe AI architecture, and real implementations will keep challenging the boundaries. If a component doesn't fit, or you would draw a boundary differently, I would like to hear why. That's how we can make the map more useful.
Read the model, try the mapping skill, and join the discussion on GitHub →
The model and original write-up are available under CC BY 4.0, and the mapping skill is available under MIT. When referring to the model, please credit Logan Smith, link to the repository, and identify the version you used. The repository's license notices explain the terms for each part.
These are my own views and work. They do not represent my employer or any related vendors.