Skip to content Skip to footer

How to Choose an Agent Framework for Production AI: Prioritize Control Over Orchestration Features

What Happened

Recent releases put more emphasis on execution control and reliability than on new agent patterns. Claude Code now asks or denies when its server safety check is unavailable in auto mode, rather than silently falling back to a built-in classifier. It also closed sandbox and permission bypasses and made MCP tool calls background tasks by default [1]. LangGraph’s Python SDK added strict_resume to run creation, streaming and waiting, plus tool and lifecycle stream modes [3].

CrewAI added experimental conversational Agent sessions and fixed tool execution, configuration precedence and shutdown behavior [2]. Semantic Kernel’s Python 1.47.0 release dropped Python 3.10 support and fixed issues across MCP initialization, streaming, schemas and integrations; its .NET changes include a breaking file-access consolidation [4]. These notes do not establish comparable new releases for LangChain, LlamaIndex, AutoGen, PydanticAI, DSPy or the OpenAI Agents SDK.

Why It Matters to Businesses

Framework selection is no longer just a question of how quickly a team can assemble agents. Buyers need to know what happens when a run resumes, a tool waits for approval, a safety service is unavailable, or an integration changes behavior. Claude Code’s refusal behavior and LangGraph’s resume option illustrate why those failure paths belong in procurement and acceptance tests, not only in developer documentation [1][3].

Kimbodo Engineering Perspective

Choose the smallest runtime that meets the workflow’s control requirements. Use retrieval and indexing where knowledge access is the problem; use explicit stateful orchestration where work must pause, resume or involve approvals. Evaluate LangChain, LlamaIndex, AutoGen, CrewAI, PydanticAI, DSPy, Semantic Kernel, the OpenAI Agents SDK and LangGraph against the same task, rather than comparing feature lists. Treat Claude Code separately as a coding agent whose permissions and operating environment require their own controls.

Experimental sessions and new SDK switches are useful evaluation targets, not evidence of production readiness by themselves [2][3].

How We Would Implement It

  • Define each agent’s allowed tools, data scope, approval points, timeout and maximum spend before selecting a framework.
  • Put tool execution behind a gateway that validates arguments, applies identity-based permissions and records decisions. Deny or require approval when a required safety check is unavailable [1].
  • Persist workflow state and test retries, duplicate tool calls, interrupted streams and resume behavior. Enable strict resume only after verifying its semantics against the application’s recovery requirements [3].
  • Run a representative evaluation across candidate frameworks: task success, tool-call accuracy, latency, token and infrastructure cost, and operator effort. Pin SDK versions and test upgrades against integrations and supported language runtimes [4].

Risks, Costs and Security

Background tools and subagents can create work that outlives the interaction that started it; assign ownership, cancellation and audit trails to every task [1]. Sandboxes are not a substitute for tool-level authorization: recent fixes involving shell commands, symlinks and worktrees show why those boundaries need adversarial tests [1]. Budget for model calls, retries, observability and upgrade testing. A dependency or runtime change can be as consequential as a model change—particularly when a release removes Python support or makes a breaking connector change [4].

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.1.319
  2. [2] 1.15.36
  3. [3] langgraph-sdk==0.4.14
  4. [4] python-1.47.0

Leave a comment

0.0/5

Engineering Founded & Customer Focused

KIMBODO LLC. © 2026. All Rights Reserved.