Which approach should I start with if I've never built an agent?

Start with the plain while loop. Writing the loop, the tool dispatch, and the exit condition yourself teaches you exactly what every SDK is doing under the hood. Once you hit a concrete limitation, such as needing multi-provider support or streaming to a UI, you'll know which abstraction you actually need and why.

Can I ship the plain while loop to production, or do I need a framework?

You can ship it, but you own everything the frameworks give you for free: retries, timeouts, logging, memory management, and guardrails. A while loop is a good production choice when your logic is simple, your dependencies must stay minimal, or your agent doesn't fit a framework's assumptions. Reach for a framework when reimplementing those concerns yourself costs more than adopting the abstraction.

Can I switch SDKs later without rewriting the whole agent?

Partially. The core loop, your tool functions, and your prompts usually port cleanly because every SDK expresses the same underlying pattern. What doesn't port is framework-specific glue: LangChain's chains, the OpenAI Agents SDK's handoffs, or Vercel's useChat streaming hooks. Keep your tool implementations independent of the framework so a future switch touches assembly code, not business logic.

Do long-running agent loops time out when deployed as a web service?

They can. A multi-step agent loop that runs for minutes can exceed the timeout of a standard HTTP request handler. On Render, run the loop as a Render Workflows task, which can execute for up to 24 hours with automatic retries, or have a web service trigger the task and return immediately. Either way, request handling stays fast while the agent runs to completion out of band.

Where does agent state live between steps and requests?

The message history in the examples lives in memory for a single run. For agents that resume across requests or share context between services, persist that state in a datastore. On Render, a managed PostgreSQL database is a common choice for agent memory, tool results, and session state, and it's reachable from both your workflow tasks and your web services.

Platform

Comparing agent SDKs (LangChain vs. OpenAI Agents vs. Vercel AI vs. a simple while loop)

July 15, 2026

The AI ecosystem ships new "agent frameworks" constantly, but the underlying pattern is simple: a loop that calls an LLM, decides whether to use a tool, observes the result, and repeats. Every SDK implements a variation of this loop, regardless of language, abstraction level, or marketing positioning.

This article compares four approaches to building agentic workflows: LangChain, OpenAI Agents SDK, Vercel AI SDK, and a plain while loop. The comparison examines what each approach actually does to the core loop: where it adds abstraction, what it hides, and what tradeoffs follow. Code examples are simplified illustrations, not starter kits.

An agent is a program that executes an iterative cycle: send a prompt to an LLM, parse the response for a tool-use decision, execute the selected tool, feed the tool's output back as context, and repeat until the LLM signals completion. This is the agent loop, and every framework implements it. The differences lie in how much of this loop the framework makes explicit versus implicit.

LangChain wraps the loop in composable abstractions. OpenAI Agents SDK provides opinionated primitives that keep the loop visible. Vercel AI SDK optimizes the loop for streaming to a UI. A plain while loop drops the framework altogether: you get complete control over the loop, and you own every bit of the maintenance that comes with it.

python

messages = [{"role": "user", "content": user_input}]

while iterations < max_iterations:                                  # Exit strategy varies by framework
    response = call_llm(messages)

    if response.has_tool_call:                 # This is where SDKs add abstraction
        tool_name = response.tool_call.name
        tool_args = response.tool_call.arguments
        result = execute_tool(tool_name, tool_args)
        messages.append(tool_result(result))
    else:
        print(response.content)
        break

For production, add timeout limits, error handling, and observability logging.

LangChain is a Python and TypeScript framework that encodes the agent loop into composable primitives: chains, agents, tools, and memory modules. Its philosophy is declarative composition. You wire together pre-built components rather than writing loop logic directly.

The tradeoff is direct: abstraction breadth introduces debugging opacity and dependency weight. When a tool call fails silently or memory injection produces unexpected context, tracing the problem requires understanding multiple abstraction layers between your code and the LLM API call.

LangChain is strongest when your project needs model-provider flexibility, built-in memory strategies, or pre-built integrations. It's weakest when you need transparent control flow or minimal dependencies.

python

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def search(query: str) -> str:
    """Search the web for information."""   # Docstring becomes the tool description
    return external_search(query)

agent = create_agent(
    model="openai:gpt-5.6-sol",
    tools=[search],
    system_prompt="You are a helpful research assistant."
)

# The loop (reasoning -> tool call -> observation -> repeat) is internal to the graph
result = agent.invoke(
    {"messages": [{"role": "user", "content": "What is Render's pricing?"}]}
)

create_agent returns a compiled graph that owns the loop. You configure the pieces, but you don't write the reasoning-tool-observation cycle: it runs inside .invoke(). The graph's recursion limit is LangChain's exit strategy, the same loop bound from the pseudocode, managed for you instead of written by hand.

The OpenAI Agents SDK provides three core primitives: Agents (an LLM configured with instructions and tools), Handoffs (delegation between agents), and Guardrails (input/output validation). It's designed primarily for OpenAI models, which is both its constraint and its advantage.

Runner.run() manages the agent loop, but the primitives remain visible and inspectable. The SDK keeps a flatter architecture than LangChain, with fewer places for bugs to hide. The tradeoff is provider lock-in: switching to a different provider like Anthropic means moving away from the SDK's built-in integrations.

python

from agents import Agent, Runner, function_tool

@function_tool
def search(query: str) -> str:
    """Search the web for information."""
    return external_search(query)

agent = Agent(
    name="research_agent",
    instructions="You answer questions using search.",
    tools=[search],                          # Tools are declared, not chained
)

