The open-source landscape, by layer

Everything below was verified against the GitHub/HuggingFace/npm APIs or the vendor's own docs on 2026-09-15. "Fit" is 1–5 against this problem (long-horizon, offer-withholding, Ukrainian/Russian, Telegram+Viber+WhatsApp, 2–4 engineers) — not general quality. A project can be excellent and score 1.

Licence flags used throughout: OSI = genuinely open source · open-core = permissive core with a proprietary ee/ or enterprise/ tree · source-available = BSL/SSPL/Elastic/FSL/Commons Clause, not open source · non-commercial = CC-BY-NC or equivalent, unusable in a revenue product · use-restricted = RAIL/Llama/Gemma community licences with acceptable-use policies that flow down.

---

1. Memory & the persistent customer model

How to choose here. Split the layer in two and do not let them blur. The authoritative half — relationship_stage, trust_score, readiness_score, last_offer_at, offers_in_30d, consent, channel-window expiry — goes in typed Postgres columns written only by deterministic code, because offer gating must be unit-testable, atomically updated and auditable after a complaint. The fuzzy half — "what did she say about her sister's wedding in June" — goes in an engine. For the fuzzy half the real decision is temporal invalidation vs operational simplicity: Graphiti wins on invalidation and loses on backends (there is no permissively-licensed production graph store left); Hindsight wins on one-container MIT simplicity and loses on bi-temporal validity. At 500–50,000 customers, take Hindsight or roll bitemporal columns yourself (valid_from, valid_to, asserted_at, superseded_by — four columns and a close-and-supersede rule) and skip the graph database entirely. Whatever you pick, add an explicit expiry class at write time (permanent: allergies, sizes · seasonal: pregnancy, injury, relocation · decaying: purchase recency), because decay and invalidation are different mechanisms and you need both.

Things that sound right but aren't (memory). "Self-host Zep" — dead, moved to legacy/, and the repo still commits daily so a liveness check gives a false green. "Mem0 has decay and temporal reasoning" — Platform-only, and the OSS SDK dropped external graph stores in the April 2026 rewrite. "Supermemory is MIT and self-hostable" — the MIT repo is SDK surface; the engine ships as a closed single-machine binary. "PowerMem gives you Apache-2.0 Ebbinghaus decay" — it rebranded to PowerContext, restarted at v0.1.0 on 2026-08-31, pivoted to coding-agent work handoff, and its README now contains zero mentions of decay, profiles or forgetting. "Memobase is actively maintained" — one commit in all of 2026. "lifetimes for CLV" — archived 2024-06-28.

---

2. Conversational policy / guideline / journey engines

How to choose here. Three layers, and conflating them is the standard mistake. (a) Deterministic enforcement — OPA/Cedar, or a plain Python function with a gate_version constant and a table-driven test suite. Anything countable (caps, cooldowns, quiet hours, window state, complaint status) lives here, gating the tool call. (b) Durable orchestration — LangGraph (Postgres checkpointer plus the cross-thread Store) or Pydantic AI on DBOS/Temporal, so a relationship survives a three-week gap and a deploy. (c) Conversational shaping — Parlant strict canned responses or NeMo predefined-response substitution, so the model's words are constrained on any turn that mentions a price, spec, stock level or delivery date. For a 2–4 person team the honest month-one answer is: skip (a)'s DSL, write the gate as ~300 lines of Python with gate_version pinned to a git SHA, and keep the migration to Rego mechanical by keeping the gate I/O-free (state in, decision object out).

Things that sound right but aren't (policy). "Use Rasa for intent + flow guards" — Apache repo is frozen and in maintenance mode; the guards are in proprietary Rasa Pro. "Flowise for a quick visual prototype" — archived. "Semantic Kernel's Process Framework models business processes" — maintenance mode; the concept survives in MAF. "Hatchet is the lightweight Temporal" — its own docker-compose.yml needs Postgres + pgbouncer + RabbitMQ + NATS, four stateful services including two brokers; minimal Temporal runs on plain Postgres with no Elasticsearch. "Challenger's Take Control" — its evidence is manager-rated self-report with no peer-reviewed replication, and "take control" maps onto aggressive sales pressure, which the JAMS work shows damages trust in both seller and company. Take Teach and Tailor, drop Take Control.

---

