Layer 1
Compute, runtime, sandboxes, and serving infrastructure
GPU capacity, execution environments, sandboxes, hosting, job runners, and serving infrastructure.
CAISI
Independent research and operating notes on AI Software Delivery Control.
Framework / Agentic Control
The Agentic AI Stack: Where Control Actually Belongs
An OSI-inspired model for the agentic AI stack is useful because it separates infrastructure, models, memory, orchestration, tools, authority, controls, and business actions. Without that separation, every AI risk conversation collapses into the model layer.
The control problem does not live cleanly in one layer. It appears where tools, credentials, policy, proof, and domain workflows combine into action.
Last updated: May 9, 2026
In this piece
Why a layered model helps
"Agentic AI" is too broad to govern as one thing. One team may be debating model routing. Another may be connecting agents to internal tools. A third may be approving write access to repositories or cloud systems. Those are not the same control problem.
The point of an OSI-inspired model is not to create another taxonomy for its own sake. The point is to stop mixing layers that need different owners, evidence, and control mechanisms.
Compute risk, model risk, context risk, orchestration risk, tool risk, credential risk, approval risk, and business-process risk all matter. But the highest-leverage governance question is narrower:
What can this workflow do, through which tool, with whose authority, under what control, and with what proof?
The eight layers
Layer 2
Models, providers, and model gateways
Model APIs, routing, observability, prompt and response controls, and model-provider abstraction.
Layer 3
Context, memory, retrieval, and enterprise data
The documents, records, memory, retrieval paths, and enterprise data an agent can use while deciding what to do.
Layer 4
Agent runtime, orchestration, and planning
Planning loops, multi-agent coordination, durable execution, state, retries, handoffs, and human-in-the-loop mechanics.
Layer 5
Tools, actions, MCP, connectors, and execution interfaces
The interfaces that let agents touch the world: repositories, CI/CD, cloud APIs, SaaS APIs, shells, browsers, databases, and MCP tools.
Layer 6
Authority, identity, credentials, wallets, and access
The grants that give an agent or workflow power: OAuth, tokens, service accounts, cloud roles, delegated user authority, workload identity, and future economic authority.
Layer 7
Control, policy, approval, proof, and trust
The decision and evidence layer: allowed, approval-required, blocked, validated, logged, signed, reviewed, revoked, or trusted over time.
Layer 8
Business workflows and domain actions
The places where value and risk show up: software delivery, cloud operations, IT administration, security operations, data engineering, support, finance, procurement, legal, and payments.
Where risk changes shape
The model layer is important, but it is rarely enough to explain the operational risk. A model that can only answer a question creates a different problem than a workflow that can retrieve internal context, call a tool, use a token, change a file, trigger CI/CD, or publish a package.
Risk changes shape when Layer 5 and Layer 6 meet Layer 8:
- Layer 5 defines the tools and action interfaces the workflow can use.
- Layer 6 defines the authority those tools can exercise.
- Layer 8 defines the domain where the action has consequences.
That is why a model inventory, a prompt policy, or a runtime dashboard can be useful and still incomplete. The harder question is not only what the agent saw or said. It is what the workflow was able to do.
Where control belongs
Layer 7 is the control layer, but it cannot operate as a detached policy box. It has to understand the tool call, the credential, the target system, the domain workflow, the owner, and the evidence requirement.
A useful Layer 7 decision does not ask only whether "AI is allowed." It asks whether a specific action should be allowed, approved, or blocked in a specific context.
Layer 7 needs Layer 5, Layer 6, and Layer 8 context
Tool without authority is capability without permission. Authority without a domain is permission without business meaning. Policy without proof is intent without evidence.
For AI Software Delivery Control, this becomes concrete. A team needs to map the action path, classify authority, require approval where the blast radius is real, and preserve proof after the decision.
Why software delivery first
This stack applies beyond engineering. Agents will affect cloud operations, IT administration, security operations, finance, support, procurement, and legal workflows. But software delivery is the first practical domain to study because the action paths are visible and already consequential.
Software delivery has artifacts a team can inspect:
- pull requests
- workflow files
- CI/CD runs
- package manifests and scripts
- MCP and tool declarations
- credential references
- release rules
- infrastructure and deployment paths
That makes it possible to create a concrete action graph:
workflow -> repo/PR -> tool -> credential -> action -> target -> approval/proofThe first question should not be "which model is safest?" The first question should be whether the team can explain the action path and defend it later.
Questions to ask
A layered model is only useful if it changes review behavior. For an AI-assisted workflow that can affect a real system, start with these questions:
- Layer 8: Which business workflow or domain action is affected?
- Layer 7: Which actions are allowed, approval-required, or blocked?
- Layer 6: Which identity, credential, token, grant, or delegated authority is used?
- Layer 5: Which tool, MCP server, connector, API, shell, browser, database, or workflow interface is reachable?
- Layer 4: Which runtime or orchestration path decides, retries, delegates, or escalates?
- Layer 3: Which context, memory, retrieval path, or enterprise data influences the action?
- Layer 2: Which model or provider is involved, and does that choice change the control requirement?
- Layer 1: Where does execution happen, and is the environment isolated enough for the action class?
The practical takeaway is simple: agentic AI is not governed by controlling one layer. It is governed by understanding how layers combine into authority-bearing action.