{
  "id": "page:agent-generate-universal-agentic-stack-layers",
  "_kind": "Page",
  "_file": "wiki/agent-generate/universal-agentic-stack/layers.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "Universal Agentic Stack Layers",
    "displayName": "Universal Agentic Stack Layers",
    "slug": "agent-generate/universal-agentic-stack/layers",
    "articlePath": "wiki/agent-generate/universal-agentic-stack/layers.md",
    "article": "# Universal Agentic Stack Layers\n\nDerived from `graph/stack-layers/layers`. There are no modeled nested layer nodes; responsibilities/examples/fit notes are attributes on each top-level layer.\n\n## Quick navigation\n\n| Layer | Best question to ask |\n|---|---|\n| 1 Model | What model artifact is this, independent of who serves it? |\n| 2 Provider | Who serves it, with what quota, auth, and deployment posture? |\n| 3 Transport | What protocol or client path actually carries requests? |\n| 4 Agent-Core | Where does the decision loop or graph logic live? |\n| 5 Agent-Runtime | What hosts tools, state, approvals, and streaming around that loop? |\n| 6 Agent-Platform | What installs, extends, launches, and distributes the runtime? |\n| 7 Workspace | What working context is materialized for the agent? |\n| 8 Execution | Where do commands and side effects actually run? |\n| 9 Sandbox | What policy boundary constrains those side effects? |\n| 10 Interaction | What actions are exposed to users or systems? |\n| 11 Presentation | How are those actions and results rendered? |\n\n## How to read this page\n\n- Use the `Scope` line to identify the core boundary.\n- Use `Responsibilities` to see what belongs inside that boundary.\n- Use `Fit note` to avoid the most common category mistake.\n- If you are comparing product shapes, skim [`07-comparison-matrix.md`](./07-comparison-matrix.md) first and then return here.\n\n## Layer 11: Presentation\n\nThe presentation layer renders agent work to humans or downstream systems:\nterminal UI, CLI, web UI, IDE panel, API endpoint, JSON stream, structured\nevent log, or dashboard. Realized by `Presentation` instances such as TUI,\nCLI, web, IDE, and API surfaces.\n\n- Scope: Outermost rendering surface for humans or downstream systems.\n- Responsibilities:\n  - Render prompts, transcripts, plans, tool calls, approvals, and results.\n  - Provide human-readable and machine-readable output modes.\n  - Own layout, accessibility, theme, streaming display, and navigation affordances.\n- Examples:\n  - TUI, CLI, web app, IDE side panel, notebook/chat surface.\n  - REST/WebSocket API, JSON stream, structured event log, dashboard.\n  - LangGraph app UI, LangSmith trace view, custom workflow console.\n- Not this:\n  - the command vocabulary itself\n  - the approval logic behind an interaction\n- Fit note: Products can be headless and still fit the stack through an API or event\nstream presentation. Presentation can be supplied by a host IDE/web app\nrather than by the agent framework itself.\n- Source: `graph/stack-layers/layers/layer-11-presentation.yaml`\n\n## Layer 10: Interaction\n\nThe interaction layer contains the actions exposed through an agent\nsurface: slash commands, keybindings, prompt controls, editor widgets,\nvoice or multimodal triggers, review/approve/resume gates, collaborative\nactions, operational triggers, and telemetry affordances. Realized by\n`InteractionPrimitive` nodes and related trigger/command records.\n\n- Scope: Atomic user-agent and agent-system actions exposed by a surface.\n- Responsibilities:\n  - Expose commands, controls, triggers, approvals, and resumable interrupts.\n  - Translate human/system gestures into runtime or platform actions.\n  - Surface task state, telemetry, collaboration, and handoff controls.\n- Examples:\n  - Slash commands, keybindings, prompt controls, approve/reject interrupt.\n  - GitHub Action trigger, webhook trigger, editor widget, dashboard button.\n  - LangGraph human-in-the-loop review, edit, approve, resume controls.\n- Not this:\n  - layout, theming, or transcript rendering\n  - the runtime that carries out the action\n- Fit note: Interaction primitives are not presentation widgets by themselves; they are\nthe action vocabulary that a TUI, CLI, web UI, IDE, API, or automation host\nrenders and invokes.\n- Source: `graph/stack-layers/layers/layer-10-interaction.yaml`\n\n## Layer 9: Sandbox\n\nThe sandbox layer constrains `Execution`: filesystem allow/deny lists,\nnetwork allow/deny lists, binary allow/deny lists, environment and secret\nscope, audit-log policy, and policy evaluation point (pre-call,\ncontinuous, or post-call attestation). Coarse posture is captured by\nfilesystemPolicy and networkPolicy enums. Realized by `Sandbox` nodes.\n\n- Scope: Policy-enforcement perimeter around execution and side effects.\n- Responsibilities:\n  - Enforce filesystem, network, binary, secret, and environment policy.\n  - Record audit evidence and policy decisions around side effects.\n  - Define approval, escalation, and attestation boundaries for execution.\n- Examples:\n  - Read-only filesystem, workspace-write mode, network-disabled mode.\n  - Binary allow list, secret scope, approval-required command policy.\n  - Container, VM, OS sandbox, or hosted policy engine.\n- Not this:\n  - the shell or process runner itself\n  - the human-facing approval UI by itself\n- Fit note: Custom-agent frameworks may leave sandboxing entirely to the embedding\nhost. Production tools should model this layer explicitly even when users\nonly see a simple approval prompt.\n- Source: `graph/stack-layers/layers/layer-9-sandbox.yaml`\n\n## Layer 8: Execution\n\nThe execution layer hosts agent-driven tool calls and shell commands:\nlocal process, Docker container, SSH remote, Kubernetes pod, cloud\nfunction, direct host, or service-side executor. Execution posture includes\nprocess lifecycle, signal propagation, resource limits, isolation, network\npolicy, filesystem access, GPU access, and concrete runtime substrate.\nRealized by `Execution` nodes.\n\n- Scope: Invocation environment for agent-driven tools, commands, and side effects.\n- Responsibilities:\n  - Start, stream, interrupt, and stop tool/shell/process execution.\n  - Own process lifecycle, resource limits, environment variables, and mounts.\n  - Route side effects to local, remote, container, or hosted executors.\n- Examples:\n  - Local shell, Docker, SSH remote, Kubernetes pod, GitHub Actions runner.\n  - Browser automation worker, notebook/kernel executor, cloud function.\n  - LangGraph tool node executing inside a host application runtime.\n- Not this:\n  - the repo or mounted files being operated on\n  - the policy system that restricts execution\n- Fit note: Frameworks often delegate execution to user-defined tools. Hosted agent\nproducts may make this layer invisible but still need it for auditing and\npolicy mapping.\n- Source: `graph/stack-layers/layers/layer-8-execution.yaml`\n\n## Layer 7: Workspace\n\nThe workspace is the materialized working directory or project context the\nagent operates against — a git worktree, clone, symlinked overlay,\nIDE-managed project, mounted remote, or virtual ephemeral workspace.\nWorkspace posture includes materialization, storage backend, indexing,\ngit hooks, artifact scope, and multi-tenant policy. Realized by `Workspace` nodes.\n\n- Scope: Materialized working context the agent reads, writes, indexes, and reasons over.\n- Responsibilities:\n  - Materialize project files, indexes, artifacts, and session-visible state.\n  - Define git/worktree, mounting, overlay, and persistence behavior.\n  - Bound what files, generated outputs, and caches belong to the agent task.\n- Examples:\n  - Local repository, remote clone, IDE project, container-mounted workspace.\n  - Git worktree, generated artifact directory, vector/code index, cache scope.\n  - LangGraph app state when backed by project files or persisted stores.\n- Not this:\n  - the process that runs the command\n  - the UI surface that renders the result\n- Fit note: Some products are read-only and omit this layer. Others delegate workspace\nownership to an IDE, CI runner, hosted environment, or user shell.\n- Source: `graph/stack-layers/layers/layer-7-workspace.yaml`\n\n## Layer 6: Agent-Platform\n\nThe platform wraps one or more `AgentRuntimeImpl`s with extension,\ndistribution, and operator concerns: installed plugins, installed skills,\nnative extension formats, subagents, tool servers, channel adapters,\nlaunch/config registries, identity, marketplace, and update channels.\nRealized by `AgentPlatformImpl` instances.\n\n- Scope: Extension, distribution, launch, and ecosystem surface around runtimes.\n- Responsibilities:\n  - Load installed plugins, installed skills, commands, hooks, subagents, and tool servers.\n  - Broker capability profiles, launch profiles, identity, marketplaces, and updates.\n  - Bridge channels such as MCP, HTTP/SSE, A2A, chat, mailbox, and gateway adapters.\n  - Publish the platform-specific extension contract and installation scopes.\n- Examples:\n  - Claude plugins/skills, Codex/Gemini/OpenCode extension packages, a5c plugins.\n  - LangGraph Platform, LangSmith deployment, RemoteGraph, hosted graph operations.\n  - Skill directories, plugin registries, marketplace manifests, MCP server configs.\n- Not this:\n  - a single tool invocation inside one running session\n  - the inner decision loop itself\n- Fit note: Installed plugins and skills belong explicitly in this layer. Products may\nexpose a platform without owning a model/provider, or may hide platform\nservices inside an IDE or hosted control plane. a5c platform is modeled as\na unified same-layer extension host, not a Pi wrapper.\n- Source: `graph/stack-layers/layers/layer-6-agent-platform.yaml`\n\n## Layer 5: Agent-Runtime\n\nThe runtime hosts an agent process around the core: built-in tools,\ninternal session state, tool registry, hook sockets, approval primitives,\nsubprocess execution posture, streaming, output guards, and runtime\nidentity. Realized by `AgentRuntimeImpl` instances.\n\n- Scope: Host process and operational runtime for an agent core.\n- Responsibilities:\n  - Maintain internal session and transcript state.\n  - Provide built-in tools, dynamic tool discovery, hooks, and approvals.\n  - Manage subprocess/tool execution posture and streaming events.\n  - Enforce runtime output, resume, and journal/event contracts.\n- Examples:\n  - LangGraph checkpointer/store, thread state, interrupts, streaming runtime.\n  - Claude Code/Codex/Gemini CLI process runtimes.\n  - a5c unified runtime, Pi-compatible session profiles, adapters remote runtime.\n  - Built-in file/shell/search tools, approval gates, session files.\n- Not this:\n  - a package installer or marketplace\n  - the trained model or provider endpoint\n- Fit note: Frameworks can leave runtime to the host app; CLI products often combine\ncore and runtime in one binary. a5c runtime is modeled as a unified\nsame-layer implementation that can map Pi, Claude, Codex, LangGraph, and\nadapters runtime profiles without depending on one of them.\n- Source: `graph/stack-layers/layers/layer-5-agent-runtime.yaml`\n\n## Layer 4: Agent-Core\n\nThe agent-core layer drives an inference turn or graph step end-to-end:\nprompt/context assembly, state transition, tool dispatch, child-agent\nhandoff, message materialization, result synthesis, and stop detection.\nRealized by `AgentCoreImpl` instances.\n\n- Scope: Inner loop and graph/turn semantics for one agent brain.\n- Responsibilities:\n  - Define loop, graph, or state-machine iteration semantics.\n  - Assemble prompt/context and normalize message/state materialization.\n  - Dispatch tools/subagents and synthesize terminal results.\n  - Detect stops, interrupts, graph terminal states, and budget exits.\n- Examples:\n  - LangGraph StateGraph, graph nodes/edges/state, create_agent routing.\n  - Claude Code/Codex/Gemini CLI loop cores.\n  - a5c unified core and Pi-compatible tool-use loop profiles.\n  - Tool dispatch, stop detection, context-window handling, result envelopes.\n- Not this:\n  - the transport client that calls the provider\n  - plugin installation or ecosystem distribution\n- Fit note: This is where custom agent builders fit first. A product may expose only a\ncore library without owning runtime, platform, workspace, or presentation.\na5c's core is modeled as a unified same-layer contract, not as built on top\nof Pi; Pi is a compatibility profile.\n- Source: `graph/stack-layers/layers/layer-4-agent-core.yaml`\n\n## Layer 3: Transport\n\nThe protocol and client path that carries inference requests from an\n`AgentCoreImpl` to a `Provider`, plus optional proxies or gateways that\ninterpose between them. This layer is modeled as one top-level layer; wire\nprotocol, client library, and proxy behavior are responsibilities/examples,\nnot nested layer nodes.\n\n- Scope: Wire and client path between agent core and provider.\n- Responsibilities:\n  - Encode request, response, streaming, tool-call, and error payloads.\n  - Run the in-process client or adapter that speaks the provider protocol.\n  - Optionally route through a proxy, gateway, recorder, or policy interposer.\n- Examples:\n  - OpenAI Responses, OpenAI Chat Completions, Anthropic Messages, Gemini GenerateContent.\n  - HTTP, SSE, WebSocket, gRPC, OpenAI-compatible gateways.\n  - LangChain chat-model adapters and transport clients.\n- Not this:\n  - the provider organization behind the endpoint\n  - the graph or loop that decides what to send\n- Fit note: Custom-agent frameworks often hide transport behind model abstractions.\nGateway products may occupy mostly this layer while delegating core/runtime\nbehavior upward.\n- Source: `graph/stack-layers/layers/layer-3-transport.yaml`\n\n## Layer 2: Provider\n\nThe hosted-inference vendor or self-hosted serving boundary that exposes a\n`ModelVersion` over an endpoint. Provider posture covers auth scheme, rate\nlimits, regions, fine-tuning availability, and SLA — distinct from the wire\nprotocol (Layer 3) and the agent-side core that consumes it (Layer 4).\n\n- Scope: Hosted or self-hosted serving boundary.\n- Responsibilities:\n  - Serve model versions through authenticated endpoints.\n  - Own availability, regions, quotas, rate limits, billing, and deployment posture.\n  - Publish provider-specific model and endpoint capabilities.\n- Examples:\n  - Anthropic, OpenAI, Google, Azure OpenAI, AWS Bedrock, OpenRouter.\n  - Self-hosted vLLM, Ollama, llama.cpp, or custom inference gateway.\n  - Auth scheme, region, quota, rate-limit, and SLA records.\n- Not this:\n  - the request protocol itself\n  - the agent logic above the provider\n- Fit note: LangChain/LangGraph apps usually choose providers through model adapters\nrather than owning this layer. Gateways may specialize here while leaving\nhigher layers to another product.\n- Source: `graph/stack-layers/layers/layer-2-provider.yaml`\n\n## Layer 1: Model\n\nThe trained model artifact itself — weights, tokenizer, inference graph —\nindependent of any provider that serves it. Concrete realizations are\n`ModelFamily` and `ModelVersion` nodes. Capability claims about token\nlimits, modalities, native tools, and reasoning posture are bound to\n`ModelVersion`, not to providers or transports.\n\n- Scope: Trained artifact and declared capability surface.\n- Responsibilities:\n  - Preserve model family/version identity.\n  - Declare token, modality, reasoning, tool, and output-shape capabilities.\n  - Separate model-native behavior from provider/runtime behavior.\n- Examples:\n  - Model family and version records.\n  - Context window and output token limits.\n  - Native tool-use, reasoning, vision, audio, and embedding support.\n- Not this:\n  - provider-specific quotas or deployment regions\n  - runtime behavior around tool calls and approvals\n- Fit note: Custom-agent apps may expose model choice directly or hide it behind a\nprovider/model configuration. Local inference collapses Model and Provider\noperationally, but the graph keeps them separate.\n- Source: `graph/stack-layers/layers/layer-1-model.yaml`\n",
    "documents": [
      "layer:1-model",
      "layer:2-provider",
      "layer:3-transport",
      "layer:4-agent-core",
      "layer:5-agent-runtime",
      "layer:6-agent-platform",
      "layer:7-workspace",
      "layer:8-execution",
      "layer:9-sandbox",
      "layer:10-interaction",
      "layer:11-presentation"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:1-model",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:2-provider",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:3-transport",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:4-agent-core",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:5-agent-runtime",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:6-agent-platform",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:7-workspace",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:8-execution",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:9-sandbox",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:10-interaction",
      "kind": "documents"
    },
    {
      "from": "page:agent-generate-universal-agentic-stack-layers",
      "to": "layer:11-presentation",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:agent-generate-universal-agentic-stack",
      "to": "page:agent-generate-universal-agentic-stack-layers",
      "kind": "contains_page"
    }
  ]
}