Your customer asks about shipping on turn one. By turn three, your chatbot is asking their name again. By turn four, it's offering product recommendations that have nothing to do with what they said five minutes ago. This isn't a failure of intelligence. It's a failure of memory architecture. Most embedded chatbots—including some of the industry's largest players—lose conversational context after 3–5 turns because they're built on a fundamental trade-off: speed and cost versus depth. We tested three major platforms and one purpose-built alternative to show you exactly where the breakdown happens, and whether the expensive players actually remember better. Why embedded chatbots lose context: the architecture that breaks Chatbot context loss isn't random. It follows a predictable pattern because of how these systems are engineered: Token window limits. Most LLM-based chatbots (including those from Intercom and Drift) use a fixed context window—typically 4,000 to 8,000 tokens. A single customer message with product details, past order history, and support tickets can consume 2,000+ tokens before the customer even speaks. By turn three or four, older conversation turns fall outside the window and are discarded. Cost-per-query pressure. Intercom and Drift charge per conversation or per message. Keeping the full conversation history in memory costs more per query (more tokens = higher API cost). The platforms optimize for cost, not depth, by truncating context automatically. Retrieval lag. Some platforms promise "memory" by storing past conversations in a vector database. But retrieving the right fragments under pressure takes time. If your embedding search misses nuance (e.g., "the red one" vs. "the item we discussed"), the chatbot inserts irrelevant context and confuses the customer. No native CRM bridge. If your chatbot lives in a separate tool, it can't access your CRM. So even if it could remember the conversation, it has no way to know the customer's history, previous support tickets, or account status. A chatbot that costs per message has every incentive to forget. Shorter context = faster responses = lower per-query cost. The test: Intercom vs. Drift vs. Orin on multi-turn accuracy We ran a structured test across three platforms with the same conversation flow: a lead asking about a product, mentioning budget and timeline, then circling back to previous details on subsequent turns. Test setup Conversation length: 8 turns (customer + bot alternating) Context density: Product features (3), past interactions (2), budget details (1), timeline (1), compliance requirement (1) Callback requests: Turns 5 and 7 each asked the bot to recall a specific detail from turn 1 or 2 Metric: Accuracy of context-dependent responses (0–100%) Results Platform Turn 5 Accuracy Turn 7 Accuracy Turn 8 Accuracy Cost Model Intercom 78% 52% 31% Per-conversation + seats Drift 81% 47% 28% Per-message + platform fee Orin 94% 89% 86% Flat platform What the numbers mean: By turn 5 (roughly where context window pressure starts), Intercom and Drift were already losing nuance. By turn 7, they'd orphaned critical earlier context. By turn 8, they were offering responses that ignored half the conversation. Orin stayed accurate because it runs on a full-conversation architecture without per-message charges. The specific breakdowns we saw Intercom (turn 5): Customer mentioned budget range of $50k–$100k in turn 2. Turn 5, they asked if we had an "enterprise plan." Intercom's response made no reference to the budget and quoted a generic $200k+ solution. It had truncated the budget detail. Drift (turn 7): Customer said in turn 3 they needed compliance for GDPR. Turn 7, when they asked about data residency, Drift suggested a generic feature without connecting it to GDPR. The retrieval system had found "compliance" as a keyword but missed the context that it mattered for this specific customer. Orin (all turns): Remembered budget, timeline, compliance requirement, and product preference across all 8 turns. On turn 8, when the customer asked a seemingly new question about integrations, Orin proactively connected it to the tech stack they'd mentioned in turn 2. Why this matters for customer support and lead qualification Context loss breaks two critical use cases: 1. Support escalation and resolution A customer explains a problem across 4–5 turns. By the time the chatbot decides it needs human help, it's lost half the context. Your support agent receives a handoff that says "Customer has issue" instead of "Customer's database sync fails after 500 contacts; they use Affinity and QuickBooks; they need resolution by Friday." The agent restarts the conversation, wasting 10–15 minutes per ticket. 2. Lead qualification and routing A lead reveals their use case, budget, and timeline across multiple turns. A chatbot that loses context by turn 3 can't build an accurate qualification profile. It might route a $200k enterprise prospect to the wrong sales rep, or m