3. Existing sales / SDR / conversational-commerce prior art

How to choose here. The blunt finding: no open-source project does what this user wants. Every piece of prior art is a single-session closer. GitHub repo search on 2026-09-15 returns total_count=0 for "customer lifetime value agent LLM" and "proactive re-engagement agent messaging", and exactly one 1-star result for "sales conversation stage llm". So assemble from three unrelated places: SalesGPT's two-chain decomposition (but with persisted state instead of a recomputed stage), the MEDDIC/SPIN skill pack's evidence-scored rubric (re-derived for B2C), and b2b-sdr-agent-template's channel-window cron and memory layering. Then build the readiness gate yourself — it is the product, and it is a small amount of deterministic code.

Things that sound right but aren't (prior art). "Start from SalesGPT" — 25 months dead, pinned to a 2024-era LangChain, and architecturally incapable of cross-session state. "CRMArena is the benchmark for withholding" — CC-BY-NC, legally unusable in a commercial pipeline, mirrors on HuggingFace carry the same terms. "Shopify's agent is open source" — it isn't. "Use the retail domain in tau2-bench as-is" — it's returns and order modification, i.e. customer service, not advisory selling, and it's single-episode. "antiwork/helper is the leading OSS AI helpdesk" — github.com/antiwork/helper returns HTTP 404 and is absent from the org's 67 repos, yet it's still recommended by 2026 blog posts and has a live Play Store listing.

---

4. Customer care platforms / omnichannel inbox

How to choose here. Adopt the inbox, build the brain, and never let the helpdesk own your relationship model. Chatwoot's MIT core gives you three genuinely expensive things — native Telegram+WhatsApp transport with media and delivery semantics, a human agent workspace with assignment and escalation, and a contact record that survives across conversations — and gives you nothing on relationship stage, trust or offer timing, which is fine because those belong in your Postgres anyway. Keep relationship_stage/trust_level/upsell_readiness authoritative in your DB and mirror them into Chatwoot custom_attributes (which require a CustomAttributeDefinition to become filterable in automations and campaign audiences — pay that schema cost). If you ever leave, you lose a projection, not your brain. For a month-one team the even smaller answer: a needs_human flag plus posting the thread into a private Telegram group with a deep link is ~40 lines and zero new services.

Things that sound right but aren't (care platforms). "Chatwoot gives you a free self-hosted AI agent" — Captain's backend is 252 files under enterprise/ and needs a paid subscription in production. "Chatwoot has Viber" — it doesn't, and two issues asking for it were closed unimplemented. "lib/captain/follow_up_service.rb is re-engagement" — it's an agent-facing editor refinement loop; Captain does no proactive customer nurture. "Papercups is a live OSS option" — 6,104★, MIT, never formally archived, but its default-branch last commit is 2022-05-10. "antiwork/helper" — 404.

---

5. Channel libraries & gateways (Telegram · WhatsApp · Viber)

How to choose here. Telegram first, always: free, no window, no templates, and therefore the only channel where you can A/B "withhold vs offer" without the result being confounded by per-message cost or template-approval latency. Ship aiogram (Python) or grammY (TypeScript). WhatsApp second, via Cloud API direct or a flat-fee BSP — never a per-message BSP, because Twilio's verified $0.005 applies inbound and outbound, including on messages Meta bills at zero, which is exactly the traffic a chatty advisor generates ($800/month at 50k customers vs ~€49/month flat on 360dialog). Viber last and hardest: nothing exists, so budget ~12.5 engineer-days — webhook + CA-signed cert (self-signed explicitly unsupported; issuer must be on the Sun Java trusted root list) 1d · HMAC-SHA256 X-Viber-Content-Signature validation 0.5d · all 7 event types 2d · idempotency on message_token 1d (mandatory — Viber retries 10× with exponential intervals from 10s to 900s, so duplicates are guaranteed, and a duplicate here means re-sending an offer) · outbound text/picture/rich_media 2.5d · user-id↔contact mapping and a verification flow 2.5d (Viber exposes no phone numbers) · rate limiting 1d · tests and monitoring 2d. And start the Rakuten Viber commercial application in week one: bots have been commercial-terms-only since 2024-02-05, partner onboarding plus Viber's own 2–3 day review runs 2–4 weeks, and it becomes the critical path otherwise.

