AI Agent Memory
Give the autonomous AI Agent customer-level memory: before responding, the agent reads the customer's cross-module profile and history (conversations, tickets, campaign engagement, orders, loyalty) from CEBE — the Customer Event-Based Engine — so a returning customer is recognized, known facts are not re-asked, and open ticket/order state informs the answer.
Today the agent is context-blind across modules and stateless per turn on the chatbot BE: only the current message is sent to the AI service, conversation state lives in the AI-service thread, and no cross-conversation or contact-level memory exists anywhere in the stack. CEBE's own anchor names the consequence: "a ticket resolved in the support module never informs the AI Agent handling a follow-up sale."
This initiative is the consumer piece of CEBE (CDP squad, epic TF-3302): CEBE builds the backbone (Central DB + retriever + query layer); AI Agent Memory is its flagship downstream — the CEBE roadmap row "Agentic AI reads CEBE memory — Eng (Chatbot) — Q4 2026" and the initiative-level success metric "AI Agent uses CEBE memory in ≥50% of conversations by end of Q4 2026" are delivered here.
Phases
| Phase | Scope | Status | Epic |
|---|---|---|---|
| Phase 1 — Read-side CEBE memory | The AI service reads the customer's CEBE profile/history (keyed qontak_customer_id) at conversation start and uses it in responses; flag-gated per org; graceful degradation when CEBE data or identity is unavailable | PRD draft | TBD |
| Future — Agent-authored memory write-back | Agent writes learned facts (preferences, commitments, declared attributes) back as CEBE events — requires net-new AI event types in the standardized schema | Not committed | — |
| Future — Tenant memory controls | Admin UI to view/edit/delete a customer's memory, retention settings, opt-out (UU PDP erasure obligations) | Not committed | — |
Cross-repo & dependencies
- CEBE core infra (P0 blocker) — cdp/customer-event-based-engine-cebe (TF-3302): Central DB + Retriever/Metrics layer + query approach must be live. Schedule risk: the joint Eng+Data RFC (due Jul 2026) is escalated in the CDP sprint — a Q3 slip cascades into this initiative's Q4 target.
- DSAI (P0, external squad) — the AI service queries the CEBE retriever directly per conversation and injects the result into the agent's reasoning. Chosen over chatbot-BE-side assembly (see the Phase-1 PRD's recorded avoidability check); gated on an explicit DSAI contract + capacity commitment before BUILD.
- chatbot (Rails BE) — small but real: the predict payload passes
qontak_chat_customer_id = contact.channel_contact_idtoday, notqontak_customer_id; the identity chain room → contact →qontak_customer_idmust be resolvable/passed. Plus the org-level feature flag (system_preferences rollout-group pattern). - Data — memory reads logged per response into the AI Activity Log datamart (system of record for the ≥50% adoption metric and the memory-vs-non-memory outcome comparison).
- Design — no memory-related design exists in qontak-designer (census 2026-07-22). Phase 1 is flag-only (no FE surface); any V2 agent-config toggle needs a design request first.
Scope Changes
- Backend — chatbot BE: pass/resolve
qontak_customer_idin the AI-service payload; org-level feature flag; timeout/fallback behavior owned at the emit chokepoints. (The retriever client itself is DSAI-side, outside this repo's surfaces.) - Data — per-response memory-read telemetry into the AI Activity Log datamart; adoption + outcome metrics queries.
QA Lane
Lane B — keeps a human QA gate. The memory read sits on the real-time agent response path (latency- and timing-sensitive), and no E2E test specs exist for this initiative yet, so the Lane-A entry bar (100% E2E, spec-mapped coverage) is unmet regardless. Classified 2026-07-22.
Positioning vs adjacent initiatives
- ai-agent-knowledge = company-level knowledge (what the business knows — KB, high-performing conversations). Memory = customer-level context (what we know about this customer). Different axes; no overlap in v1.
- Future consumers, noted not depended on: the Automation Flow Builder engine and Live Monitoring/ROI reporting reuse the same telemetry chokepoints and could read the same context.