Platforms and hybrid architectures

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.)

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:

Deterministic where precision matters, flexible where language matters.

• 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:

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

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.