The AI Agent Stack: Architecture Layers and Market Map

Research date: June 15, 2026
Scope: Active or influential open-source projects and commercial products with a public official website or repository.

How to read this map

There is no single “AI agent market.” There are several markets stacked on top of one another:

Agent products and hosts
User experience and agent interaction
Application and model SDKs
Agent frameworks and orchestration
Managed agent infrastructure and durable execution
Tools, integrations, protocols, retrieval, and memory
Sandboxed execution and computer use
Model gateways and routing
Model providers and inference runtimes
Compute, storage, and network

Security, identity, governance, observability, evaluation, and cost management cut across the entire stack.

Products often span several layers. This directory places each player where an architect would primarily evaluate or buy it. “Comprehensive” here means a broad, useful working set, not every GitHub repository or newly launched startup.

Layer 0: Agent products and hosts

This is the layer users operate directly. These products contain or connect to an agent runtime, but they are evaluated as finished coding agents, desktop agents, IDEs, assistants, or automation products.

Open-source and model-flexible coding agents

Commercial and vendor-native coding agents

Business and knowledge-work agent products

Layer 1: User experience and agent interaction

This layer turns backend agents into usable products. It handles chat, multimodal input, streamed events, generative UI, frontend tools, shared application state, approvals, and human intervention.

Agentic frontend frameworks and component systems

Self-hosted assistant shells

Voice and realtime-agent interfaces

Layer 2: Interaction and interoperability protocols

Protocols are not agent frameworks. They standardize boundaries between hosts, tools, agents, user interfaces, commerce systems, and external services.

Layer 3: AI application and model SDKs

These libraries normalize model access and application primitives such as streaming, structured output, multimodal input, tools, prompt management, and frontend state. Some overlap with the agent-runtime layer.

Layer 4: Agent frameworks, runtimes, and orchestration

This is the decision-loop layer. It coordinates models, tools, state, delegation, retries, approvals, and multi-agent workflows.

Code-first agent frameworks

Visual and low-code agent builders

Layer 5: Managed agent infrastructure and durable execution

This layer runs and operates agents in production. It provides hosting, session isolation, identity, scaling, durable state, scheduling, deployment, and operational controls.

Agent-native managed platforms

Durable workflow and background execution platforms

Layer 6: Tools, actions, integrations, and web intelligence

Agents need authenticated, governed access to business applications, APIs, browsers, search, and the public web.

Tool and integration platforms

Search, research, crawling, and browser data

Layer 7: Sandboxed execution and agent computers

This layer gives agents isolated machines, filesystems, processes, browsers, desktops, code interpreters, and preview environments.

General code and computer sandboxes

Browser and desktop computer-use infrastructure

Layer 8: Memory, retrieval, context, and knowledge

This layer turns stateless model calls into systems that can remember users, retrieve organizational knowledge, and maintain durable context.

Agent memory and context engines

Retrieval and document processing frameworks

Vector and hybrid-search databases

Layer 9: Observability, evaluation, testing, and prompt operations

Traditional logs tell you whether code crashed. Agent observability must also explain model decisions, tool calls, trajectories, quality, cost, regressions, and user outcomes.

End-to-end observability and evaluation platforms

Evaluation and testing frameworks

Layer 10: Security, identity, guardrails, and governance

Agent security includes prompt injection, data leakage, unsafe output, excessive permissions, tool misuse, insecure MCP servers, identity delegation, policy enforcement, and auditability.

Runtime guardrails and open frameworks

Agent and GenAI security platforms

Identity and authorization for agents

Layer 11: Model gateways, routers, and inference control planes

Gateways normalize providers and add routing, fallbacks, caching, budgets, keys, policy, logging, and usage control. They do not replace an agent runtime.

AI-native gateways and model routers

API gateways with AI capabilities

Layer 12: Model providers, inference clouds, and local runtimes

This is where model inference occurs. Some providers sell proprietary models, some host open models, and some supply inference software for your own compute.

Foundation-model providers and model platforms

Hosted inference for open and custom models

Self-hosted inference runtimes

Layer 13: Compute, storage, network, and deployment substrate

