State of Agents: May 2026

Attempting to map the agentic framework/infra landscape

Originally published at: https://offsquare.substack.com/p/state-of-agents-may-2026

As the founding engineer at an AI-focused venture fund, I work with many different companies, including internal incubation companies that we help create and launch. These vary widely in language, framework, infrastructure maturity, and product surface area.

For that reason, my goal isn’t to find a single “best” agent framework, but to identify a flexible, portable agent stack whose lessons transfer across projects. The ideal stack should make it easy to move between Python and TypeScript, swap model providers, preserve observability, avoid unnecessary cloud setup, translate between local/dev/prod environments, and prevent every company from being locked into one vendor’s end-to-end agent platform.

Cloud agnosticism matters to me more than it does to most projects. If the recommended stack requires a company to adopt Bedrock, Vertex, Kubernetes, or a large AWS/GCP/Azure setup, it won’t be usable by many of the companies I work with. They may already be on AWS, where a GCP-centric stack doesn’t translate. By contrast, more focused providers like Modal, Logfire, OpenRouter, Langfuse, and similar tools can usually be adopted regardless of whether the company’s main app runs on Vercel, AWS, GCP, Azure, Fly, Render, Kubernetes, or something else. The goal is to keep the agent infrastructure portable enough that it fits into the company’s existing deployment stack instead of forcing a major cloud decision.

The core recommendation is to standardize around portable model access, language-native agent code, OpenTelemetry-compatible observability, durable execution, and lightweight compute.

Agent Stack

The agent stack has six separable layers:

The preferred stack changes by use case:

This is more pragmatic than treating Temporal, LangGraph, or any other durable runtime as the default for every production agent.

For most agents, the ergonomic default is the OpenAI Agents SDK. Add E2B or Vercel Sandbox when the agent needs a place to execute code, install packages, manipulate files, or hold per-session state — Vercel Sandbox is the natural fit for Vercel/Next.js teams, E2B is the more provider-neutral default. Reach for Modal when the workload actually needs GPUs, beefier hardware, gVisor isolation, or Python-heavy ML compute. Add Vercel Workflows (Vercel/Next.js teams) or Temporal (selectively) when durable execution matters.

E2B, Vercel Sandbox, and Modal all integrate cleanly with the OpenAI Agents SDK, so the framework choice doesn’t lock you into any single compute layer.

Tier 1: Non-Production / Local / Exploratory Agents

For one-off scripts, internal tools, local experiments, and non-production-facing workflows, use:

OpenAI-compatible gateway + OpenAI Agents SDK + Logfire

This is the right stack when the agent is mostly request/response, has limited side effects, and doesn’t need durable retries or long-running state.

OpenAI Agents SDK is especially attractive here because it includes built-in tracing for LLM generations, tool calls, handoffs, guardrails, and custom events out of the box.

Useful references:

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
• OpenAI Agents SDK quickstart: https://developers.openai.com/api/docs/guides/agents/quickstart
• OpenAI Agents SDK tracing: https://openai.github.io/openai-agents-python/tracing/
• Logfire OpenAI integration: https://pydantic.dev/docs/logfire/integrations/llms/openai/

Tier 2: Lightweight Production Agents

My definition of “lightweight” is: agents that run for up to several minutes, have manageable retry and state management needs, and don’t have critical business impact if they fail occasionally. For these use cases, default to the same stack as Tier 1, but add a sandbox layer (E2B or Vercel Sandbox) for code execution, tool use, and per-session state:

OpenAI-compatible gateway + OpenAI Agents SDK + Logfire + E2B or Vercel Sandbox

For very lightweight TypeScript/web workloads, a secondary option is:

OpenAI-compatible gateway + OpenAI Agents SDK or Vercel AI SDK + Logfire + Vercel serverless + Vercel Sandbox

Most agent sandboxes have modest hardware needs (a few vCPUs and a few GB of RAM); the properties that matter are startup time, ergonomics, and per-session state. Both E2B and Vercel Sandbox fit that shape — see the Layer-by-Layer compute section for a deeper comparison and the heavier-compute escalation to Modal.

