V posledních týdnech AWS publikoval sérii návodů, jak pomocí Amazon Bedrock AgentCore stavět agenty pro business intelligence, automatizaci dashboardů a víceuživatelské produkty. Společný motiv není konkrétní use case, ale stejná otázka v zákulisí každého z nich: jak provozovat AI agenta, který v jedné instanci slouží více zákazníkům, a přitom drží jejich data, identity a paměť odděleně. Pro firmy, které píší B2B SaaS z Česka, je to praktičtější téma než kterýkoli model release v tomto měsíci.
Co AgentCore podle dokumentace přidává
AgentCore se v základu netváří jako další framework pro psaní promptů. Je to spíš sada provozních primitiv: runtime pro spouštění agenta v izolovaném prostředí, paměť napojená na identitu uživatele, brána pro volání nástrojů a observabilita pro každé volání modelu i nástroje. AWS k tomu publikuje příklady, kde agent odpovídá na dotazy nad firemními daty, navrhuje vizualizace a aktualizuje dashboard.
Pro vývojáře v Česku, kteří dosud lepili agenty z LangChainu, vlastních vektorových úložišť a vlastní autentizace, není zajímavé tvrzení, že AWS má agenty. Zajímavé je, že tyto provozní vrstvy přestávají být úkol pro každého zvlášť. Stejně jako se před deseti lety přesouvalo téma "máme vlastní deploy" do téma "máme managed cluster", AgentCore se snaží převzít stejnou roli pro agenta.
Multi-tenancy je provozní problém, ne marketing
Z trojice návodů má největší dopad ten o multi-tenant agentech. AWS v něm popisuje, jak na úrovni session, paměti a IAM rolí oddělit kontext různých koncových zákazníků v jednom agentovi. To je v B2B SaaS klíčový bod. Pokud agent volá databázi nebo API, musí být jisté, že nikdy nevidí data jiného tenanta. A pokud si pamatuje minulé interakce, musí jeho paměť patřit konkrétnímu uživateli, ne sdílenému prostoru.
Praxe ukazuje, že tato disciplína je v rané fázi agentických produktů často slabá. Mnoho startupů začíná se sdílenou demo pamětí pro všechny, jednou systémovou rolí pro všechny dotazy a jedním připojením do datového skladu. Funguje to do prvního enterprise zákazníka, který se zeptá, kdo přesně vidí jeho data a jak se to dá auditovat. AgentCore touto otázkou nezačíná zázračnou odpověď, ale dává návod, kde má izolace probíhat: na úrovni runtime kontextu, paměťové buňky a identity volajícího.
Co z toho plyne pro českou stranu trhu
Pro firmu, která z Česka prodává SaaS více zákazníkům, je z dokumentace cenné spíš architekturní zadání než produktový brand. I když se nakonec rozhodne nezakládat své jádro na AgentCore, výčet věcí, které musí mít vyřešené, funguje jako kontrolní seznam. Patří sem: jasný binding mezi koncovým uživatelem a session agenta, mapování zákazníka na identitu, kterou agent ponese při volání nástrojů, oddělené paměťové bloky pro každého klienta, kontrolované rozhraní pro nástroje místo libovolného HTTP a auditní stopa pro každé volání.
Stejně tak je dobré poznat hranice tohoto přístupu. AgentCore neudělá z modelu spolehlivého analytika ani z nedotaženého produktu funkční nabídku. Pokud agent dnes generuje obecné odpovědi bez napojení na pravdivý interní zdroj, lepší infrastruktura tento problém nevyřeší. Hodnota se ukáže až ve chvíli, kdy je agent navázán na konkrétní data, schválené dotazy a měřitelný výsledek pro koncového uživatele.
Pro českou konzultační scénu se otevírá jeden konkrétní typ zakázky. Zavést agenty do existujícího SaaS produktu pro střední firmu, která má AWS účet, ale nemá kapacitu řešit identity propagation a izolaci paměti vlastními silami. Tuto roli trh dříve viděl u Kubernetesu nebo u datových platforem. U agentů teprve začíná.
Co to znamená
AgentCore je signál, že téma agentů se z fáze prezentací posouvá k otázce, jak je provozovat ve sdílené infrastruktuře. Pro firmu, která plánuje agentickou funkci ve svém SaaS, je první otázka před modelem a před promptem provozní. Jak budete vědět, čí dotaz právě běží, jaké nástroje smí použít a kde končí jeho paměť. Pokud na ně dnes neumíte odpovědět ani na papíře, žádný nový model to nevyřeší.
Pro AWS jde samozřejmě o snahu udržet AI workloady ve své cloudové platformě v době, kdy modeloví dodavatelé staví vlastní agentická API. Pro českého CTO je rozumné se nenechat strhnout brandem a porovnat, zda by stejnou architekturu nepostavil nad Azure AI Foundry, Google Vertex AI nebo otevřenými nástroji. Volba bývá diktovaná tím, kde už zákaznická data leží a jaké závazky k regulaci je nutné dodržet. Důležitější než provider je, aby výsledný produkt zvládl odpovědět na jednoduchou otázku auditora: u kterého zákazníka, kdo a kdy spustil tuto akci.
Proč je to důležité
Adopce AI v českém prostředí už není otázkou prestiže, ale konkurenceschopnosti. Firmy, které začnou letos, získají zásadní časovou výhodu.
Pondělní redakční briefing
Pravidelný přehled o AI v českém byznysu přímo do vaší schránky. Bez spamu, jen data.