How to Choose an Agent Framework for Production: Prioritize Control, Recovery and Security

What Happened

Recent releases show agent tooling maturing around operational failure modes, not just new ways to call models. Claude Code 2.1.288 fixed missed approval prompts for several shell-command patterns and now blocks tool calls when approval hooks cannot be checked. It also improved session recovery, unattended timeouts, MCP authentication prompts and code-review controls [1].

PydanticAI 2.53.0 fixed a high-severity streamed-request concurrency-slot leak that could block other requests sharing a limiter. It also added managed subagents and evaluation tools, while changing shared-limiter behavior in ways custom integrations must review [3]. The agent SDK’s 0.23.0 release tightened sandbox checks and improved tool approvals, session recovery, MCP resumption and realtime output guardrails. Its 0.23.1 patch changed release checks, not SDK runtime behavior [4][2].

Why It Matters to Businesses

The choice among LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, PydanticAI, DSPy, Semantic Kernel, OpenAI Agents SDK and coding agents such as Claude Code should start with the workload, not the breadth of a demo. A research assistant, a durable approval workflow and an unattended coding agent have different requirements for state, tool permissions and recovery. The cited releases illustrate why: a missed approval check, lost tool result or stuck concurrency slot can become a business incident even when model output is otherwise good [1][3][4].

Kimbodo Engineering Perspective

Separate orchestration from authority. Use a framework to manage agent state and tool calls, but enforce permissions, spending limits and data access at the tool or service boundary. Prefer explicit workflow steps for consequential actions; reserve open-ended delegation for tasks where an unexpected action is cheap to detect and reverse.

Framework selection is a trade-off. Retrieval-heavy applications may need strong data-access integration; long-running work needs durable state and replay; regulated operations need observable approvals. Coding agents need particular scrutiny around shell execution and repository permissions, as the Claude Code fixes demonstrate [1]. Avoid treating a framework’s built-in sandbox or approval UI as the only security control.

How We Would Implement It

• Define the task boundary: specify allowed tools, data classes, approval points, latency and cost budgets, and what constitutes a completed run.
• Choose one orchestration layer per workflow: keep model adapters, retrieval, tool services and state storage behind interfaces so framework changes do not require rewriting business logic.
• Make execution recoverable: persist run and tool-call identifiers, record outcomes before advancing state, and test cancellation, retries, compaction and resume paths. Recent SDK work shows these paths require deliberate engineering [4].
• Gate side effects outside the model: apply scoped credentials, server-side authorization, human approval for high-impact actions, and bounded concurrency. Test streaming separately from non-streaming traffic [1][3].
• Evaluate with real failure cases: measure task success alongside unauthorized-action attempts, duplicate tool calls, recovery correctness, latency and spend.

Risks, Costs and Security

More agents and tools increase token use, integration work and the number of permission boundaries to audit. Streaming, MCP connections and resumable sessions add failure modes that happy-path tests miss [3][4]. Before upgrading, check compatibility changes—particularly custom concurrency limiters—and run regression tests for approvals, sandbox escapes, interrupted runs and duplicate side effects. A release marked ready to ship does not replace approval and repository protections in an organization’s own deployment process [2].

Sources

1. [1] v2.1.288
2. [2] v0.23.1
3. [3] v2.53.0 (2026-10-01)
4. [4] v0.23.0