In this tier, it usually isn’t necessary to add a durable execution framework. Vercel Functions cap out at 300 seconds (Hobby) / 800 seconds (Pro/Enterprise) per invocation, which is fine for most short agent loops but a problem for longer-running ones — that’s where Tier 3’s durable layer (Vercel Workflows or Temporal) comes in.

Tier 3: Durable Long-Running / High-Stakes Agents

Use a durable execution layer when parts of the workflow are long-running, fragile, business-critical, or stateful enough that homegrown retry and checkpointing logic becomes risky. There are two solid defaults here: Vercel Workflows for Vercel/Next.js teams, and Temporal for platform-agnostic or deeply mission-critical workflows.

The stack becomes:

OpenAI-compatible gateway + OpenAI Agents SDK + Vercel/Temporal Workflows + Logfire/OTLP + E2B or Vercel Sandbox (with Modal for GPU/heavy compute)

Vercel Workflows as a hybrid orchestrator

Vercel Workflows (GA April 2026) sits between a generic compute layer and a durable execution framework. It gives you durable agent loops via use workflow / use step directives, sleeps and hooks that pause for minutes/days/months without consuming compute, resumable streams that survive a client reconnect, and deployment pinning so workflows keep running on the deployment they started on.

The key thing is that Vercel Workflows is the agent runtime, not the agent body. Workflow steps run on Vercel Functions / Fluid Compute and inherit those limits — no GPUs, modest CPU/RAM, and per-step caps (~300s Hobby, ~800s Pro/Enterprise). Heavy work still belongs in Modal, and code-execution/tool-use sandboxes still belong in E2B or Vercel Sandbox.

For a Next.js app, that produces a coherent stack:

For teams not on Vercel — or for workflows that need a language-agnostic, mission-critical engine with mature worker control, heartbeats, and explicit activity modeling — Temporal remains the right choice.

Temporal as a durable boundary

Temporal doesn’t need to replace the whole agent framework. A better, more incremental migration path is to use OpenAI Agents SDK for the main agent loop, then wrap with Temporal as needed.

For example:

This lets the team apply Temporal only where its durability semantics matter, while sandbox and heavy-compute concerns continue to live in E2B/Vercel Sandbox and Modal respectively.

Temporal makes sense when a workflow has one or more of these properties:

The goal isn’t to make every agent step a Temporal workflow — it’s to identify the parts of the agent graph where durability actually matters and put Temporal boundaries there. Sometimes the entire agent workflow is durable; more often, only one or two critical steps need Temporal while the rest stays in the more ergonomic OpenAI Agents SDK.

Temporal’s local dev experience is reasonable for teams already using Docker Compose. A local Temporal service can sit alongside Postgres, Redis, or S3-compatible storage:

This gives teams a local Temporal service and Web UI without requiring Temporal Cloud or running production infrastructure for small experiments.

Rule of thumb:

Use OpenAI Agents SDK for the agent loop. Use Vercel Workflows (Vercel/Next.js teams) or Temporal (selectively) for durable orchestration. Use E2B or Vercel Sandbox for the agent’s sandbox. Use Modal for compute-heavy execution and GPUs.

Useful references:

• Temporal local development server: https://docs.temporal.io/develop/run-a-development-server
• Temporal CLI server docs: https://docs.temporal.io/cli/server
• Temporal Docker image: https://hub.docker.com/r/temporalio/temporal
• Temporal OpenAI Agents SDK integration: https://docs.temporal.io/ai-cookbook/openai-agents-sdk-python
• Temporal agentic loop example: https://docs.temporal.io/ai-cookbook/agentic-loop-tool-call-openai-python
• Temporal Python integrations: https://docs.temporal.io/develop/python/integrations
• Temporal TypeScript integrations: https://docs.temporal.io/develop/typescript/integrations

Why Not Default to Temporal?

