Visual map

Clickable map

A more visual way to see the ecosystem: context comes in, tools make action possible, agents decide what to do, and hosts mediate the work.

System sketch

Inputs, loop, interface, controls

Most AI tooling fits somewhere in this shape. Some parts feed the agent, some parts let it act, some parts run the loop, and some parts keep the work visible and controlled.

Feeds the system

Starting point Model access Subscriptions, APIs, routers, local endpoints Connectors Protocols MCP, OpenAPI, LSP, function calling Action surface Tools CLIs, APIs, scripts, browsers
Runs the work Agent loop State, planning, tool selection, retry logic

Shapes the work

Human surface Host / UI Chat, CLI, IDE, approvals Work plane Orchestration Queues, subagents, handoffs Control plane Governance Policy, logs, evals, cost controls
Skills, hooks, plugins, and wrappers Reusable behavior that sits around the tools and changes how the agent uses them.

First branch

Before the stack, choose how you reach the model

Human surface Subscription Start with a product when you want the assistant experience first. Then enter the labs through the bootstrap step. Build surface Direct API Start here when you want a stable interface for code, tools, and agents. Usually this means you can skip to bootstrap step 2. Managed cloud Platform Start here when model access comes bundled with deployment, identity, and enterprise controls. Treat the deployed endpoint or platform surface as your starting interface. Comparison surface Router Use a routed API when you want to swap and compare models quickly. Keep prompts and evals stable while you compare. Local surface Local host Start here when you want local control and are willing to manage the runtime. Separate the runtime, the artifact, and the hardware.

Decision tree

Classify by the job it does

Provides model access Subscriptions, APIs, platforms, routers, local hosts Connects systems MCP, OpenAPI, LSP Takes action Tools, CLIs, APIs Packages behavior Skills, hooks, wrappers
What job does it do?
Decides next steps Agent runtime Mediates humans Host, CLI, IDE, chat UI Coordinates work Orchestration Controls risk Governance, evals, logs

Layer coverage

Where real tools sit on the stack

This is more useful than a generic stack because it shows overlap. Local CLI agents, protocol adapters, task graphs, workspace coordinators, and persistent assistant platforms do not live in one neat box.

Primary fit Touches this layer —No meaningful fit
Layer Local host agent Protocol adapter Task graph Workspace coordinator Persistent assistant
Governance Approvals — — Watchdogs Sandboxing
Orchestration — — Ready tasks Multi-agent work Routing + schedules
Host / UI CLI + desktop — — Workspace manager CLI + channels
Agent runtime Agent loop — — Launches agents Persistent loop
Packaging Extensions — — Hooks + roles Skills
Protocols Uses MCP Protocol layer MCP package — MCP / gateway
Capabilities Calls tools Exposes tools bd CLI gt CLI Toolsets
Foundation Model access + files — Dolt state Project state Workspace + memory

Object shortcuts

Click the object, not the category

MCP host/client/serverWho talks to whom. MCP tools/resources/promptsWhat servers expose. MCP transportsStdio and HTTP. Model access pathsSubscription, API, router, local host, artifact. Local hosting splitPublisher, artifact, runtime, hardware, endpoint. SkillsProcedural memory. HooksLifecycle automation. WrappersInterface adapters. Agent typesRuntime, framework, CLI, persistent system. Memory and coordinationBeads, Gas Town, OpenClaw, Hermes. CLI agentsGoose, Aider, OpenCode, and friends. Build the piecesToy versions of the stack. Wire the piecesA tiny capstone flow.