DEEP DIVE SERIES · #05

The 7 Layers of AI Systems Engineering: From Foundation Models to Shared Meaning

Luca Viscomi

· Published Sep 9, 2026 · Updated Sep 24, 2026 · 9 min read

The biggest misconception in modern AI engineering is that building an agent is simply writing a prompt and connecting an API key.

When prototypes fail in staging, teams often blame the foundation model: “The model isn’t smart enough,” or “We need the next generation frontier model.”

In reality, the model is only the bottom tier of a complex, multi-layered computing stack. Just as network engineering relies on the 7-layer OSI model to separate raw physical signals from application protocols, dependable enterprise AI requires a structured separation of concerns.

If your agent is unreliable, hallucinating tool parameters, or burning tokens in infinite loops, the failure is almost never in Layer 1. It is almost always an unaddressed flaw in the surrounding engineering harness.

Here is the complete architectural blueprint of the 7 Layers of AI Systems Engineering.

> model.load(tier="claude-3-5-sonnet")
> weights.evaluate(task="reasoning")
> token_stream.bind(temp=0.0, seed=42)
✓ probability kernel ready [lat: 142ms]

Layer 01: Foundation Model

Core Question: What can the model do?

The foundation model is the raw compute engine of semantic reasoning. Whether you are leasing Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o, or self-hosting open weights like Llama 3 or DeepSeek-V3, this layer represents the model’s learned capabilities and fundamental constraints.

Key Engineering Responsibilities:

• Capability Profiling: Measuring empirical benchmark performance across reasoning, math, code generation, and multilingual comprehension for your specific task domain.
• Architectural Trade-offs: Choosing between dense models (consistent latency) and Mixture-of-Experts (MoE) architectures (throughput and token economics).
• Latency & Cost Budgets: Matching the model tier to the cognitive load (e.g. using lightweight Flash models for routing and high-tier models for synthesis).
• Known Failure Boundaries: Identifying tokenizer biases, non-determinism, floating-point variance across providers, and catastrophic forgetting.

Engineering Rule: Treat the foundation model as an untrusted, probabilistic processing unit. Never expect Layer 1 to enforce business rules that software engineering should handle deterministically.

Layer 02: Prompt Engineering

Core Question: What should it do?

Prompt engineering is no longer about finding “magic words.” In enterprise systems, it is declarative behavioral compilation.

This layer defines the persona, task boundaries, input-output schemas, and hard operational constraints that govern the model’s execution.

{
  "task": "Extract enterprise invoiceline items",
  "input_schema": "StructuredPDFPayload",
  "output_schema": "PydanticInvoiceModel",
  "negative_constraints": [
    "Do NOT estimate missing VAT numbers",
    "Do NOT round line item decimals",
    "Reject documents marked DRAFT"
  ]
}

Key Engineering Responsibilities:

• Schema Contracts: Compiling strict JSON schemas using Pydantic or Zod to enforce typed completions.
• Few-Shot Exemplar Selection: Dynamically injecting high-signal, real-world edge-case examples that calibrate confidence.
• Negative Behavioral Constraints: Explicitly bounding what the model is prohibited from doing (preventing over-eager guesses).
• Prompt Versioning & Diffing: Treating system prompts as audited code with semantic regression tests on every pull request.

Layer 03: Context Engineering

Core Question: What does it need to know?

If prompt engineering defines the instructions, context engineering governs the information diet.

Models do not fail because they lack general knowledge; they fail because their context windows are starved of relevant facts or choked with irrelevant noise. Context engineering is the active management of the model’s working memory at runtime.

Key Engineering Responsibilities:

• Dynamic Context Assembly: Merging system prompts, episodic user session history, retrieved enterprise documents, and recent tool outputs into a cohesive token payload.
• Hybrid Retrieval (RAG): Combining dense semantic vector search with sparse BM25 keyword search using Reciprocal Rank Fusion (RRF) to capture both semantic concepts and exact identifiers.
• Attention Budgeting & Needle Placement: Mitigating “lost-in-the-middle” attention degradation by positioning high-stakes data near the prompt margins.
• Context Compaction & Eviction: Pruning stale tool scratchpads, rolling summaries, and cached entity states before token limits are breached.

Layer 04: Harness Engineering

Core Question: How can it act safely?

An LLM cannot directly reboot a server, query a SQL database, or dispatch an email. The runtime harness is the execution scaffolding that gives the model hands—while holding it in an iron grip.