As powerful as Temporal is, it adds complexity, latency, and one more layer of abstraction between the agent and the user/developer. Its local development story is workable, but still less ergonomic than running a pure SDK-based agent locally. Its integrations are useful, but not uniformly mature across Python and TypeScript — the TypeScript AI SDK integration in particular should be treated with caution while it’s still in preview.

The latency cost is real. Every Temporal-backed step crosses the boundary between application code and the Temporal worker/server: workflow tasks, activity tasks, and event-history persistence all add round trips that a pure in-process agent loop doesn’t pay. For short, latency-sensitive agent steps, that overhead can be larger than the work being durable-wrapped in the first place.

Temporal’s abstractions also shift how the developer reasons about the agent: code splits into workflows and activities, side effects must be pushed to activity boundaries, retries and timeouts move into Temporal config, and debugging often means reading event histories rather than stack traces. That’s a worthwhile trade for genuinely durable workflows, but it’s a meaningful tax on the day-to-day developer and user experience when the workflow doesn’t actually need durability.

For lightweight production agents, it isn’t a huge lift to build basic retry, state hints, checkpointing, and error recovery directly in Python or TypeScript. If the workflow only runs for a few minutes and occasional failures are acceptable or easily recoverable, Temporal is more overhead than value.

The better escalation path is:

Each layer earns its place by solving a specific problem: OpenAI Agents SDK for building the agent, E2B/Vercel Sandbox for a sandbox to act inside, Modal for heavy compute or GPUs, Vercel Workflows or Temporal for durable execution. Don’t pull in any of them before the corresponding problem actually shows up.

The LangChain Stack

The most common/popular alternative to my preferred stack is:

LangGraph + LangSmith + LangSmith Deployment

This is popular because it’s the closest thing to a one-stop-shop for agent development, tracing, evals, and deployment.

This stack is attractive if a team wants an integrated agent platform and is already comfortable with LangChain abstractions.

Personally, I wouldn’t treat it as the generic default. LangSmith can trace non-LangChain frameworks, but deploying those frameworks through LangSmith generally means wrapping them in LangGraph-style entrypoints. That’s useful, but it’s still a form of lock-in — everything eventually becomes LangGraph-shaped.

LangSmith Evals are a real advantage. Logfire doesn’t give you a full eval platform out of the box. But generic traces plus separate scoring jobs can cover most eval workflows while keeping the stack more portable.

Langfuse is also worth mentioning here, but it isn’t part of the LangChain stack. It’s an independent open-source LLM observability/evals platform, and a good alternative to Logfire or LangSmith when self-hosting or OSS posture matters.

Useful references:

• LangSmith Deployment: https://docs.langchain.com/langsmith/deployment
• Deploying other frameworks to LangSmith: https://docs.langchain.com/langsmith/deploy-other-frameworks
• Langfuse observability: https://langfuse.com/docs/observability/overview

The Claude / Anthropic Stack

Anthropic deserves its own category. The Claude stack is more specialized than the LangChain stack, but it’s significant because it’s very strong for coding agents and file-based workflows.

The relevant stack is roughly:

Claude API + Claude Agent SDK + Claude Managed Agents

The biggest advantage of the Claude stack is that Claude Agent SDK exposes the same core tools, agent loop, and context management that power Claude Code. It can read files, run commands, search the web, edit code, use hooks, subagents, MCP, permissions, sessions, and more. That makes it especially attractive for coding agents, repository agents, local-file workflows, CI agents, migration agents, and internal developer tooling.

The biggest downside is lock-in. Claude Agent SDK is built around Anthropic’s API and Claude Code-style execution model. Anthropic does offer an OpenAI SDK compatibility layer, but its own docs describe that layer as intended for testing and comparison, not as the long-term production path for most use cases. Several Claude-native features require the native Claude API.

