vLLM Agentic API 0.9 moves conversation state and multi-agent execution into the gateway
The release changes the application boundary: clients can address durable conversations while the gateway records and executes nested agent work as Responses items.
vLLM’s Agentic API 0.9 is less a collection of tools than a change in where an agent application keeps state and coordinates work. The release adds an OpenAI-compatible Conversations API, retrieval of stored Responses payloads, and modeled multi-agent Response items and event lifecycles, followed by HTTP execution for those multi-agent responses.
The gateway becomes a state boundary
In 0.8, the architectural work centered on operating the gateway: opt-in OpenTelemetry traces and HTTP metrics, W3C trace context, image preservation across stored continuations and transports, paginated MCP discovery, and Brave as a web-search provider. Applications still had to think primarily in terms of requests, stored Responses and their own orchestration.
Version 0.9 gives clients a conversation-shaped resource at the compatibility boundary. That lets an application identify an ongoing interaction without rebuilding all prior context into each call. Stored Responses can now be retrieved, while a continuation sent with store=false is deliberately not persisted even if its parent response was stored. That distinction matters for applications that mix durable history with transient or sensitive turns: storage intent must be set per operation, not inferred from ancestry.
The release also preserves prompt_cache_key during Responses execution. Teams using stable prefixes can therefore keep cache identity as requests cross the gateway rather than quietly losing that optimization signal. Execution traces now carry upstream context, extending 0.8’s telemetry foundation across the new orchestration path.
Multi-agent work becomes protocol data
The paired multi-agent changes model nested agent work as Response items with explicit event lifecycles, then execute those items over HTTP and verify recorded contracts. That can remove bespoke coordinator code from an application tier: a client can consume one event model while the gateway manages subordinate agent calls. Code interpreter support as a gateway execution tool and Tavily as another selectable search provider broaden what those plans can invoke.
The tradeoff is tighter coupling to gateway semantics. Event consumers should be tested against the new item lifecycle, persistence policy and failure ordering, rather than assuming a nested agent behaves like an ordinary tool call.
A practical 0.8-to-0.9 migration
Keep 0.8’s telemetry configuration and image/session regeneration requirements in place, then add 0.9 incrementally. First, adopt Conversations for one durable workflow and make every storage decision explicit. Second, test stored-response retrieval and store=false continuations as separate cases. Third, replay streaming consumers against multi-agent events and malformed-stream rejection. Finally, confirm prompt-cache keys and distributed trace context survive end to end.
That sequence preserves the operational gains of 0.8 while moving orchestration only after the application can observe and validate the new state model.
sources
- vLLM Agentic API v0.9.0 releasegithub.com
- vLLM Agentic API v0.8.0 releasegithub.com
comments · 0