Dnešní ranní briefing vybírá čtyři technicky použitelné novinky z oblasti AI chatbotů a voice/voicebotů – se zaměřením na to, co reálně mění architekturu, provoz a měření v telco prostředí.
1) Referenční „realtime“ voice bot v .NET: RT.Assistant (multi-agent + WebRTC + Realtime API)
Microsoft .NET tým publikoval detailní guest post o RT.Assistant, ukázkové aplikaci, která spojuje OpenAI Realtime API přes WebRTC s multi‑agent orchestrací v .NET/F# a nativním UI v .NET MAUI. Zajímavé je, že autoři explicitně řeší produkční problém non-determinismu: LLM je „nevyzpytatelný“, takže kolem něj staví deterministický stavový automat (Flow), který omezuje, kdy a jak agenti mohou dělat kroky a side‑effecty. Pro telco je praktická i volba domény (výběr tarifů): ukazuje, jak držet fakta konzistentně (Prolog knowledge base místo vektorového vyhledávání) a tím snížit halucinace u cen/benefitů. Důležitá provozní část je argumentace pro WebRTC proti WebSocketům: oddělené audio/data kanály, OPUS, lepší resiliency na krátké výpadky – což přesně odpovídá realitě mobilních sítí a Wi‑Fi roamingu. Praktický takeaway: pokud stavíte voicebota pro telco, oddělte „konverzační inteligenci“ (LLM) od „řízení procesu“ (deterministická orchestrace) a tlačte na transport, který vám dává stabilní low‑latency audio (WebRTC) a jasné hranice pro tool-calling.
2) Jak vybírat produkční framework pro Voice AI agenty: Bedrock/Vertex vs LiveKit vs Pipecat
Technický rozbor od WebRTC.ventures porovnává čtyři dnes často nasazované přístupy k produkčním voice agentům: Amazon Bedrock Agents/AgentCore, Google Vertex/ADK, LiveKit Agents a Pipecat Flows. Silná myšlenka pro telco je rozdělení na „media plane“ (SIP/WebRTC, barge‑in, session state, latence), „agent plane“ (workflow, tooly, eskalace) a „governance plane“ (IAM, audit, retenční okna, datové hranice) – přesně to, co v regulovaných a mission‑critical hlasových službách řešíte denně. Článek zároveň připomíná, že governance‑heavy platformy (Bedrock/Vertex) typicky pořád potřebují samostatnou RTC/telephony vrstvu pro telephony‑grade kontrolu, zatímco LiveKit/Pipecat staví „voice‑native“ pipeline jako první třídu (latence, barge‑in, media observability). I když jde částečně o poradenský obsah, hodnotu má v konkrétních trade‑offech: open‑source vs managed, kde leží složitost (IAM vs media), a jaké třídy incidentů tím vznikají. Praktický takeaway: před výběrem stacku si napište rozpočet latence (p95/p99), požadavky na barge‑in a eskalaci do živého agenta a požadavky na audit/retenci; teprve potom rozhodujte, jestli vám dává smysl media‑first runtime (LiveKit/Pipecat) nebo enterprise orchestrace s doplněnou RTC vrstvou (Bedrock/Vertex).
3) AWS Bedrock AgentCore Runtime: WebRTC bidirectional streaming + TURN jako povinná součást
AWS do dokumentace AgentCore Runtime doplnilo jasný návod pro WebRTC bidirectional streaming mezi klientem (browser/mobile) a agentem, což je pro voice agenty důležité kvůli nízké latenci a nativní podpoře v klientech. Klíčová „produkční“ věc: WebRTC na AgentCore vyžaduje VPC network mode a současně TURN relay pro media traffic (tj. bez správně navržené sítě a relaye se prostě nerozjede stabilní streaming). Dokument uvádí několik cest: managed TURN přes Amazon Kinesis Video Streams (GetIceServerConfig) s IAM autentizací, třetí stranu, nebo self‑host (např. coturn). Pro telco provoz je to cenné, protože TURN/UDP reachability a síťové politiky bývají nejčastější zdroj „funguje to v labu, nefunguje to u zákazníků“ problémů – zejména na firemních sítích, captive portálech a v roamingu. Praktický takeaway: pokud stavíte voicebota s WebRTC, zahrňte do designu síťové testy (UDP egress, NAT traversal, fallback strategie), měření míry relaying vs direct a kapacitní plán TURNu; je to infrastruktura stejně kritická jako samotný model.
4) Observability pro ML/LLM systémy: instrumentujte „kritickou cestu“ a držte nízkou kardinalitu atributů
ML Digest publikoval praktický úvod do OpenTelemetry pro ML systémy a dobře pojmenovává, proč je observability u LLM/agentů těžší než u klasických microservices: latence a kvalita se láme napříč gatewayí, cache, feature store, vektor DB i externím LLM providerem. Pro chatboty/voiceboty v telco to sedí: bez end‑to‑end trace kontextu nedokážete férově rozlišit, jestli vám p99 zabíjí ASR, retrieval, tool call do CRM, nebo TTS. Článek zdůrazňuje užitečné pořadí při incidentu (metrics → traces → logs) a hlavně roli context propagation (traceparent), která se ráda rozbije na hranách jako async queue, background worker nebo vlastní RPC wrapper. Praktická a často přehlížená rada je držet atributy analyzovatelné a low‑cardinality (např. model, verze, route, typ akce), a důležité „momentky“ dávat jako span events místo generování tisíců miniaturních spanů. Praktický takeaway: u telco botů standardizujte minimální sadu OTel atributů (tenant, kanál voice/chat, typ intentu, model/verze, outcome, eskalace) a hlídejte, že se trace kontext propaguje přes všechny hop-y včetně SIP/WebRTC gateway, toolů a background jobů – jinak budete optimalizovat naslepo.
5) Trend z průzkumu: OpenTelemetry jako „společný jazyk“ pro telemetry napříč stackem (a připravenost na AI agenty)
Grafana Labs shrnula výsledky Observability Survey 2026: otevřené standardy (zejména OpenTelemetry a Prometheus) jsou mainstream a důraz se přesouvá z vendor‑locku na přenositelnost a korelaci signálů. Pro provoz chatbotů/voicebotů je to důležité, protože bez korelace napříč signály (metriky, traces, logs) neuděláte spolehlivé SLO pro latenci, úspěšnost tool-calling a eskalace – zvlášť když se část pipeline odehrává u externích providerů. Článek zmiňuje, že OTel adoption roste hlavně v POC a postupně se posouvá do produkce; to je dobré číst jako výzvu: teď je nejlepší čas udělat „instrument once, route anywhere“ a nečekat, až bude pipeline neudržitelně složitá. Zajímavý detail je i propojení open-source ekosystému a agentů (např. MCP server pro Grafanu): směrem k agentům, kteří umí číst observability data a navrhovat zásahy, se bez standardizovaných datových modelů nedostanete. Praktický takeaway: pokud telco tým plánuje agenty, začněte u standardu telemetry (OTel) a konzistentního service naming/versioning; AI na observability dává smysl až když jsou data konzistentní a srozumitelná.
Závěr – 3 takeaways pro telco voice/chat provoz:
- Low-latency hlas není jen „model“: WebRTC + TURN + síťové politiky jsou kritická infrastruktura, která rozhoduje o UX a incidentní zátěži.
- Omezujte non-determinismus: kombinujte LLM s deterministickou orchestrací (stavové automaty/flows) a jasně definovanou plochou toolů.
- Bez OTel a jednotných atributů neoptimalizujete: standardizujte tracing end‑to‑end (včetně gateway a toolů) a měřte kritickou cestu p95/p99.