Almost every agent project we are asked to rescue started with the same question: which framework should we use? It is the wrong first question. The framework is the least durable decision in the stack — teams swap them in a weekend — while the decisions that actually determine whether the agent ships are architectural, and no framework makes them for you. This is a practical guide to choosing one in 2026: what a framework genuinely gives you, the seven criteria that decide it, what breaks the moment real traffic arrives, and the cases where the right answer is no framework at all.
Strip away the marketing and an agent framework provides four things: control flow (how a multi-step task is sequenced, branched and retried), state and memory (what the agent remembers within a run and across runs), tool calling (schema definition, argument validation, result handling), and instrumentation hooks (somewhere to attach traces and logs). That is genuinely useful plumbing and it will save you weeks.
What a framework does not give you is the part that gets an agent approved: a guardrail layer you can prove to a security reviewer, per-task cost metering, an evaluation suite that tells you whether this week's agent is better than last week's, and the audit evidence a regulator will ask for. Those are yours to build regardless of which logo is on the import statement. Teams who miss this distinction are the ones who discover in month four that the framework choice was never the bottleneck.
Direct answer: often not. If the workflow has fixed inputs and fixed rules, a hundred lines of ordinary code will beat an agent on cost, latency and reliability — every time. If the workflow needs a model but always in the same shape (classify, extract, summarise, then act), that is a pipeline with an LLM call in it, not an agent, and it does not need an orchestration framework.
You need agent machinery when the number of steps genuinely cannot be known in advance, when tool selection depends on intermediate results, and when the task benefits from retry and replanning. That is a real category — it is just much smaller than the market implies. We wrote about the pattern of applying autonomy where deterministic code wins in why AI agent projects fail; it remains the single most expensive mistake in the space.
The landscape splits into three families: graph and state-machine orchestrators (LangGraph and similar), role- and crew-based abstractions (CrewAI, AutoGen and their descendants), and the first-party agent SDKs shipped by the model vendors themselves. They differ far less than their documentation suggests. Score any candidate against these seven criteria instead of feature lists:
| Criterion | What to ask | Why it decides the project |
|---|---|---|
| Control-flow transparency | Can you read the execution path without running it? | What you cannot trace, you cannot debug at 2am or explain to an auditor |
| Escape hatches | Can you drop to plain code at any step? | Every real system needs one thing the abstraction did not anticipate |
| State durability | Does a run survive a process restart? | In-memory-only state fails the first long-running or resumable task |
| Validation boundary | Can you enforce rules the model cannot override? | The LLM must be an untrusted component, not the final authority |
| Cost observability | Tokens attributable per task, per step? | Agent loops multiply calls; unmetered loops are how budgets vanish |
| Eval integration | Can you replay a run against a fixed dataset? | Without replay there is no way to prove a change was an improvement |
| Exit cost | How much rewrite if you leave in a year? | The framework will outlive its hype cycle by less time than your product |
Weight the last one heavily. Frameworks in this category churn fast; the ones that survive are the ones that stayed thin. A framework that owns your control flow, your prompts, your state store and your tool definitions is not a dependency — it is a rewrite waiting for a trigger.
The same four things, in roughly this order. Cost is first: a loop that averaged three model calls in testing averages eleven on real inputs, and consumption pricing turns that into a finance conversation. Latency is second: sequential tool calls that felt fine with one user compound badly under concurrency. Non-determinism is third — the same input produces a different trajectory, and without recorded traces you cannot tell a regression from noise. Permissions are fourth and most dangerous: an agent with broad write access and no approval gate is a security finding waiting to be written up.
None of these are framework bugs. They are consequences of autonomy, and they arrive no matter which library you picked. Budgeting for them from week one is the difference between a pilot that converts and one that gets quietly cancelled — the full build-and-run numbers are in our AI agent cost guide.
A rule that has held up well for us: use a framework to learn the problem, then keep only the parts you can defend. Prototype fast on whatever has the best documentation — the goal in week one is to discover what the agent actually needs to do, not to pick a long-term dependency. Once the workflow is understood, most production systems end up with a thin orchestration layer, explicit tool definitions, and a validation kernel the team owns outright. That is not anti-framework purism; it is what survives a security review and a model migration.
Build from scratch when the agent operates in a regulated surface, when cost must be controlled at a granularity the framework does not expose, or when the compliance evidence has to be first-class rather than reconstructed from logs. In healthcare and fintech that is usually all three at once — the reference architecture is in HIPAA-compliant AI agents.
We open-sourced Kite because the frameworks we evaluated all optimised for the demo and left the safety layer as an exercise for the reader. Kite starts from one principle — the LLM is an untrusted component — and builds outward: kernel-level validation of every action before it executes, circuit breakers, idempotency, kill switches, and five reasoning patterns (ReAct, ReWOO, Tree-of-Thoughts, Plan–Execute, Reflective) that you select deliberately rather than inherit by default. It is inspectable on GitHub rather than rented as a black box.
We are not claiming it is the right choice for everyone. We are claiming that whatever you choose, the validation boundary, the cost meter and the eval harness have to exist — and if your framework does not provide them, that work does not disappear. It just moves onto your backlog without a ticket.
We build production AI agents for startups and regulated industries — senior team, fixed price per phase, full IP ownership from day one. If you are mid-way through a framework evaluation, see how we take agents to production or tell us what you want the agent to do — we will tell you honestly whether it should be an agent at all, and which of these seven criteria will decide your build.