# Platforms and hybrid architectures

> Cloud conversational services, open-source frameworks, visual builders and agent runtimes: how to choose, how to combine them, and how to migrate a legacy intent bot.

Source: https://conversationalaidesign.com/modules/12-platforms.html. Author: Nelson Abacherli Kawakami. Reviewed October 27, 2026.

## What you will learn
- Distinguish the main platform categories
- Choose using criteria beyond feature lists
- Place an intent platform and an LLM together in a hybrid design
- Plan a migration from an intent-only bot
- Reduce lock-in


## Five kinds of platform

The first edition of this course centered on one product, Amazon Lex. The market is wider now, and the useful question is which *kind* of platform fits. (Product names below are examples, not endorsements, and offerings change often. Check each vendor's current documentation.)

| Kind | Examples | Good for | Watch out for |
|---|---|---|---|
| **Cloud conversational services** | Amazon Lex, Google's Dialogflow family, Microsoft Copilot Studio | Contact centers, telephony, deterministic flows, tight cloud integration | Cloud lock-in; LLM features vary by vendor |
| **Open-source frameworks** | Rasa and similar | Control, self-hosting, custom pipelines | You own operations and upgrades |
| **Visual builders** | Voiceflow and similar | Fast collaboration between designers and developers | Limits when logic gets complex |
| **Agent runtimes and SDKs** | Cloud agent runtimes, agent frameworks from the major labs | LLM-first assistants with tools, memory and tracing | Fast-moving APIs |
| **Direct API plus your code** | Any model provider's API | Maximum control and portability | You build and maintain everything |

## How to choose

Skip the feature checklist and ask about constraints:

- **Channels:** web, mobile, WhatsApp, SMS, phone? Telephony is a strong reason to favor a contact-center platform.
- **Compliance and data:** where may data go, how long is it kept, who can see transcripts?
- **Team:** do you have engineers, or designers who need to ship without them?
- **Rate of change:** will content and flows change weekly? Who edits them?
- **Observability:** can you trace a conversation end to end, with prompts, tool calls and retrieved passages?
- **Cost model:** per message, per resolution, per seat, or your own infrastructure?
- **Escape hatch:** can you export flows, transcripts and tests if you leave?

## The hybrid architecture

An intent platform and an LLM are not rivals. A common, effective split:

- User → Channel (web, app, phone) → Router: intent platform or classifier → Transactions: deterministic flow with tools → Questions: RAG with citations → Open requests: agent with limits → Human handoff

- **Keep deterministic:** identity checks, payments, confirmations, anything with a legal consequence, and phone-menu integration.
- **Add an LLM for:** understanding messy input, the "didn't understand" fallback, FAQ answers grounded by RAG, summarizing a conversation for a human, and extracting slots from free text.
- **Always keep** a handoff path and a kill switch.

## A platform-agnostic fulfillment handler

Whatever platform sits in front, your fulfillment logic can stay portable. Keep it a plain function with clear inputs and outputs:

```python
def fulfill(event: dict) -> dict:
    """event: {"intent": str, "slots": dict, "session": dict, "text": str}"""
    intent, slots, session = event["intent"], event["slots"], event["session"]

    if intent == "policy_question" or event.get("fallback"):
        answer = rag_answer(event["text"], session)          # module 6
        return {"message": answer, "next": "continue"}

    if intent == "change_booking":
        return run_flow("change_booking", slots, session)   # module 9 state machine

    return {"message": "Let me connect you to a person.", "next": "handoff"}
```

Because the handler knows nothing about the platform's event format, swapping platforms means rewriting a thin adapter, not your business logic.

## Migrating from an intent-only bot

1. **Inventory.** List intents, volumes, containment and satisfaction per intent. Most traffic is in a few intents.
2. **Add an LLM fallback.** Route "didn't understand" turns to RAG or an agent and measure the difference.
3. **Move FAQ-style intents to RAG.** They are cheaper to maintain as documents than as intents.
4. **Keep the high-stakes flows deterministic**, but let the model handle the language around them.
5. **Evaluate continuously** (module 14) so you can prove each change helped.
6. **Retire intents** only when evidence shows the new path is better.

## Build or buy

| Question | Buy a platform when... | Build on APIs when... |
|---|---|---|
| Time | You need to ship quickly | You can invest in foundations |
| Team | Designers lead | Engineers lead |
| Differentiation | The assistant is a feature | The assistant is the product |
| Control | Standard behavior is fine | You need custom logic and portability |

## Reduce lock-in

- Keep **prompts** in version control, not only in a vendor console.
- Define **tools** with standards such as MCP so any runtime can use them (module 8).
- Maintain **your own evaluation set** and run it against any platform.
- **Export transcripts** regularly into storage you control.
- Wrap vendor calls behind a thin interface you own.


## Key takeaways
- Platforms differ most in channels, compliance, team skills and how much you can change.
- Intent platforms still shine for deterministic, telephony-heavy flows.
- Hybrid designs add LLMs where flexibility pays and keep rules where precision matters.
- Keep prompts, tools, tests and transcripts portable.

## Sources
- Amazon Lex: https://aws.amazon.com/lex/
- Rasa: https://rasa.com
- Voiceflow: https://voiceflow.com
- The 8 best AI agent frameworks in 2026 (Dupple): https://dupple.com/learn/best-ai-agent-frameworks