Claude Managed Agents takes this further by offering a managed harness and infrastructure for running Claude as an autonomous agent. It can run long-running sessions in managed containers, persist event history, read and write files, run shell commands, browse the web, and execute code securely. This is powerful, but it couples the application to Anthropic’s model API, agent harness, managed runtime, and deployment environment.

This LLM provider lock-in makes me especially nervous. A lot of developers have already switched from Claude Code to other coding agents (either local or another provider), because of Anthropic’s (1) restrictive rate limits and (2) high costs for models like Opus 4.7. The LLM is a critical, low-level dependency for agentic products, and I’d hesitate to lock my company into a single provider’s models and API.

Recommendation: treat Claude Agent SDK as a strong specialized choice for coding agents, not the default generic agent framework.

Useful references:

• Claude Agent SDK overview: https://code.claude.com/docs/en/agent-sdk/overview
• Claude Agent SDK observability: https://code.claude.com/docs/en/agent-sdk/observability
• Claude Managed Agents overview: https://platform.claude.com/docs/en/managed-agents/overview
• Anthropic OpenAI SDK compatibility: https://platform.claude.com/docs/en/api/openai-sdk
• Anthropic Managed Agents engineering writeup: https://www.anthropic.com/engineering/managed-agents

Layer-by-Layer Recommendations

1. LLM / AI Gateway

Recommended default: preserve an OpenAI-compatible boundary wherever possible.

The gateway should be boring. Route requests, manage keys, track spend, support fallbacks, and avoid trapping the app behind one provider-specific interface.

Useful references:

• Vercel AI Gateway: https://vercel.com/docs/ai-gateway
• Pydantic AI Gateway: https://pydantic.dev/docs/ai/overview/gateway/
• OpenRouter API docs: https://openrouter.ai/docs/api/reference/overview
• OpenRouter FAQ: https://openrouter.ai/docs/faq
• Anthropic OpenAI SDK compatibility: https://platform.claude.com/docs/en/api/openai-sdk

2. Agent Framework

Recommended default: OpenAI Agents SDK.

Use PydanticAI for Python-heavy Pydantic shops, Vercel AI SDK for TypeScript-heavy product teams, and LangGraph when the team has already chosen LangChain.

Use Claude Agent SDK when the agent is meaningfully Claude Code-like: codebase navigation, file edits, shell commands, repo repair, migration agents, test-writing agents, or local developer automation.

Useful references:

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
• PydanticAI overview: https://pydantic.dev/docs/ai/overview/
• Vercel AI SDK agents: https://ai-sdk.dev/docs/agents/overview
• Claude Agent SDK overview: https://code.claude.com/docs/en/agent-sdk/overview

3. Observability

Recommended default: Logfire.

Use LangSmith when eval UX and LangGraph-native workflows matter more than portability. Use Langfuse when open-source/self-hosted observability is important. Use Claude Agent SDK’s OTLP export when the agent is intentionally Claude-native.

Useful references:

• Logfire OpenAI integration: https://pydantic.dev/docs/logfire/integrations/llms/openai/
• Logfire general observability: https://pydantic.dev/logfire
• PydanticAI Logfire integration: https://pydantic.dev/docs/ai/integrations/logfire/
• Vercel AI SDK + Logfire / OTEL: https://pydantic.dev/articles/vercel-ai-sdk-logfire-otel
• Langfuse observability: https://langfuse.com/docs/observability/overview
• Claude Agent SDK observability: https://code.claude.com/docs/en/agent-sdk/observability

4. Raw Compute

Recommended default: Vercel Workflows (Vercel/Next.js teams) as the durable orchestrator and lightweight host for the agent loop; E2B or Vercel Sandbox for the agent’s sandbox; Modal for GPU and heavy compute.

Note: Vercel Workflows is my only recommended framework that is not language-agnostic. The Workflows SDK only exists for TypeScript, but the developer experience is so good that I think it’s worth it. It actually does not lock you into the Vercel ecosystem either, because the Workflows SDK can run locally or anywhere with a Node.js runtime.

