
The agentic AI infrastructure stack in 2026: what to use at each layer
Building an agent is now a stack decision, not a model decision. Eight layers, the two or three tools that lead each one, and what we would pick for a small team.
A year ago, building an agent meant picking a model and writing a loop. In 2026 the model is the easy part. The hard parts are around it: how the agent reaches tools, where its code runs safely, how a ten-minute task survives a crash, what it remembers, and how you find out why it did something stupid. Each of those is now its own layer with its own vendors. This is the map.
The short version
Start with a framework and a gateway. Add a sandbox the day your agent runs code, durable execution the day a task takes longer than one request, and tracing on day one. Memory and browser infrastructure come last, when you can name the problem they solve.
1. Protocols: how agents reach tools
- MCP (Model Context Protocol) is the default way to connect an agent to tools and data. Every major agent client speaks it, which means a tool you expose once works in Claude, ChatGPT, Cursor, Copilot and the rest. The July 2026 spec made servers stateless; we covered what changed. Browse working servers in our MCP directory.
- A2A (Agent2Agent) covers the other direction: one agent delegating to another agent over the network. Useful when agents belong to different teams or companies. Most single-team projects do not need it yet.
- Agent Plugins packages skills, commands and MCP servers into one folder that any compatible client can load. See our Agent Plugins 1.0 explainer.
2. Frameworks and SDKs: the agent loop
This is where you write the agent itself: the loop of calling a model, running tools and deciding when to stop.
- Claude Agent SDK. The harness behind Claude Code, released as a library. The strongest choice if you build on Claude and want file editing, tool use and context management that already work in production.
- [OpenAI Agents SDK](/tools/openai-agents-sdk). Small and readable, with handoffs between agents, guardrails and built-in tracing. Best on OpenAI models.
- Google ADK (Agent Development Kit). Google's framework, tuned for Gemini and Google Cloud deployment, with support for other models.
- [LangGraph](/tools/langgraph). Agents as explicit state graphs with checkpoints and human approval steps. More boilerplate, but the most control when a workflow has to be predictable.
- [CrewAI](/tools/crewai). Role-based teams of agents. Quick to get a multi-agent demo running; needs firm stopping rules to avoid agents delegating in circles.
- Vercel AI SDK and [Mastra](/tools/mastra). The two leading TypeScript options. The AI SDK covers model calls, tool calling, streaming and UI; Mastra adds workflows, memory and evals on top in an agent-first framework.
3. Durable execution: surviving long tasks
An agent task that takes ten minutes will eventually hit a timeout, a deploy or a crashed worker. Durable execution records each step, so a task resumes where it stopped instead of starting over and paying for every model call twice.
- [Temporal](/tools/temporal). The battle-tested option, used far beyond AI. Powerful, with a learning curve: workflow code must be deterministic, and side effects live in separate activities.
- [Inngest](/tools/inngest). Event-driven durable functions written as plain steps. Lighter to adopt than Temporal for most web teams.
- Vercel Workflow. Durable steps in TypeScript for apps already on Vercel, with retries, sleeps and pause-and-resume built in.
4. Sandboxes: running code safely
The moment your agent writes and runs code, it needs somewhere that is not your server. Sandboxes give it an isolated machine that starts in seconds and is thrown away afterwards.
- [E2B](/tools/e2b). Purpose-built sandboxes for AI-generated code on lightweight microVMs, with SDKs for Python and JavaScript. The default choice for code interpreters.
- Vercel Sandbox. Firecracker microVMs on Vercel's platform, generally available since January 2026. A natural fit if the rest of your app is already there.
- Daytona focuses on very fast-starting sandboxes for agents, and [Modal](/tools/modal) is the pick when the code needs GPUs or heavy Python workloads.
5. Browser infrastructure: agents on the web
- [Browserbase](/tools/browserbase). Hosted headless browsers for agents, with session recording and its Stagehand framework for writing browser actions in plain language.
- Steel. An open-source browser API you can self-host.
Before reaching for a browser, check for an API or an MCP server. A browser is the slowest, most expensive and most fragile way for an agent to get data.
6. Memory: what the agent keeps between sessions
- Mem0. A memory layer that extracts facts from conversations and retrieves them later. The most common drop-in choice.
- Letta. From the team behind MemGPT: stateful agents that manage their own memory blocks. Works best with strong models.
- [Zep](/tools/zep). Memory built on a temporal knowledge graph, so it tracks how facts change over time, not just what was said.
Most agents do not need a memory product on day one. A table of user preferences and a search over past tasks covers more than people expect.
7. Observability and evals: knowing why it failed
Agents fail quietly: a wrong tool call three steps back, a retry loop, a confident answer built on an empty search. Tracing every step is the only way to see it.
- [Langfuse](/tools/langfuse). Open source and self-hostable, covering tracing, prompt management and evals. The default if you want to own your data.
- [LangSmith](/tools/langsmith). LangChain's hosted platform, the obvious choice if you build on LangGraph.
- [Braintrust](/tools/braintrust). Evals-first: datasets, scoring and comparing prompt or model changes before they ship.
- [Arize Phoenix](/tools/arize-phoenix). Open source and built on OpenTelemetry, so traces fit into observability you may already run.
8. Model gateways: one API for many models
- [OpenRouter](/tools/openrouter). One API key for hundreds of models, including free ones. A warning from experience: free model slugs get retired without much notice, so never hard-code one as your only option.
- Vercel AI Gateway. One endpoint across providers, with fallbacks, budgets and observability, integrated with the AI SDK.
- LiteLLM. An open-source proxy that puts many providers behind the OpenAI API format. The self-hosted choice.
What we would pick for a small team
- A framework that matches your language and main model: Claude Agent SDK or OpenAI Agents SDK in Python, the AI SDK or Mastra in TypeScript.
- A gateway with at least two providers behind it from the start.
- Tracing from the first day, with Langfuse if you want to self-host.
- A sandbox the first time the agent runs code it wrote.
- Durable execution once a single task outlives a request.
We learned the gateway lesson the hard way. Kapyn's own news pipeline runs on a chain of eight model providers, and in October we found most of its spend going to re-summarising articles it had already deleted. That story is here.
Kapyn tracks releases across all of these layers as they happen. Open the feed, or browse the tools directory and MCP servers.
Find these on the Radar
Every tool here lives on Kapyn Radar. Save the ones that fit into a Loadout and find them again.