result = Runner.run_sync(agent, "What is Render's pricing?")  # Loop runs here
print(result.final_output)

The Runner manages the loop, including handoffs between agents if you configure multiple agents.

The Vercel AI SDK is a TypeScript framework that optimizes the agent loop for streaming UI integration. Its core abstractions, streamText and generateText, run a tool-calling loop bounded by a stopWhen condition and stream partial results directly to React components via hooks like useChat.

The SDK targets full-stack TypeScript applications where the agent's output must render incrementally in a browser. It supports multiple LLM providers through a unified interface, but its architectural priority is the stream-to-UI pipeline.

typescript

import { generateText, tool, stepCountIs } from 'ai';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

const result = await generateText({
  model: openai('gpt-5.6-sol'),
  prompt: "What is Render's pricing?",
  tools: {
    search: tool({
      description: 'Search the web',
      inputSchema: z.object({ query: z.string() }),   // renamed from "parameters"
      execute: async ({ query }) => externalSearch(query),
    }),
  },
  stopWhen: stepCountIs(5),
});

The stopWhen condition controls the loop boundary. For UI streaming, replace generateText with streamText and consume the result with useChat on the client.

A plain while loop using the OpenAI API with function calling for tool use gives you the agent loop without any framework mediation.

This approach is optimal when you need to understand exactly what happens at each step, your agent logic doesn't fit a framework's assumptions, or your team is small enough that framework onboarding cost exceeds implementation cost.

python

from openai import OpenAI

client = OpenAI()
messages = [{"role": "user", "content": "What is Render's pricing?"}]
tools = [{"type": "function", "function": {"name": "search", ...}}]

for step in range(10):                        # Explicit max iterations
    response = client.chat.completions.create(
        model="gpt-5.6-sol", messages=messages, tools=tools
    )
    msg = response.choices[0].message
    messages.append(msg)

    if msg.tool_calls:                        # You control the dispatch logic
        for tc in msg.tool_calls:
            result = execute_tool(tc.function.name, tc.function.arguments)
            messages.append({"role": "tool", "content": result, "tool_call_id": tc.id})
    else:
        print(msg.content)
        break

Every line is yours, which is both an advantage and a cost. You must implement retries, timeouts, logging, memory management, and guardrails yourself.

Choose your SDK based on project constraints, not feature lists:

Constraint	Recommended approach
Multi-provider flexibility, rich integrations	LangChain
OpenAI-only, multi-agent handoffs	OpenAI Agents SDK
TypeScript full-stack, streaming UI	Vercel AI SDK
Learning, prototyping, non-standard patterns	Plain while loop
Minimal dependencies, maximum debuggability	Plain while loop
Team already uses Next.js + React with a focus on streaming to the UI	Vercel AI SDK

Start with the basics, then abstract. A while loop teaches you what the SDKs are doing. When you outgrow the while loop, you'll know why you need the abstraction.

Agent SDKs solve the logic layer. Deployment solves the infrastructure layer. Agentic workloads introduce requirements that standard web apps don't: individual runs that range from minutes to hours, steps that fail and need retrying, bursts of parallel runs when many agents work at once, and persistent state that outlives a single request.

Render Workflows targets exactly this shape. It's an orchestration and execution engine for long-running, distributed tasks, built to meet the demands of agentic workloads. You write a task as an ordinary Python or TypeScript function, and Render runs it with automatic retries, per-task timeouts, and isolated compute that scales on demand. The agent loop from any of the approaches above drops straight into a task body.

python

@app.task
async def agent_loop(user_input: str, context: dict):
    actions = await call_llm(user_input, context)

    # Spawn a parallel task run for each planned action
    results = await asyncio.gather(
        *[execute(action) for action in actions]
    )

    # Combine results into a coherent response
    return await synthesize(user_input, results)

@app.task
def execute(action: dict):
    handler = get_handler(action["name"])
    return {"action": action["name"], "result": handler(action)}

@app.task
def synthesize(user_input: str, results: list[dict]): ...

Applying @app.task registers the function as a durable workflow task with its own retry behavior. There's no separate queue, worker, state store, or retry infrastructure to stand up. If a task run fails partway through, Render automatically retries it according to your settings, instead of you hand-rolling retry logic inside the loop. Render also spins up a separate instance for each task run and deprovisions it as the run completes, so a hundred concurrent agent runs scale out and then back to zero without a standing fleet. For multi-agent designs, a coordinating task can trigger and chain sub-agent task runs, which maps cleanly onto the handoff pattern from the OpenAI Agents SDK.

Two supporting pieces complete the picture: Managed PostgreSQL provides persistent storage for agent memory, tool results, and session state, reachable from your tasks and any web services, and environment groups let you share API keys and other environment variables across services and workflows securely.

The SDK you choose shapes your code; the platform you deploy on determines whether that code runs reliably. Pick a platform that removes DevOps friction, and your engineering time stays focused on the agent logic that actually differentiates your product.

Comparing agent SDKs (LangChain vs. OpenAI Agents vs. Vercel AI vs. a simple while loop)

Every agent SDK wraps the same loop

What happens on each turn of the agent loop

LangChain hides the entire loop behind composable primitives

The OpenAI Agents SDK keeps the loop visible behind opinionated primitives

The Vercel AI SDK optimizes the loop for streaming to a UI

A plain while loop gives you total control and full responsibility

How to choose the right agent SDK

Deployment complexity scales with agent complexity

Frequently asked questions