Things that sound right but aren't (channels). "Meta publishes a Node SDK" — archived since June 2023. "Telethon is the Python Telegram library" — archived, moved to Codeberg, and it's a user-account library anyway. "tdlib is BSL" — it's the Boost Software License, permissive and OSI-approved; rejecting it on the abbreviation is a mistake in the other direction. "Botpress is MIT and self-hostable" — the runtime is proprietary cloud; the self-hostable v12 is AGPL and last pushed 2025-04-10. "Evolution API is Apache-2.0" — it's Apache with additional conditions including a mandatory in-product attribution notice. And a process finding worth internalising: GitHub's pushed_at is not a liveness signal — it counts branch and tag pushes. It overstated viber-bot-python by 3+ years, viberroo by ~18 months and Papercups by ~21 months in this corpus alone. Always check the default branch's last commit.

---

6. Product grounding, RAG & recommenders

How to choose here. At 5k SKUs / 50k customers the binding constraint is data volume, not model class — Ludewig & Jannach's repeated studies found heuristic session-kNN matches or beats GRU4Rec/NARM/STAMP/SR-GNN across most configurations, and the Next-Basket Reality Check found most neural gains come from the repetition component rather than genuine exploration. So budget one week to prove a neural model beats a time-decayed item-similarity baseline on a time-based holdout, expect it not to, and be pleased. Two architectural rules matter more than any model choice. First: vector similarity is a substitute detector, not a complement detector — embedding "more like this" recommends a rival jacket to someone who just bought a jacket, which reads as not listening; build two item-item matrices (co-purchase → complements, co-view-without-co-purchase → substitutes) and serve only complements post-purchase. Second: free-text RAG is the wrong primitive for specs — embedding similarity cannot reliably distinguish "waterproof to 5 ATM" from "3 ATM", and the business consequence is opposite. Extract specs once into typed attributes (Docling → GLiNER2/LangExtract), store them filterable, and let the model read fields. Reserve RAG for reviews, how-tos and returns policy.

Things that sound right but aren't (recsys/grounding). "Use Transformers4Rec for session-based recommendation" — no release since January 2024, all recent commits are security fixes, and it's the wrong model class anyway. "LightFM is perfect for small catalogues with cold-start" — master dead since April 2023, and it's a C extension. "Typesense looks abandoned" — main is stale; v31 ships weekly. "R2R for RAG" — ~8.0k★ but last commit 2025-11-07. "Superlinked for recsys-aware embeddings" — the Python framework is deprecated in favour of an inference server. "Anti-hallucination is handled, we have a guard model" — Granite Guardian 4.1's own card says "The model is only trained and tested on English data", and HHEM-2.1-Open is language: en while the paid HHEM-2.3 covers Russian but not Ukrainian at any price. A guard that silently scores out-of-distribution input is worse than no guard: it paints a green dashboard while the bot invents specs in Ukrainian.

---

7. Offer-timing models — CLV/BTYD, survival, uplift, bandits

How to choose here. Decompose "only offer when prepared" into four separable questions and pick per question: who is worth attention (BTYD → PyMC-Marketing) · when is the natural need window (survival → lifelines, then XGBoost-AFT) · would my message change anything (uplift → CausalML/EconML) · which message, learned online (bandits + OPE → contextualbandits/bayesianbandits). Two disciplines dominate the tooling. Individual-level uplift is statistically out of reach at this scale and recommending it would be malpractice — uplift estimates a difference between two noisy conditional expectations, needing roughly 10–100× the data of a propensity model, with reliable per-customer CATE wanting >10k treated plus >10k control; the correct substitute is a permanent randomised global holdout (suppress ~10% of intended offers) measuring one average incrementality number. And log action propensities from day one — it is one line per decision, it is the only thing here that is truly unrecoverable, and it is what lets every future policy be tested against a year of real logs without messaging a single customer.

Things that sound right but aren't (offer timing). "Use lifetimes for CLV" — archived 2024-06-28; so is btyd. "scikit-uplift for uplift" — four years dead, and its own docs claim otherwise. "Open Bandit Pipeline is the OPE library" — nearly four years dead; vendor the math. "Optimise the score against offer acceptance" — the model will learn that manufactured urgency, flattery and pitching into emotional vulnerability all raise acceptance, and you will have built a pushy bot with a trust-shaped score as cover. The label must be compound and long-horizon: accepted AND no complaint/unsubscribe/block/churn in 60–90 days AND next-period order value not down. "A deterministic gate is fine, we'll add exploration later" — you cannot; deterministic propensities are 0 or 1, importance weights are undefined or infinite-variance, and OPE is foreclosed on that data permanently.

