Spring AI 2.1.0-M1 Introduces Ordered Message Parts and OpenAI Responses API Support
The Spring AI team has released Spring AI 2.1.0-M1, the initial milestone for the 2.1 line baselined on Spring Boot 4.2.0-M2. The release fundamentally refactors how message streams and model interactions are handled by introducing an ordered MessagePart data structure (including TextPart, ReasoningPart, ToolCallPart, ToolResultPart, and MediaPart), adding a dedicated OpenAiResponsesChatModel for OpenAI's /v1/responses endpoint, and providing native VectorStore upsert capabilities for pre-computed embeddings across backends like pgvector, Redis, Elasticsearch, and Qdrant.
Historically, orchestration frameworks modeled model responses as plaintext with detached collections of tool calls and attachments. As reasoning-first and multimodal models evolved, this simplified model broke down: reasoning traces now intertwine with tool invocations, media spans arbitrary segments of output, and provider-specific opaque signatures (such as thinking blocks in Anthropic and Gemini) must be echoed back verbatim. The new MessagePart structure guarantees exact round-trip ordering and preserves opaque reasoning payloads, ensuring multi-turn agent loops retain consistent contextual state without losing model rationale.
This update reflects the broader shift across cloud and DevOps ecosystems from basic retrieval-augmented generation (RAG) toward stateful, multi-turn autonomous agents. Previous chat completion paradigms struggle with structured reasoning controls; for instance, combining reasoning effort settings with tool calling increasingly requires dedicated modern response endpoints. By adapting the core abstraction to support structured message parts and newer gateway protocols, framework maintainers are aligning enterprise backend runtimes with modern model mechanics.
In practice, engineering teams maintaining Spring-based generative AI microservices should evaluate milestone 2.1.0-M1 to prepare for the upcoming Spring AI Agents framework. While legacy getter methods remain available as views over the new parts, teams implementing agentic loops should migrate their orchestration layers to construct and consume MessagePart streams directly. This transition eliminates silent context truncation during tool chaining and ensures compatibility with strict-schema reasoning models.
Read original source