Agentic AI frameworks: how to choose one for production work

What an agentic framework actually does

Strip away the marketing and every agentic AI framework solves the same five problems. A language model can produce a tool call, but it cannot execute it, remember it, retry it, or know when to stop. The framework does that:

• The loop. Call the model, read the response, execute any tool calls, append the results to the conversation, call again. Repeat until a terminal condition: a final answer, a step limit, or a budget ceiling.
• The tool protocol. Turning Python or TypeScript functions into JSON schemas the model can call, then validating and coercing what comes back. Models routinely return a string where you declared an integer.
• State. What survives between steps: the message history, intermediate artefacts, a scratchpad, retrieved documents. How much of it goes back into the next prompt is the single biggest driver of both cost and quality.
• Control flow. Sequential steps, parallel fan-out with a join, conditional branches, loops with exit criteria, and delegating a sub-task to another agent.
• Failure handling. Rate limits, timeouts, malformed tool arguments, a model that loops forever calling the same tool. In production this is most of the code.

Frameworks differ far less in what they do than in which of these they make explicit. That is the real axis of comparison, and it is why a framework that feels elegant in a tutorial can feel obstructive at scale, or the reverse.

The six criteria that actually decide it

After running agents in production against live client data, crawling sites, calling search and ads APIs and writing into client accounts, these are the properties that determined whether a framework helped or got in the way.

1. Durable state and resumability

A run that takes eleven minutes and calls six external APIs will die partway through. The question is what happens next. If your framework checkpoints state after each step to a real datastore, you resume from step four. If state lives in process memory, you start again, and pay for the first three steps twice. This single property separates frameworks suitable for long-running work from those built for chat-latency tasks.

2. Human-in-the-loop as a first-class concept

Any agent that writes to a client-facing system needs an approval gate. The naive version (pause, wait for a callback, resume) is genuinely hard, because it means suspending execution across a process boundary and possibly across days. Frameworks that model interruption natively make this a few lines. Frameworks that do not force you to decompose the agent into separate invocations and hand-roll the state passing.

3. Observability you can hand to a non-engineer

When a client asks why an agent recommended something, "the model decided" is not an answer. You need the full trace: every prompt, every tool call and its arguments, every result, token counts and cost per step. Some frameworks ship this; others expect you to instrument it. Retrofitting tracing onto an agent framework that did not plan for it is painful, because the interesting boundaries are inside the library.

4. Cost control at the loop level

An agent that re-sends its entire message history on every iteration has quadratic token growth. Ten steps of a growing context is not ten times the cost of one: it is closer to fifty. Look for explicit context-window management: message trimming, summarisation of older turns, and the ability to pass only a compacted state forward. Also look for a hard step ceiling and a token budget that aborts the run, because without one a looping agent will happily spend your month's budget overnight.

5. Escape hatches

You will eventually need to do something the framework's authors did not anticipate: a custom retry policy, a non-standard streaming format, a provider quirk. Frameworks that expose the underlying request let you drop down a level. Frameworks that fully encapsulate the model call leave you forking or abandoning them.

6. The dependency's own stability

This space moves fast enough that a framework's public API can change substantially inside a year. Pin versions, read the changelog before upgrading, and weigh how much of your system would need rewriting if the abstraction shifted. A thinner framework is a smaller bet.

The frameworks, compared

Scored on the criteria above rather than on feature checklists. All of these are actively maintained and all of them work. The question is which failure mode you would rather own.

The case for not using a framework

This is underrated. A working agent loop is genuinely small:

Call the model with the message list and tool schemas. If the response has tool calls, execute them, append the results, and call again. Otherwise return. Stop after N steps or when the token budget is exhausted.

That is roughly forty lines. Production-hardening it (typed tool schemas, validation and coercion, exponential backoff on rate limits, per-run cost accounting, structured tracing, a step ceiling) takes it to perhaps three or four hundred. In exchange you get a system where every behaviour is in your repository, stack traces point at your code, and no upgrade can silently change how your agents behave.

Most of Opaeron's twenty-plus agents work this way. Each one is a scoped pipeline: gather inputs from real APIs, do deterministic processing in ordinary code, call the model at the specific points where judgement is genuinely needed, then write a structured result. The model is a component inside a workflow, not the workflow itself.

Five patterns that show up in every real deployment

1. Router. One cheap model classifies the request and dispatches to a specialised handler. Most of the reliability win, almost none of the cost.
2. Deterministic sandwich. Code gathers the data, the model does one bounded judgement step, code validates and persists the result. The model never touches I/O directly.
3. Fan-out and reduce. Run N independent analyses in parallel, then have a final step reconcile them. Effective for audits and reviews where coverage matters more than depth.
4. Propose and confirm. The agent produces a structured proposal; a person approves; ordinary code executes. Non-negotiable for anything client-facing.
5. Adversarial verification. A second pass whose only job is to refute the first pass's findings. Expensive, and the single most effective way to stop plausible-but-wrong output reaching a client.

So which one should you use?

Answer three questions honestly. How long does a run take? Under thirty seconds, durability barely matters and almost anything works. Over several minutes with external API calls, you need real checkpointing. Does it write anything a client sees? If yes, human-in-the-loop is a hard requirement, not a feature you will add later. How many distinct agents will you actually run? Below about five, a shared abstraction is overhead; above twenty, you will want one.

For most teams building serious AI agents for marketing and operations work, the honest answer is a hybrid: deterministic workflows for the ninety percent of steps whose shape you already know, a well-instrumented agent loop for the genuinely open-ended parts, and a framework only where its specific strength, usually durable resumption, pays for its abstraction.

Frequently asked questions