AI Agent Stack in 2026: LangGraph vs Custom vs DIY

A developer who ships AI agents weekly compares three approaches to building agent stacks in 2026: plain loops, LangGraph, and custom frameworks. For simple linear agents with fewer than five tools, a 150-line loop around an LLM call suffices for about 40% of shipped agents. LangGraph is preferred for complex branching, durable execution, and multi-agent handoffs, though it hides token accounting unless callbacks are explicitly wired.

I ship agents into production most weeks, and the framework question keeps coming back in every kickoff call. The honest answer is that the "right" stack depends on how much branching, how much state, and how much blast radius you can tolerate. I've built the same agent three ways in the last year, and the trade-offs are sharper than the framework marketing lets on. Here is how I actually decide. When I start a new agent, I pick from three buckets. Everything else is a variation of these: while loop around an LLM call with tool execution and a message array. Roughly 150 lines of Python or TypeScript.The decision comes down to three questions: how many steps, how much concurrency, and what happens when it crashes at 3am. Everything else observability, evals, human-in-the-loop can be bolted onto any of the three. For any agent with fewer than about five tools and a linear think-act-observe loop, a plain loop wins. I use this for ~40% of the agents I ship, including most of the sub-agents inside BizFlowAI ContentStudio. Frameworks add abstraction cost that only pays back when you have real branching. Here is what the whole thing looks like, minus logging: python def run agent task: str, tools: dict, max steps: int = 12 : messages = {"role": "system", "content": SYSTEM PROMPT}, {"role": "user", "content": task}, for step in range max steps : resp = client.messages.create model="claude-sonnet-4-5", messages=messages, tools=list tools.values , max tokens=4096, messages.append {"role": "assistant", "content": resp.content} if resp.stop reason == "end turn": return resp.content -1 .text tool results = for block in resp.content: if block.type == "tool use": try: result = tools block.name <a href=" block.input" "fn"</a tool results.append { "type": "tool result", "tool use id": block.id, "content": str result , } except Exception as e: tool results.append { "type": "tool result", "tool use id": block.id, "content": f"ERROR: {e}", "is error": True, } messages.append {"role": "user", "content": tool results} raise RuntimeError "Agent exceeded max steps" That is it. The advantages are real: is error: true so it can recover, and if the model loops on a broken tool, you catch it because you wrote the counter.Where DIY breaks: parallel tool execution across long-running jobs, multi-agent handoffs, or anything with checkpointing that needs to survive a process restart. At that point you are either building a framework or reaching for one. LangGraph is the framework I keep coming back to in 2026, mostly because it treats agents as graphs of nodes with typed state, and that model actually matches how complex agents behave. I reach for it when the workflow has real branching three or more meaningful paths , when I need durable execution across hours or days, or when I have multiple agents talking to each other. The value shows up in three specific features: TypedDict or Pydantic model for state, and every node returns partial updates. This is worth more than it sounds because it forces you to think about state transitions instead of passing message arrays around. SqliteSaver or PostgresSaver , the graph resumes from the last node if the process dies. For long-running research agents or human-in-the-loop workflows, this is non-negotiable.Where I get burned: LangGraph's abstraction over LLM calls hides token accounting unless you wire in callbacks explicitly. The docs move fast, and some patterns that worked six months ago are now discouraged. If you use it, pin your versions and write integration tests that snapshot the actual API calls being sent. A rough rule of thumb from what I've shipped: | Agent type | Nodes | Best fit | |---|---|---| | Single-purpose tool caller | 1-3 | DIY loop | | Research + write + review | 4-8 | LangGraph | | Multi-agent with handoffs | 8+ | LangGraph or custom | | Long-running workflow hours+ | any | Custom orchestration | | Fan-out to 50+ parallel jobs | any | Custom orchestration | Custom orchestration means treating the agent as a distributed system: a durable executor Temporal, Inngest, Step Functions, or a homegrown thing on SQS drives the workflow, and each LLM call or tool execution is a task in that system. I use this when I need to survive machine failures, when a single "agent turn" might take an hour, or when I have to fan out to hundreds of parallel branches. The serverless AWS + Zendesk integration I built for SLA compliance was custom orchestration. Not because it was an "agent" exactly, but because the same reasoning applies: EventBridge drove the workflow, Lambda functions were the tasks, and DynamoDB held the state. If a Lambda died, EventBridge retried. If a tool failed, the state machine knew where to resume. That pattern maps cleanly onto agentic workflows once you accept that an LLM call is just another idempotent task. What custom orchestration buys you that a framework does not: The cost is real. You write more code, you own the infrastructure, and you have to build your own visualization of what the agent did. For anything under an hour of runtime with fewer than 10 parallel branches, this is overkill. Above that, frameworks start to feel like toys. Here is the flowchart in my head when a new agent project starts: PostgresSaver for checkpointing and OpenTelemetry callbacks for observability.I lean DIY more often than framework marketing suggests I should. Most agents in the wild do not need a graph. They need one good loop, careful prompt engineering, tight tool schemas, and honest evals. The framework becomes useful the moment the workflow diagram stops fitting on one screen. A few lessons that cost me real time: Tool schemas matter more than model choice. I have seen the same task go from 60% to 95% success just by rewriting tool descriptions and parameter names. Before you switch models or add a framework, spend a day on your tool schemas. The model can only be as smart as your tools let it be. Message array pruning is where the token savings live. In a 20-step agent, the message array grows quadratically in tokens if you keep all tool results. I keep the last 3-5 tool results verbatim and summarize the rest. On one content agent this cut cost by 40% with no measurable quality loss. Error strings are prompts. When a tool fails, the error message goes back into the model's context and becomes part of the next prompt. "Database connection failed" is a useless prompt. "Database query returned no rows for user id=42. Try a different user id or check if the user exists." lets the model recover. Checkpointing without idempotency is a lie. If your graph resumes from step 7 and step 7 called a payment API, you just charged the customer twice. Every tool that mutates state needs an idempotency key. This is true for any framework. Evals are not optional. I run every agent I build against a fixed set of 20-50 test cases before every deploy. Not fancy LLM-as-judge stuff, just deterministic checks: did it call the right tools, did the final answer contain the required fields, did it stay under the token budget. This is the single highest-ROI engineering practice in agent work. Start with the DIY loop. Get the tools, the system prompt, and the eval set right first. Instrument token usage and step count from day one. Ship it, watch it fail on real inputs, and fix it. Only reach for LangGraph when the workflow diagram has real branches or when you need durable pause-and-resume. Only reach for custom orchestration when a single run is longer than an hour or fans out beyond what a single process should manage. Do not skip the DIY stage: it teaches you what your agent actually does, and that knowledge is what makes the framework choice obvious later. The framework debate is mostly noise. The agents that ship and stay shipped are the ones with tight tool schemas, honest evals, and observability that lets you debug production failures in under 10 minutes. Everything else is scaffolding. If you are building an agent right now and stuck between these stacks, I'm always happy to look at the workflow diagram and tell you what I'd pick. Reach out at lazar-milicevic.com/ contact https://lazar-milicevic.com/ contact , or read more on the blog https://lazar-milicevic.com/blog where I've written about agent evaluation, context engineering, and cutting token spend in production.