Vercel Workflows is the agent runtime, not the agent body — it handles durable steps, sleeps, hooks, retries, and resumable streams, but its steps run on Vercel Functions / Fluid Compute and inherit those limits (no GPU, modest CPU/RAM, ~300s Hobby / ~800s Pro per step). Heavy work and code-execution sandboxes still belong in dedicated layers. Outside the Vercel ecosystem, the equivalent role is filled by Temporal (selectively) plus whatever web/runtime compute the rest of the app uses.

Most agentic workloads have modest hardware needs but care a lot about sandbox startup time, ergonomics, and per-session state — which is exactly the shape E2B and Vercel Sandbox are built for. Pick Vercel Sandbox when the rest of the app already lives on Vercel/Next.js; pick E2B when provider neutrality, longer session limits, or memory-preserving pause/resume matter more.

Reach for Modal only when the workload actually needs GPUs, beefier hardware, gVisor isolation, or Python-heavy ML compute (model serving, embeddings, batch inference, fine-tuning, image generation). A common production pattern is Vercel Workflows orchestrating the agent loop, E2B or Vercel Sandbox for the agent’s sandbox, and Modal-hosted endpoints for the heavy bits.

A useful split:

Useful references:

• OpenAI Agents SDK sandbox providers: https://developers.openai.com/api/docs/guides/agents/sandboxes#sandbox-providers
• E2B documentation: https://e2b.dev/docs
• Vercel Sandbox: https://vercel.com/docs/vercel-sandbox
• Building an agent with OpenAI Agents SDK and Vercel Sandbox: https://vercel.com/kb/guide/building-an-agent-with-openai-agents-sdk-and-vercel-sandbox
• Modal GPUs: https://modal.com/docs/guide/gpu
• Modal sandboxes: https://modal.com/docs/guide/sandbox
• Vast.ai docs: https://docs.vast.ai/
• Vercel Workflows: https://vercel.com/docs/workflows
• Bedrock AgentCore: https://docs.aws.amazon.com/bedrock-agentcore/
• Google Agent Runtime: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime
• Claude Managed Agents: https://platform.claude.com/docs/en/managed-agents/overview

5. Durable Execution

Recommended default: application-level retries/checkpoints for lightweight agents; Vercel Workflows when the team is on Vercel/Next.js; Temporal when the workflow is platform-agnostic or mission-critical enough to justify its depth.

Don’t reach for any durable runtime just because the agent is production-facing. Reach for one when a workflow or sub-workflow is long-running, failure-prone, high-stakes, or stateful enough that simple retry and checkpointing logic becomes a liability.

Useful references:

• Vercel Workflows: https://vercel.com/docs/workflows
• Vercel Workflow SDK: https://github.com/vercel/workflow
• Temporal OpenAI Agents SDK integration: https://docs.temporal.io/ai-cookbook/openai-agents-sdk-python
• Temporal OpenAI Agents SDK Python integration repo: https://github.com/temporalio/sdk-python/blob/main/temporalio/contrib/openai_agents/README.md
• Temporal local development server: https://docs.temporal.io/develop/run-a-development-server
• Claude Managed Agents: https://platform.claude.com/docs/en/managed-agents/overview
• LangSmith Deployment: https://docs.langchain.com/langsmith/deployment

TL;DR

General advice:

1. Start simple, but don’t build accidental infrastructure.
2. Pick the frameworks based on language and use case.
3. Avoid vendor lock-in where possible.
4. Standardize on layers, not platforms.

Implementation advice:

• Start with OpenAI Agents SDK.
• Add Logfire or another OTLP-compatible observability platform.
• Add E2B (provider-neutral) or Vercel Sandbox (Vercel/Next.js-native) when agents need a sandbox to act inside.
• Add Modal when agents need GPUs, beefy hardware, or Python-heavy ML compute.
• Add Vercel Workflows when a Vercel/Next.js app needs durable agent loops, retries, sleeps, hooks, or resumable streams.
• Add Temporal when the workflow is mission-critical enough to justify it.