Dnešní ranní briefing (2026-02-02) vybírá novinky, které mají praktický dopad na návrh, provoz a měření výkonu chatbotů a voicebotů v telco prostředí (kontaktní centra, IVR, self-care).
Zoom Virtual Agent: lednové release notes (operace, reporting, jazyky)
Zoom aktualizoval release notes pro Zoom Virtual Agent (aktualizace článku 2026-01-22) a v sekci „January 17, 2026“ popisuje několik změn, které míří přímo na provozní řízení botů. Výrazná je možnost mít jedno předplatné (subscription) pro více reportů v „ZVA analytics 2.0“ a filtrovat je podle agentů/agent groups i typu reportu, což zjednodušuje pravidelné operativní reportování a snižuje administrativu. Dále přibývají alerty/notifications pro chat a voice agenty založené na historických baseline (denní/týdenní vzorce) místo „hodina po hodině“, což v praxi znamená méně falešných poplachů a lepší detekci reálných incidentů (např. náhlý propad containmentu po změně KB). Pro telco je důležitá i lepší end-to-end dohledatelnost: v analytice se objevují klikatelné vazby na Zoom Phone (ZP) call logs a Zoom Contact Center (ZCC) engagement logs a navíc se zachytávají ZP metriky typu pre-bot drop-off nebo transfer acceptance. Praktický takeaway: pokud máte více voice/chat botů, nastavte jednotný „operational telemetry“ (alerting + pravidelné report subscriptions) a přidejte click-through vazby do call logů – výrazně to zrychlí triage a postmortem.
Zdroj: Release notes for Zoom Virtual Agent
Google Cloud: plně spravovaný BigQuery MCP server pro AI agenty (secure data access)
Google Cloud popsal, jak použít nově dostupný „fully managed, remote BigQuery MCP server“ (preview k lednu 2026) k napojení LLM agentů na enterprise analytická data přes standard Model Context Protocol (MCP). Klíčová zpráva je, že MCP server běží na infrastruktuře služby a nabízí standardizovaný HTTP endpoint s definovanou sadou nástrojů – cílem je zkrátit čas integrace a omezit „custom glue code“ mezi agentem a daty. V článku je praktický postup (role/permissions, OAuth client, Gemini API key) a ukázka integrace do ADK i do Gemini CLI; zároveň je explicitně zdůrazněna potřeba držet se bezpečnostních a stability guideline pro produkční nasazení. Pro telco chatboty/voiceboty tohle znamená rychlejší a bezpečnější cestu k tomu, aby agent (např. pro péči o zákazníka) uměl dotazovat data jako billing, usage, tickets nebo síťové KPI bez toho, aby vývojáři ručně psali každou integraci a riskovali špatné scope/ACL. Praktický takeaway: zvažte MCP jako „standardní vrstvu nástrojů“ pro interní data a bot orchestration – ale od začátku nastavte minimální role, audit a omezení datasetů, protože u hlasových kanálů je dopad špatného oprávnění okamžitý.
Zdroj: Google Cloud Blog – BigQuery MCP server
Deepgram: financování + akvizice (latence, přerušitelnost, doménové modely)
Deepgram oznámil Series C ve výši 130M USD při valuaci 1.3B USD a zároveň akvizici startupu OfOne zaměřeného na voice v restauračních/drive-through scénářích. Vedle byznysového signálu je pro praxi důležitý důraz na real-time hlas: CEO zmiňuje požadavek generovat odpověď do ~500 ms, a text opakovaně akcentuje „interruptible“ chování (barge-in) a turn-taking, tedy atributy, které rozhodují o použitelnosti voicebotů v call-centru. Článek také vyjmenovává produktovou mapu (TTS Aura-2, STT Nova-3, real-time conversational ASR „Flux“ a Voice Agent API) a zmiňuje možnost nasazení v cloudu i on-prem s doménovým slovníkem/terminologií, což je v telco typicky nutnost (tarify, zkratky, produktové názvy). Pro telco provoz to signalizuje další konsolidaci trhu hlasové infrastruktury: dodavatelé, kteří zvládnou latenci + rušné akustické prostředí + domain adaptation, budou vítězit (a piloty, které nedořeší akustiku/latenci, budou končit). Praktický takeaway: při výběru voice stacku si dejte do RFP povinné metriky (end-to-end latency, barge-in stop latency, WER na reálných nahrávkách) a ověřte, že vendor umí domain adaptation a bezpečné nasazení (včetně on-prem/hybrid).
Zdroj: SiliconANGLE – Deepgram raises $130M
Praktický návod: latency budget, VAD a „barge-in“ pro real-time voice agenty
Praktický článek (Part 3 z „Voice AI Guide“) rozebírá, co je v hlasových agentech reálně „fast“ a proč je potřeba řídit latenci jako rozpočet (typicky cílit pod 800 ms end-to-end, ideál pod 500 ms). Užitečné je rozsekání latence na složky (STT/LLM/TTS + orchestrator overhead) a konkrétní doporučení, že pokud už samotné STT zabere stovky ms, zbytek pipeline nemá kde brát. Autor připomíná produkční metriky pro STT výběr (WER, RTF/real-time factor, TTFB pro partial transcript) a praktiky jako „flush“ při detekci silence, které umí snížit čekání na konci věty. V části o barge-in zdůrazňuje, že VAD není jen detekce ticha, ale klíčový prvek přerušování: potřebujete AEC (echo cancellation), rychlou VAD (řádově ~85–100 ms) a okamžité zrušení TTS, aby agent nepůsobil roboticky. Praktický takeaway: i když LLM umí skvělé odpovědi, voice UX vám zabije špatně navržená real-time pipeline – proto si nastavte explicitní latency budgety a testujte je na reálných audio scénářích (hluk, překrývání řeči, přerušování).
Zdroj: Medium – Real-Time Voice Agent (Part 3)
Zkráceně: co z toho plyne pro telco voice/chat boty
- Provozní telemetry: nastavte baseline-based alerting a jednotné report subscriptions (a proklik do call logů), jinak budete lovit incidenty naslepo.
- Data access pro agenty: standardizujte „tools“ vrstvu (MCP/ekvivalent) a hlídejte minimální oprávnění + audit, hlavně u hlasových kanálů.
- Latence a barge-in: berte latenci jako SLO; testujte E2E latency, WER na reálných nahrávkách a stop-latency při přerušení.