DSPy 3.5 Makes Agent Tooling Lighter—But Upgrades Still Need Evaluation

What Happened

DSPy 3.5 graduates RLM, Flex and GEPA, and makes dspy.ReAct the current name for ReActV2. The old name remains available but is deprecated until 3.6. Upgrades from 3.4.1 can change prompts, defaults and APIs, so previously optimized programs need to be tested again rather than assumed equivalent [1].

The release also makes LiteLLM and OpenAI’s Python library optional and sets model_type=”auto” and XMLAdapter as defaults. Compared with DSPy 3.3.0, the reported installed size fell from 206.7 to 30.9 MiB, dependency count from 65 to 25, and import time from 1.01 to 0.49 seconds. RLM gains saved conversation history and image-capable subqueries; tools can return rich content. Prewarmed interpreters and cached Deno startup improve sandbox performance in reported measurements [1].

Why It Matters to Businesses

Agent frameworks now cover different parts of a production system: orchestration, retrieval, typed tool interfaces, model integration, prompt optimization and coding workflows. LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, PydanticAI, DSPy, Semantic Kernel, the OpenAI Agents SDK and Claude Code should therefore be assessed against a specific workflow, not treated as interchangeable platforms.

DSPy’s smaller dependency footprint can simplify packaging and deployment. Its upgrade also illustrates a broader procurement and engineering point: a framework release may improve operations while changing agent behavior. Business-critical outputs need regression tests tied to the exact framework and model configuration [1].

Kimbodo Engineering Perspective

We would choose the smallest toolset that satisfies the workflow. A simple tool-calling service may not need a multi-agent framework; a long-running process with approvals and retries may need explicit state orchestration. We would use optimization tooling such as DSPy where there is a representative evaluation set and a measurable target—not as a substitute for one.

Framework abstractions should not own business state or security policy by default. Keeping tool contracts, authorization and audit records at application boundaries makes it easier to change models or frameworks without rebuilding the control plane.

How We Would Implement It

• Define the task, allowed tools, success measures and human-approval points before selecting a framework. Establish baseline quality, latency and cost on representative cases.
• Expose business actions through typed, validated tool interfaces. Keep credentials server-side and require authorization checks at each action, including actions proposed by sub-agents.
• Choose orchestration according to complexity: direct tool calls for short flows, explicit state and checkpoints for durable workflows, and retrieval components only where grounded access to documents is required.
• Pin framework and model versions. For a DSPy 3.5 upgrade, review the migration guidance, update deprecated ReAct usage, and re-evaluate optimized programs against the baseline [1].
• Record prompts, tool inputs and outputs, model versions, decisions and failures with appropriate redaction. Run offline evaluations before rollout and monitor production outcomes afterward.

Risks, Costs and Security

The main risks are unauthorized tool actions, prompt injection through retrieved or tool-provided content, sensitive data exposure, and silent quality regressions after dependency or default changes. Treat external content as untrusted, apply least-privilege access, constrain execution environments and require approval for consequential actions.

Lighter installation and faster sandbox startup can reduce operational overhead, but they do not establish end-to-end cost or reliability. Measure model calls, retries, interpreter time, evaluation effort and human review per completed task. DSPy’s published size, import-time and Deno-startup figures are useful indicators, not substitutes for measurements in the target deployment [1].

Sources

1. [1] 3.5.0