Skip to content Skip to footer

How to Choose an Agent Framework and Build Agents That Survive Retries, Replays and Tool Failures

What Happened

A November 10 agent-tooling release added durable SubAgents under Temporal and DBOS, DBOS child-workflow tools, and verdicts for guardrails and tool I/O. Its replay fixes preserve tool-call order, approvals, shell waits and background-task events, while keeping replayed work out of traces and usage totals [1].

The same release expanded model and web-tool support, improved provider retries and streamed tool calls, and tightened sandbox and repository handling. Security changes include scanning artifacts for hidden variation selectors, capping file-URL downloads and treating more IPv6 ranges as private [1].

Why It Matters to Businesses

Framework selection is no longer just about how quickly a team can connect a model to tools. For production agents, the deciding questions are whether a task can resume safely after interruption, whether an approval is preserved across replay, and whether tool activity can be audited without counting replayed work twice [1].

LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, PydanticAI, DSPy, Semantic Kernel and the OpenAI Agents SDK offer different starting points for orchestration, retrieval, typed interactions or workflow composition. Claude Code is more directly relevant to coding-agent workflows. Those categories help narrow an evaluation; they do not establish that any one product meets a business’s durability or security requirements.

Kimbodo Engineering Perspective

Choose the execution model before the framework. A short, read-only research task may need little more than tool routing and validation. An agent that edits files, spends money or waits for human approval needs explicit state transitions, durable execution and recovery tests. Replay correctness matters as much as a successful first run: an approval or external write must not be accidentally repeated.

Provider breadth is useful, but it adds integration work. Retries, quotas, streamed calls and schemas behave differently across models; the fixes in this release illustrate why those paths need tests rather than assumptions [1].

How We Would Implement It

  • Define the agent’s permitted tools, data access, approval points and measurable completion criteria before choosing an orchestration library.
  • Use a durable workflow for long-running or side-effecting tasks. Assign stable operation IDs to external writes, persist approval decisions and test interruption at every tool boundary.
  • Validate tool inputs and outputs with typed schemas; record guardrail verdicts alongside the action they permit or block. Keep replayed events distinguishable from new model and tool activity [1].
  • Evaluate candidate frameworks against the same scenarios: provider failure, quota exhaustion, partial streamed tool calls, worker restart and human-approval delay.

Risks, Costs and Security

Durability adds workflow infrastructure, state storage and operational complexity. Multi-provider support adds regression testing, while traces and usage accounting must distinguish original execution from replay [1]. For coding and file-access agents, repository instructions, downloaded files and tool output are untrusted inputs. Apply instruction-size limits, sandbox execution, restrict network destinations and review artifacts before they cross trust boundaries; the release’s instruction-loading and scanning changes make those controls especially relevant [1].

Where Kimbodo Comes In

Kimbodo builds and operates this in production for businesses — see our Enterprise AI Agent Development practice, or Scope an Enterprise AI Agent.

Sources

  1. [1] v2.67.0 (2026-11-10)

Leave a comment

0.0/5

Engineering Founded & Customer Focused

KIMBODO LLC. © 2026. All Rights Reserved.