Quick answer: Conversation-AI buyers are seeing product changes, but they are not one shared retirement event. Google publishes a lifecycle guide for Dialogflow ES and CX; check it and your project's notices for the dates that apply to your deployment. Amazon Lex V2 remains documented as a voice-and-text bot service. Amazon Bedrock Agents Classic, meanwhile, stopped accepting new customers on July 30, 2026, and AWS points new builds toward AgentCore—not toward a Lex migration. AWS says existing Agents Classic workloads remain available with no planned end-of-life date. There is no public, universal Lex-to-Bedrock conversion date or automatic conversion path in those documents. Treat the vendor notices as separate planning tracks, then choose a destination by the kind of agent you actually operate.
This is a buyer's decision map, not a vendor pitch. It does not promise a Dialogflow or Lex importer on Devotel Orbit.
Start with the agent you have
“Dialogflow replacement” can describe several different builds. Identify the work your current agent performs before comparing platforms.
- Scripted decision tree (often Dialogflow ES). Intent and entity matching select a defined response or fulfillment path. The valuable assets are training phrases, intent/entity definitions, slot prompts, fallback behavior, and webhook contracts. A language-model prompt is not automatically an equivalent replacement: reproduce required branches and test the utterances that reach them.
- Large-model conversational agent (often Dialogflow CX or a custom CX flow). The agent may combine flow pages and routes with generative responses, grounding, tools, and handoff. Preserve the flow boundaries, tool permissions, escalation rules, and tests—not only the system prompt. Google's product naming and lifecycle guidance is evolving, so verify the exact product and feature set attached to your project.
- Voice-first agent (Vapi, Retell, or Bland). Latency, interruption handling, speech recognition, voice selection, call transfer, and telephony routing are core design choices. A chat-agent builder is not a substitute for a voice path unless its runtime and phone integration meet your call requirements.
- Contact-center suite (Genesys or Cognigy). The conversational agent is one part of a larger operating environment: routing, workforce workflows, human handoff, analytics, and existing CRM/contact-center integrations can outweigh the bot canvas. Compare the full operating model, not just the prompt editor.
A Lex bot is not automatically one of those categories either. Lex V2 combines intent/slot-oriented conversation design with speech and text interfaces; inspect its intents, slots, Lambda fulfillment, channels, and any Amazon Connect integration before deciding what needs to be rebuilt.
How Devotel Orbit maps to those needs
Devotel Orbit has several distinct agent-building surfaces. They are building blocks for a new design, not a claim that an existing vendor project can be imported unchanged.
- Prompt-led starting point: Create an agent from a prompt to scaffold an agent from a natural-language description. Review the result and configure it for the real task; generated configuration is a starting point, not proof of behavioral parity.
- Reusable instructions: Prompt templates for shared, reusable prompt patterns.
- Coordinated work: Squads for organizing multiple agents around a workflow.
- Grounding: Knowledge base for grounding agent responses in tenant-provided material.
- Runtime oversight: Guardrail analytics for production guardrail telemetry. Telemetry helps teams inspect behavior; it is not, by itself, a replacement for an offline evaluation suite.
- Continuity: Agent memory for inspecting and curating agent memory associated with contacts.
Map the archetypes accordingly. A scripted ES bot usually needs its branches and fulfillment rules re-authored and tested; a prompt-led design can be a new implementation, not an intent importer. A CX-style agent can map flow responsibilities to prompts, tools, grounding, squads, and handoff rules where those fit. A voice-first team must separately validate speech, interruption, transfer, and its telephony path. A contact-center suite buyer should first inventory routing and human-agent workflows that an agent builder alone does not replace.
Decision matrix: compare the control surface, not the logo
“BYO” below means the buyer controls the component directly, not that a provider supports every possible model, carrier, or connection. The vendor documentation linked in each row defines the stated product boundary. Orbit's entries describe the dashboard surfaces above; confirm account-specific model and channel availability in the product before committing to an architecture.
| Platform | Scripting surface | BYO LLM | BYO telephony | Channel breadth | Deployment | Evaluation |
|---|---|---|---|---|---|---|
| Devotel Orbit | Prompt-led agent setup, reusable templates, and multi-agent squads; not a Dialogflow flow importer | Model presets are available; confirm provider and key options for your account rather than assuming arbitrary model access | Voice is part of Orbit's communications platform; this is not a claim that any carrier or external telephony account can be attached | Agent surfaces sit alongside Orbit's voice and messaging products; validate each required channel against the current product docs | Managed dashboard and platform runtime; configure agents in the tenant workspace | Guardrail analytics provide production telemetry; pair with a task-specific test/evaluation process |
| Dialogflow ES | Intent, entity, and fulfillment-oriented conversational design | Google-managed NLU/agent service; external fulfillment can call other services, but that is not equivalent to choosing any LLM in the ES runtime | Telephony is through supported integrations/partners, not arbitrary carrier control by default | Integrations and supported surfaces vary; use Google's integration documentation for the exact channel | Google Cloud managed service | Google documents testing and analytics features; verify which apply to your ES project and target version |
| Dialogflow CX / Conversational Agents | Flow/page, route, and agent configuration; product names and feature boundaries are changing | Google documents generative features and model options for eligible surfaces; do not infer unrestricted BYO model access | Supported telephony integrations depend on the selected product and setup; validate the intended carrier path | Google documents integrations across multiple conversation surfaces; exact availability is product-specific | Google Cloud managed service | Console testing and evaluation/analytics capabilities depend on the product and feature in use |
| Amazon Bedrock Agents | Agent instructions, action groups, knowledge bases, and orchestration | Select from Bedrock-supported foundation models; this is not an unrestricted endpoint for arbitrary models | Telephony is assembled through AWS integrations/application code, not included as general carrier control in the agent service | Application integrations are composed through AWS services and APIs | AWS-managed service; agent versions and aliases are part of deployment | Test, trace, and inspect agent execution; use a separate evaluation approach for broader quality gates |
| Amazon Lex V2 | Intents, slots, dialog prompts/branches, and Lambda fulfillment | Lex provides its own NLU/ASR; AWS documents Assisted NLU, not general BYO LLM runtime control | Voice integration options exist through AWS services such as Connect; not arbitrary carrier control by default | AWS docs describe voice/text and supported integrations; verify the required channel and region | AWS-managed bot service with versioned deployment | Test bots in the console/API and monitor through AWS tools; confirm the quality gates your team needs |
</table>
The matrix is a first-pass architecture screen, not a feature guarantee. In particular, do not equate an integration with ownership of the connected telephony or model layer. Confirm product edition, region, account eligibility, and the current vendor docs for each required cell before sizing a migration.
2026 calendar: separate published lifecycle notices from assumptions
Vendor lifecycle pages change. The linked official pages are the source of truth; check them again when you schedule work and retain any account-specific notice. As of this article's review, the public documentation supports these planning statements, not a single cross-vendor shutdown deadline:
| Surface | Publicly documented position | Planning date or trigger |
|---|---|---|
| Dialogflow ES | Google maintains lifecycle guidance for Dialogflow products. Do not infer a shutdown date from a product label or an unrelated 2026 calendar entry. | No blanket end-of-life date is asserted here. Check Google's live lifecycle guidance and your project notice before treating ES as scheduled to shut down. |
| Dialogflow CX / Conversational Agents | Google has updated product naming and capabilities around its conversational-agent offerings. A naming or feature transition is not, by itself, a CX shutdown date. | Check Google's lifecycle guide and the product/region notice tied to your project; plan for any explicitly dated feature or product change, not an inferred global EOL. |
| Amazon Lex V2 | AWS continues to document Lex V2 as a service for building voice and text conversational interfaces. Its public guide does not establish Lex V2 as migrated into Bedrock Agents. | No universal Lex V2 retirement date is stated in the linked Lex documentation. Continue monitoring AWS service announcements and your account notices. |
| Amazon Bedrock Agents Classic | AWS says the service stopped accepting new customers on July 30, 2026; existing customers can continue using it in maintenance mode. AWS recommends Amazon Bedrock AgentCore for similar capabilities. This is not a Lex V2 retirement announcement. | July 30, 2026: new-customer closure and model-catalog freeze. AWS says there is no planned end-of-life date for existing Agents Classic workloads. |
Runbook split: First, inventory exact product names, regions, agent versions, connected channels, fulfillment code, model dependencies, test cases, and account notices. If the vendor names a bounded feature change and the agent's logic remains yours, plan a surface swap: update the affected integration or configuration, then rerun the same acceptance cases. If the runtime, flow model, fulfillment contract, state, or channel changes, plan a full migration: re-author the behavior, port or recreate the integrations, run old and new paths against a representative test set, and cut over only after parity and handoff behavior are accepted. No public statement reviewed here warrants scheduling a Lex-to-Bedrock migration solely because Lex is supposedly being absorbed.
The tenant-owned control list
Before a move, make a copy of the parts your team owns and can validate: knowledge-base paths and source material, prompt-template slots and version history, squads canvases and handoff boundaries, tool/fulfillment contracts, and representative conversations with expected outcomes. Keep each vendor's export as an archive until the replacement passes the tests. Orbit does not promise to translate Dialogflow or Lex artifacts automatically; treat each as source material for a deliberate rebuild.
Compliance configuration belongs to the tenant. Review the tenant's own data-retention, consent, and access settings as part of the cutover; this article does not claim a platform-wide compliance guarantee.
A parallel case: AI API deprecations
Agent builders are only one source of change. The OpenAI API deprecation explainer separates API-surface retirements from model changes and explains why the integration inventory matters. Apply the same discipline here: name the exact surface, verify the vendor's dated notice, and scope the response to the dependency that actually changes.
Frequently asked questions
Is Dialogflow ES or CX definitely shutting down in 2026?
Do not infer a universal project deadline from a calendar mention or product rename. Google's lifecycle guide and any dated notice for your project are the sources to check. If no applicable end date appears there, treat the date as unconfirmed and ask Google for written clarification before planning a shutdown.
Is Amazon Lex being replaced by Bedrock Agents?
The official AWS pages linked here do not say Lex V2 is being retired or converted into Bedrock Agents. AWS says Bedrock Agents Classic stopped accepting new customers on July 30, 2026, and points new builds to Bedrock AgentCore. Those are separate product facts, not a Lex end-of-life announcement.
Can Devotel Orbit import my Dialogflow or Lex bot?
This article does not announce an import wizard or automatic migration. Treat your current bot's flows, intents, prompts, fulfillment code, tests, and channel setup as source material to inventory and re-author against the destination's actual controls.
Which replacement should I evaluate first?
Start with the agent archetype and the dependency most expensive to recreate. For a decision tree, test branch and fulfillment parity. For a generative agent, test grounding, tool boundaries, and handoff. For voice, measure the actual call path and transfer behavior. For a contact-center suite, include routing and human operations in the evaluation.