---

8. Signal extraction — reading the customer

How to choose here. Build three scores on three timescales and gate them conjunctively, never one additive number: R (relationship capital, decays with a ~45-day half-life of silence, floored at 0.4× peak), N (need/fit evidence, resets per need-episode, with slot coverage and price-band fit as hard sub-gates), M (moment, per-turn, sub-50ms). The heaviest single R feature is advice-acceptance rate — the fraction of bot recommendations followed within two turns — because that is the operational definition of advisor status. Percentile-normalise every engagement feature within channel (Telegram gives no read receipts at all, so a pooled model makes every Telegram customer look systematically colder and they will never receive an offer) and mark unavailable features missing, never neutral. Route by cost: GLiClass as the cheap first pass on every turn, promote only low-confidence turns to a SetFit head or an LLM judge, and push ConvoKit's Coordination/TalkTimeSharing/Politeness to a batch job at session close.

Things that sound right but aren't (signals). pysentimiento — its LICENSE says "for non-commercial use and scientific research purposes only"; disqualified despite being the standard multilingual-social-NLP recommendation. tabularisai/multilingual-sentiment-analysis (143k dl/mo, 23 languages) and tabularisai/multilingual-emotion-classification — CC-BY-NC-4.0. cardiffnlp/twitter-xlm-roberta-base-sentiment — 1,020,636 downloads/month and NO LICENSE TAG AT ALL, meaning no rights are granted by default. MilaNLProc/xlm-emo-t — 485,865 dl/mo, no licence, frozen since 2023-03-27. facebookresearch/fastText — archived 2024-03-22. snips-nlu — last push 2023-05-22. And the one that will actually bite: running ConvoKit's English politeness lexicon over Ukrainian fails silently — it returns a plausible near-zero for every message rather than an error, and an unvalidated rapport score gating revenue decisions is worse than no score because it looks like evidence.

---

9. Guardrails, manipulation limits & PII

How to choose here. Three tiers with different jobs. (1) Deterministic policy (OPA, or plain code) for anything countable and auditable — this is where the never-list lives, gating the tool call. (2) Behavioural/conversational (Parlant strict mode or NeMo rails) so the model's words are constrained on claim-bearing turns. (3) Model judges (Granite BYOC for English, Qwen3Guard for multilingual, LettuceDetect for groundedness, Detoxify/textdetox for toxicity) with cost-tiered routing — cheap classifier on every message, expensive judge only on offer- or claim-bearing turns. Two rules make the difference: gate actions, not text (if the model can mention a product in free prose, no tool-level gate helps — force every offer through a tool), and implement vetoes as a separate boolean layer evaluated AFTER scoring, backed by cheap multilingual keyword rules, so a model outage cannot silently un-veto.

Things that sound right but aren't (guardrails). The four most-cited tools are dead: LLM Guard archived 2026-07-09, Rebuff archived (dormant since Aug 2024), protectai's injection model archived while still pulling 859k downloads/month, Azure/PyRIT archived 2026-03-27 (live project moved to microsoft/PyRIT), Fides archived 2026-08-28. Licence traps concentrate in the most-downloaded artefacts: pysentimiento non-commercial, tabularisai CC-BY-NC, cardiffnlp no licence at all, Qwen3Guard's repo unlicensed while its weights are Apache. Arize Phoenix is Elastic License 2.0 — widely described as open source, and it isn't; Opik gives comparable evaluation under Apache-2.0, so choosing Phoenix means taking a non-OSI licence for no benefit. And the most consequential one for this build: tdlib/telegram-bot-api is BSL-1.0 = the Boost Software License, permissive and OSI-approved — not the Business Source License. Rejecting it on the abbreviation is a mistake in the opposite direction.

---

10. Orchestration & proactive scheduling

