Reference Stacks

Status: Living Document Last Updated: 2026-03-30

Overview

These are specific AI stack configurations - published, community-adopted, or industry-standardised - that illustrate how the Architecture view gets instantiated in practice. They range from industry-level conceptual models down to specific open-source tooling stacks. Each is described with its layer mapping, key design decisions, and trade-offs.

1. Five-Layer Industry Model

Origin: Converged consensus across cloud providers and analyst firms. This is one of the most widely referenced abstractions in enterprise AI architecture discussions.

Layers:

Applications   <- What users and systems interact with
Orchestration  <- Workflow, agent coordination, state
Models         <- Foundation models and domain-specific models
Data           <- Knowledge bases, RAG, vector stores
Infrastructure <- Compute, serving, networking

Key design decisions:

• Inference-first economics: optimise the serving layer for cost and latency rather than training
• Model plurality: multiple models in the models layer, routed by orchestration
• Governance as a cross-cutting concern across all five layers, not a separate box

Best for: Enterprise architecture conversations, vendor evaluation, and communicating across technical and non-technical stakeholders.

Limitations: At five layers it is more a communication model than a build model. It omits memory, planning, and execution as distinct concerns, which matters when you are designing real systems.

2. Agentic RAG

Origin: The evolution of the RAG pattern into a multi-step, agent-driven retrieval approach. It is now a baseline pattern for many production knowledge-augmented systems.

How it differs from classic RAG:

Stack mapping:

• Data & Knowledge layer: Vector store, document store, external search APIs
• Orchestration layer: A graph or workflow manager handles the retrieve-reason-retrieve loop
• Foundation Models layer: A reasoning model decides retrieval strategy; an embedding model encodes chunks
• Execution layer: Web search, API calls, and database queries act as retrieval tools
• Memory layer: Retrieval history informs subsequent queries within the same session

Key design decisions:

• The agent explicitly plans retrieval strategy before executing it
• Re-ranking results before passing them to the model often improves quality
• Source citation is treated as a first-class output, not an optional extra

Best for: Research assistants, documentation systems, compliance tools, and support agents that need access to dynamic or proprietary knowledge.

Limitations: More complex to build and debug than classic RAG; retrieval loops can become expensive if not bounded; prompt design matters a lot.

3. GStack

Origin: An open-sourced AI engineering workflow stack associated with Garry Tan and Y Combinator.

Core premise: The bottleneck to AI-assisted software delivery is not just model capability but process structure. Software engineering discipline can be encoded into reusable command flows that improve repeatability and throughput.

Stack mapping:

• Orchestration layer: Claude Code plus slash-command workflow structure
• Application layer: Command-driven phases for planning, building, reviewing, QA, shipping, and retros
• Execution layer: Browser automation and terminal execution
• Memory layer: Repo context, rules files, and CLAUDE.md-style orientation

Key design decisions:

• Process-first: the workflow structure is the product
• Reproducibility: the same command sequence should produce similar outcomes across tasks
• Rules-based memory: persistent repo-local context carries team knowledge forward

Best for: Engineering teams who want structured, high-throughput AI-assisted delivery.

Limitations: Strongly coupled to a specific style of working and to specific agent tooling.

4. Paperclip

Origin: A newer open-source "Company OS" concept for multi-agent work.

Core premise: The next bottleneck is coordination. Applying organisational structure - roles, delegation, context inheritance - to multi-agent systems can improve throughput and consistency.

Stack mapping:

• Orchestration layer: Org chart, ticketing, and delegation system
• Application layer: Role-based assignments (CEO, engineer, QA, marketer, and so on)
• Memory layer: Role discovery and inherited context from company to project to task
• Execution layer: HTTP-based communication across compatible agent runtimes
• Foundation Models layer: Model-agnostic

Key design decisions:

• Roles, not models, are the organising primitive
• Context flows top-down from organisation to project to task
• Standardised interfaces matter more than a single runtime choice

Best for: Teams experimenting with more complex multi-agent coordination across concurrent workstreams.

Limitations: Very new, coordination-heavy, and only worth the overhead when simpler approaches have clearly been outgrown.

5. Choosing a reference stack

No single stack is right for all contexts:

The most common mistake is adopting a framework before understanding which layer problem it solves. Map your problem to the architecture first, then select the tool or framework that fits that layer.

Related

• What is an AI Stack? - definition and context
• Architecture - the major layers of the stack
• Trade-offs - the main design decisions behind these choices
• Our View - where we currently think the practical value lies