Choosing Agent Frameworks: Prioritize Control, Evaluation and Deployment Fit

What Happened

Recent agent-tooling updates focus less on new agent abstractions and more on operating agents reliably. Claude Code v2.1.302 changes permission and subagent defaults across its interfaces, adds controls for auto-mode classification and compaction, and fixes issues involving plugins, MCP, cloud sessions and worktrees. Its Read tool now rejects image sources over 128 MB [1].

LangGraph CLI v0.4.36 accepts serverless and dedicated deployment aliases, and langgraph deploy uses the active Docker context [2]. Another agent-tooling release changes BackgroundTools completion metadata, Skills invocation rules and live-session handling; it also adds model-based approval for low-risk tool calls, service-tier request pricing, evaluation report naming and expanded MCP Apps frontend integration [3].

Why It Matters to Businesses

The pattern is clear: production agents depend on permissions, tool integration, deployment configuration, session recovery and cost visibility—not just model quality. Compatibility changes to tool metadata or invocation rules can break an application even when its prompts and models are unchanged [3]. Changed permission defaults likewise warrant a review before upgrading an agent with access to repositories or business systems [1].

Framework choice should follow the workload. LangChain and LlamaIndex can help assemble retrieval and tool integrations; LangGraph suits explicitly modeled, stateful workflows. AutoGen and CrewAI emphasize multi-agent coordination, while PydanticAI, DSPy and Semantic Kernel offer different approaches to typed outputs, optimization and application integration. The OpenAI Agents SDK and Claude Code are relevant when their native tooling and operating models fit the use case. These are selection considerations, not release claims about those projects.

Kimbodo Engineering Perspective

We would start with the smallest orchestration layer that makes the workflow observable and testable. A single agent with bounded tools is often easier to secure than a team of agents. Use an explicit workflow when approvals, retries or handoffs must be predictable; add autonomous delegation only where it measurably improves results. Keep business rules outside prompts and require deterministic checks before consequential actions.

How We Would Implement It

• Define each tool’s inputs, outputs, permissions, timeout and audit record. Separate read-only tools from tools that change data or execute code.
• Put retrieval behind access-controlled indexes and cite retrieved evidence in outputs. Use structured schemas to validate data passed between steps.
• Represent long-running work as persisted states with retry and human-approval points. Pin framework and CLI versions, and test deployment against the intended Docker context [2].
• Run regression evaluations for tool selection, permission decisions, compaction and session recovery before upgrades; track quality, latency and spend per task [1][3].

Risks, Costs and Security

Model-based approval of low-risk tool calls may reduce friction, but it should not replace explicit authorization for writes, payments, sensitive data access or code execution [3]. Compaction and background work can affect what context an agent retains and when downstream steps run [1][3]. Treat both as testable behavior. Budget for tokens, tool calls, evaluation runs and operational support; service-tier pricing data can improve cost attribution, but only if usage is tied to workflows and outcomes [3].

Sources

1. [1] v2.1.302
2. [2] langgraph-cli==0.4.36
3. [3] v2.57.0 (2026-10-15)