How to choose here. The crux — "schedule a check-in, cancel it if the customer writes in first, re-evaluate eligibility at fire time" — decomposes into two decisions people conflate. Cancellation is trivial everywhere (delete a row, complete a token, send a signal). Re-evaluation at fire time is not a scheduler feature at all — it is a discipline: the scheduled payload must contain only {customer_id, intent}, never a decision or a rendered message. So choose on operational cost, and the ranking by services you must operate is stark: pg-boss / Graphile Worker / pgmq / Procrastinate = 0 new services; DBOS = 0 new services (a library); Temporal minimal = 1 server + your Postgres; Hatchet = 4 stateful services. At 2,000–50,000 customers the sophisticated engine buys you nothing the simple row does not. Revisit Temporal when you genuinely need long-running multi-service sagas with versioned workflow migrations.

Things that sound right but aren't (scheduling). "Hatchet is the lightweight Temporal" — four stateful services vs Temporal's one, and Temporal doesn't need Elasticsearch. "Celery's countdown handles delayed tasks" — it does not durably park them. "Inngest is open source" — SSPL, and its self-host defaults are SQLite plus in-memory Redis with no automatic row deletion. "Restate's durable sleep solves this" — the docs warn long sleeps block the Virtual Object's other requests, which deadlocks a per-customer object. "Dittofeed is a ready-made engagement platform" — six months dark on alpha-only releases, with multi-tenancy closed-source. "Novu handles multi-channel" — no Viber provider, and it splits consent state away from the gate that must read it.

---

11. Evaluation & simulation

How to choose here. There is no open-source benchmark for multi-session, long-horizon relationship selling — every agentic benchmark verified here evaluates a single session with a single goal, and every memory benchmark evaluates whether the agent can answer from long history, never whether it decides correctly from it. So assemble: fork tau2-bench for the verifiable-DB-state reward and pass^k, take IntellAgent's policy-graph generator, and wrap both in a Concordia Game Master that advances the clock in days between sessions and decides whether the customer opens the app at all ("no reply" must be a first-class outcome). Then guard against the trap that dooms most eval suites here: the default metrics are adversarial to your goal. DeepEval's ConversationCompleteness and TurnRelevancy reward a bot that says more, offers more and agrees more; an LLM judge asked "was this helpful?" reliably prefers the sycophantic over-helper. Every quality metric must be paired with an adversarial veto — dark-pattern rate, simulated abandonment, real opt-out rate — and a variant that raises conversion while raising sneaking is rejected, full stop.

Things that sound right but aren't (eval). RecSim and RecSim NG — both archived. Argilla is effectively abandoned post-acquisition (develop last commit 2025-08-05, no commits since March 2026) — use Label Studio (Apache-2.0, 28k★, actively maintained) for the labelling loop, and note that its inter-annotator agreement metrics are Enterprise so you'll compute kappa yourself. LoCoMo and CRMArena and the Duolingo replication dataset and PersonaHub's persona data and Criteo-UPLIFT — all non-commercial. RecSim, Sotopia, LongMemEval, Prometheus-Eval, Verdict, DarkBench, zr-obp, SCOPE-RL — all stale to varying degrees. And two structural mistakes that cost more than any tool choice: measuring per-turn quality instead of per-conversation (ALMITA's central finding is that agents which look strong on individual interactions frequently fail complete conversations — and the gap widens again across sessions), and testing only on clean monolingual messages when OLA (ACL 2026) measures output-language pass rates of 60.9–85.8% under code-switching even when the cue is explicit, with over 92% of users rating a language mismatch "Uncomfortable or Critical".

---

12. LLM runtime & models