Every upper layer eventually runs on conventional infrastructure. The agent ecosystem does not remove this layer; it adds more dynamic workloads, secrets, egress, state, and isolation requirements.

Where Goose and OpenCode sit

Goose and OpenCode are best understood as agent products/hosts, not merely SDKs:

User
  |
  +-- Goose desktop / CLI / API
  |     +-- agent loop
  |     +-- model-provider adapters
  |     +-- MCP extensions
  |     +-- built-in code and shell tools
  |     +-- recipes, scheduling, subagents, and ACP delegation
  |
  +-- OpenCode terminal / desktop / IDE
        +-- client/server agent architecture
        +-- model-provider adapters
        +-- LSP-aware coding tools
        +-- permissions and custom agents
        +-- MCP and SDK integration

They compete most directly with Claude Code, Codex, Gemini CLI, Cline, Roo Code, Kilo Code, Aider, Continue, and OpenHands. They do not directly replace an agent deployment platform such as AgentCore, a sandbox such as Daytona, a frontend framework such as CopilotKit, or a gateway such as LiteLLM.

Goose is broader and more automation-oriented: it is positioned as a general-purpose local agent with recipes, extensions, scheduling, and the ability to conduct other agents through ACP. OpenCode is more deliberately centered on the terminal/IDE software-development experience and a provider-neutral client/server architecture.

Common stack combinations

Open-source local coding agent

OpenCode or Goose
  -> MCP tools
  -> OpenRouter or LiteLLM
  -> Anthropic, OpenAI, Gemini, Qwen, or local Ollama/vLLM

Embedded enterprise copilot

CopilotKit
  -> LangGraph, Strands, Microsoft Agent Framework, or OpenAI Agents SDK
  -> Composio, Arcade, or internal MCP servers
  -> Mem0, Zep, or a vector database
  -> AgentCore, Foundry Agent Service, or Vertex Agent Engine
  -> model gateway
  -> model provider

Secure coding or data-analysis agent

Product UI
  -> agent framework
  -> Daytona, E2B, Runloop, or another sandbox
  -> repository, data, tests, and preview server
  -> observability and evaluation platform
  -> gateway and models

Fully self-hosted stack

Open WebUI or LibreChat
  -> LangGraph, PydanticAI, Mastra, or Strands
  -> self-hosted MCP servers
  -> PostgreSQL/pgvector, Qdrant, or Weaviate
  -> Langfuse and promptfoo
  -> NeMo Guardrails and OPA
  -> LiteLLM
  -> vLLM, SGLang, Ollama, or llama.cpp
  -> Kubernetes or conventional compute

Selection checklist

Do not choose one winner across the whole landscape. Choose one or two candidates per required layer:

1. Is the deliverable a finished agent product or a framework for building one?
2. Is the primary interface an IDE, terminal, web application, voice channel, or API?
3. Do you need model portability or a vendor-native experience?
4. Must workflows survive restarts, wait for humans, and run for hours or days?
5. Will the agent execute arbitrary code or operate a browser?
6. Which tools require delegated user identity rather than service credentials?
7. What memory is durable, deletable, attributable, and policy-governed?
8. How will you evaluate full trajectories, not only final text?
9. Where are prompt injection and tool authorization enforced?
10. Do you need self-hosting, air-gapping, regional control, or managed operations?
11. Which protocol boundaries should remain portable: MCP, A2A, AG-UI, or ACP?
12. What happens when the model, tool, browser, sandbox, or human approval times out?

Practical shortlist by problem

Maintenance notes

• This market changes rapidly. Recheck status, licensing, pricing, and product names before procurement.
• Open-source client libraries and self-hosted servers from the same company can use different licenses.
• A protocol implementation claim does not guarantee full interoperability; test the exact client/server pair.
• “Memory” may mean message history, semantic facts, a knowledge graph, checkpoint state, or durable workflow state. These are different products and data-governance obligations.
• “Agent platform” is heavily overloaded. Always identify whether it supplies authoring, hosting, execution, tools, UI, models, or only a control plane.
• The earlier detailed comparison remains available in Vercel AI SDK vs TanStack AI and adjacent platforms.