Key Engineering Responsibilities:

• Tool Protocol Gateway: Implementing standardized client-server contracts like the Model Context Protocol (MCP) via stdio or Server-Sent Events (SSE).
• The Mutation Boundary: Structurally separating read operations (SELECT, GET) from state mutations (DELETE, POST, UPDATE), requiring signed cryptographic tokens or human-in-the-loop approvals for write actions.
• Least-Privilege Scoping: Presenting only 3 to 4 hyper-relevant tools per execution step rather than dumping an entire enterprise API catalog into the system prompt.
• Telemetry & Tracing: Emitting OpenTelemetry spans on every tool invocation with exact input parameters, execution latencies, and output byte lengths.

Layer 05: Loop Engineering

Core Question: How does it check and refine?

Autonomous capability comes from iteration. Loop engineering governs how the agent cycles through observation, reasoning, action, and evaluation until a termination condition is met.

Key Engineering Responsibilities:

• Deterministic Invariant Assertion: Automatically verifying whether a tool action actually succeeded (e.g. confirming a database row exists or HTTP 200 payload contains valid data) before accepting completion.
• Self-Healing Exception Handling: Capturing runtime tracebacks and schema validation errors, feeding them back into context so the agent can autonomously diagnose and correct its own parameters.
• Termination Governors: Hardcoding maximum loop iterations, token spending limits, and wall-clock timeouts to eliminate run-away token burns and infinite cycles.
• Backoff & Rollback Mechanics: Reverting state modifications if an agent fails three consecutive validation checks.

Layer 06: Graph Engineering

Core Question: How is the work coordinated?

Real enterprise workflows are not single-agent loops. They are complex multi-agent choreographies involving specialized workers, parallel branches, and conditional handoffs.

Graph engineering structures this coordination as a stateful Directed Acyclic Graph (DAG) or cyclic finite state machine (using frameworks like LangGraph).

Key Engineering Responsibilities:

• Specialized Worker Topology: Deconstructing monolithic agents into focused micro-agents (e.g. a Planner Agent, a SQL Retrieval Agent, a Code Validator, and a Governance Sign-off Gate).
• Deterministic State Machines: Modeling agent workflows as strictly typed state graphs where nodes are Python functions and edges define conditional routing logic.
• Durable Checkpointing: Persisting execution graph state to persistent storage (e.g. PostgreSQL / Redis) after every node transition, enabling workflows to pause for asynchronous human review and resume without data loss.
• Parallel Fan-Out & Consensus: Launching multiple subagents concurrently across independent subtasks and aggregating their outputs with a synthesis supervisor.

Layer 07: Ontology Engineering

Core Question: What do concepts mean?

The final frontier of AI systems engineering—and the layer most frequently omitted in failed deployments—is ontology engineering.

Foundation models understand vocabulary; they do not understand your enterprise’s specific business semantics. If two internal systems use the word “Customer” to mean fundamentally different things (e.g. an authenticated billing entity in Stripe vs an anonymous lead in HubSpot), the agent will produce subtle, catastrophic business errors.

Ontology engineering defines the shared semantic data model, entity relationships, and domain invariants across the entire agent fleet.

Key Engineering Responsibilities:

• Enterprise Semantic Schema: Formalizing business entities, parent-child relationships, and lifecycle states into unified graph models.
• Context Grounding: Mapping unstructured user queries to explicit ontology nodes before tools are invoked (e.g. resolving natural language mentions to canonical CustomerUUID records).
• Cross-Agent Semantic Interoperability: Ensuring that when Agent A emits an artifact or state update, Agent B interprets the exact same semantic payload without ambiguity.
• Business Invariant Rules: Encoding non-negotiable domain axioms (e.g. “An Order cannot transition to Shipped without an approved Payment Authorization”).

The System Hierarchy at a Glance

Conclusion: Better Agents Need Better Systems

The era of AI as a standalone prompt is over.

True enterprise intelligence does not emerge from larger parameter counts alone. It emerges when a capable foundation model is wrapped in disciplined prompt contracts, fed clean contextual evidence, sandboxed by a secure execution harness, checked by self-healing verification loops, coordinated through deterministic state graphs, and grounded in a rigorous enterprise ontology.

Stop treating the LLM as the entire system. Build the other six layers.

This article is Series #5 of the Agent Junky build log. If you found this useful, share it with your engineering team or connect on LinkedIn.