How to choose here. Two 2026 facts invert 2024-era instincts. Licensing flipped: Gemma 4 and Command A+ 05-2026 are Apache-2.0; Llama 4 is the restrictive one and does not list Russian or Ukrainian. And the Ukrainian evidence is now decisive: on the only public Ukrainian suite that exists, gemma-4-26B-A4B-it beats the best Ukrainian-specialist finetune by roughly 19 points of MMLU-uk while activating only 3.8B parameters per token — so the 2024 playbook of "use a language-specific finetune" is obsolete for Russian and half-obsolete for Ukrainian (MamayLM is still the best UK specialist, but it is a generation behind and stuck under non-OSI Gemma terms). On economics, measure in Ukrainian tokens, not English ones: I measured the same advisory message at EN 61 / UK 92 / RU 69 tokens on Gemma 4 (UK 1.51×, RU 1.13×), EN 60 / UK 99 / RU 72 on Qwen3.8 (1.65×), EN 55 / UK 100 / RU 71 on gpt-oss (1.82×) — and on an older 100k-vocab tokenizer the Ukrainian penalty is 2.39–2.49×, so large-vocab tokenization is an explicit model-selection criterion. Chars-per-token also falls from 4.37 to 2.82, so your context window fills ~1.5× faster than English intuition suggests. Finally, compare on cache tiers, not list price, and do not self-host for money: measured break-even is 165,185 conversations/month (1× L40S community, no redundancy) to 455,826 (2× L40S secure, HA), against ~100,000/month at 50,000 customers. Self-host for Ukrainian PII residency, latency control, cross-session KV persistence and serving your own LoRA — not to save $780/month that costs more than that in one engineer-week of GPU incident response.

Things that sound right but aren't (runtime). "TGI is the alternative to vLLM" — archived 2026-03-21. "Llama is the safe default open model" — non-OSI, 16 months stale, and Russian and Ukrainian are absent from its official language list. "gpt-oss is the cheapest" — it has no usable prompt-cache tier, so a prefix-heavy workload pays full rate on every turn, and its Ukrainian tokenizer is the worst measured. "Cohere is CC-BY-NC" — true of c4ai-command-a-03-2025, false of command-a-plus-05-2026. "Qwen is Apache" — model-by-model, and the cheap hosted Flash variant is one of the non-Apache ones. "Set enable_prefix_caching=True" — it's been the default; the knob that actually matters is prefix_cache_retention_interval, which defaults to 0. And the checkpoint name gemma-4-26B-A4B-it-qat-w4a16-ct does not exist — Google's real QAT repos are -qat-q4_0-gguf and -qat-q4_0-unquantized.

---

13. Channel policy comparison — who can initiate, windows, templates, cost

This table decides more architecture than any model choice. All figures verified from primary vendor documentation on 2026-09-15 except where marked.

Reading the table. Three consequences fall straight out of it.

First, the cadence primitive is (one paid or earned window-opener) → (free multi-message burst inside the window) — never N independent paid broadcasts. The education payload is free on all three channels inside a session; only opening is metered. Batching a 3-message teaching burst into one opened window cuts an 8-touch education month by roughly 80–87%. Cap the drain at 3 messages per window-open event and 6 per 24h, or the burst reads as a wall of text. Apply an inversion test to every opener: would we still send this if in-window messages cost the same as templates? If no, it is a fee-dodge — legitimate openers are order status, a back-in-stock item they explicitly asked about, a genuine post-purchase check-in; illegitimate ones are manufactured urgency, content-free "are you there?", and questions whose answer you already know.

Second, the withholding policy is economically aligned with good selling on WhatsApp and economically neutral on Telegram — which inverts the usual intuition that patience costs money. A gate that waits for the customer to re-initiate keeps traffic inside the free window; a gate that fires on a timer spends a marketing template that may not even be delivered (131049). Conversely Telegram's zero cost means there is no price signal to restrain you, so enforce the attention budget more strictly there, not less. And Viber is fixed-cost-bound, not per-message-bound: with ~€200/month already sunk buying ~15,000 messages, under-sending Viber below roughly 1,500 active contacts is pure waste — ration only above ~2,000.

Third, the telemetry asymmetry will silently bias your relationship model if you pool channels. Read-latency and read-rate features simply do not exist on Telegram, so a single cross-channel R model makes every Telegram customer look systematically colder and they will never receive an offer. Normalise every engagement feature within channel by percentile rank, mark unavailable features missing rather than imputing neutral, and never reach for TDLib to recover Telegram read state — that requires a user account and is a ToS and ban risk on your primary channel.

Two operational rules that are easy to get wrong and expensive to fix: a stop signal on any channel must suppress all channels (WhatsApp's policy binds requests made "whether inside or outside WhatsApp", so you need one suppression ledger keyed on person, not per channel), and channel window state belongs in the veto layer, never as a score contributor — persist wa_window_expires_at, viber_subscribed, telegram_chat_member_status as typed columns the gate reads live, so "is this customer ready" and "am I currently allowed to message them, and will it cost me a paid template" remain two separate gates that must both pass.