Oracle Agent Engine: kdy nechat AI workflow běžet přímo v databázi

Když agent nad fakturou několikrát čte databázi, přenáší mezivýsledky a čeká na model, stojí za to položit jinou otázku než „který model použít“: kde má běžet samotný proces? Pro firmy s důležitými daty v Oracle je novou možností nechat jej blíž databázi.

Oracle 26. října 2026 oznámil obecnou dostupnost AI Database Agent Engine v Oracle AI Database 26ai. Jde o runtime pro deklarativní agentní workflow uvnitř databáze. SQL a PL/SQL mohou obsloužit pevná pravidla, model se zapojuje do interpretačních kroků. Je to samostatné architektonické téma, nikoli nový chatbot.

Co skutečně ověřit před pilotem

Dokumentace uvádí podporovanou podmnožinu Agent Spec 26.1.0. Volání externího modelu stále opouští databázovou síťovou hranici. Navíc sekci obnovy běhu a konverzací označuje jako připravovanou pro 23.26.4.2, přestože blog obnovu po výpadku popisuje obecně. Bez ověření konkrétního buildu bych ji nesliboval.

Úvodní návod pracuje s balíčky DBMS_AI_AGENT a DBMS_VECTOR_CHAIN, databázovým schématem, credentialem a síťovým oprávněním k poskytovateli modelu. Ukázka přitom obsahuje Agent Spec 25.4.1. Rozdíl proti přehledové dokumentaci je další důvod validovat definici v cílovém prostředí, ne slepě kopírovat příklad.

Pro mě z toho plyne jednoduché pravidlo: architekturu schválit až nad krátkým funkčním testem. Označení 26ai samo nestačí jako doklad dostupnosti všech popsaných funkcí. Stejně tak bych samostatně ověřil licenci, provozní náklady a zpracování dat u zvoleného modelu; tento článek jejich cenu nepotvrzuje.

Faktura jako podklad k rozhodnutí

Oracle v doprovodné ukázce spojuje fakturaci se servisními záznamy a lidským rozhodnutím. Firma Northstar je výslovně fiktivní. Jde o ilustrační workflow dodavatele, nikoli doloženou zákaznickou návratnost.

Vlastní pilot bych postavil nad reklamacemi dodavatelských faktur. To je můj návrh, ne provedený benchmark:

Na oddělené kopii dat vybrat 200 uzavřených případů, včetně chybějících příloh a opakovaných importů.
Připravit úzké procedury pro dohledání objednávky, příjemky a předchozí kontroly. Součty a duplicity určit kódem.
Modelu předat jen povolené podklady k vysvětlení nesrovnalosti. Výstup obsahuje odkazy na záznamy a chybějící důkazy.
Návrh uložit do kontrolní fronty. Účetní potvrzuje další akci; agent nemá oprávnění sám měnit bankovní účet nebo odeslat platbu.

n8n nebo Make bych v takovém návrhu nechal přijmout událost a doručit upozornění přes schválené aplikační rozhraní. Databázový proces by měl jasně vymezený úsek odpovědnosti. Nejde o zde ověřený hotový konektor.

Kam bych ho nasadil

Smysl vidím tam, kde už tým spravuje Oracle, většina podkladů leží v něm a existují důvěryhodné procedury. Pro workflow mezi pěti SaaS službami bych nejdřív zůstal u stávající orchestrace. Přesun procesu do databáze také znamená, že jeho zátěž a změny musí vlastnit konkrétní tým.

Při testu bych odpojil model, zopakoval stejnou událost a změnil podklad těsně před schválením. Ověřoval bych, zda vznikne právě jeden návrh, zda schválení stále odpovídá aktuálním datům a zda chyba nezmění čekající případ na povolenou akci. Databázová transakce sama nevrátí již odeslaný e-mail.

Měřil bych čas účetní na přijatý případ, přehlédnuté nesrovnalosti, cenu včetně opakování a dopad na běžné databázové dotazy. Přínosem není počet autonomních kroků. Přínosem je dohledatelný výsledek s menší ruční prací.

Ověřeno 27. října 2026. Cover je ilustrační fotografie vytvořená pomocí AI.