Agentic flow v podjetju: kako zasnovati zanesljiv poslovni proces

Najprej določite poslovni izid

Agentic flow je poslovni tok, v katerem AI agent znotraj določenih meja izbira naslednje korake in uporablja orodja. Zanesljivost izhaja iz zasnove celotnega procesa: kaj ga sproži, kaj agent sme odločiti, kako preverimo dejanje in kdaj je naloga končana.

Dober začetek ni navodilo »avtomatiziraj prodajo«, ampak natančna naloga: iz prejetega povpraševanja pripravi preverjen osnutek ponudbe za odgovorno osebo. Tako lahko ločite uporabno avtonomijo od odprtega raziskovanja brez konca. Potrebujete izhod, ki ga lahko nekdo sprejme ali zavrne, ter imenovanega lastnika procesa.

V seriji uporabljamo hipotetičen primer distributerja, ki prejema B2B povpraševanja. Agent razume zahtevo, preveri podatke o izdelkih in pripravi osnutek. Primer je učni model, ne opis rezultatov stranke NUMEDIA. Isti primer nam omogoča povezati arhitekturo, procesni brief, integracije, odobritve in produkcijsko uvedbo.

Za uspeh opredelite tudi negativni pogoj. Proces ni končan, če je agent zgolj napisal prepričljivo besedilo. Osnutek mora vsebovati prave izdelke, aktualno podatkovno podlago in označene manjkajoče informacije. Če tega ni mogoče doseči, je veljaven izhod predaja človeku z razlago, kaj manjka.

Razlikujte med vnaprej določenim tokom in odločitvijo agenta

Anthropic v svoji arhitekturni razlagi loči workflow z vnaprej določenimi potmi od agenta, ki naslednje korake izbira dinamično. Za poslovno uvedbo je koristna kombinacija: stabilen procesni okvir in omejena področja, kjer model razume neurejen vhod ali izbere ustrezno orodje.

V našem primeru naj programska pravila določijo dovoljene kategorije izdelkov, obvezna polja in prag za predajo. Model lahko razvrsti opis potrebe in predlaga ujemanje med izrazom kupca ter katalogom. Izračun skupne vrednosti ponudbe pa ostane preverljiv izračun nad potrjenimi podatki.

Več avtonomije dodajte, ko lahko pokažete, katero težavo rešuje. Če so vsi koraki znani in so podatki strukturirani, je preprost workflow pogosto primerna izhodiščna zasnova. Če se potrebne poizvedbe razlikujejo med primeri, agentu določite omejen nabor izbir in merilo, po katerem se mora ustaviti.

Razdelite flow na šest odgovornosti

Prva odgovornost je sprožitev: kateri dogodek ustvari primer in kako prepoznate podvojitev. Druga je kontekst: kateri podatki pripadajo temu primeru. Tretja je odločitev: kaj mora agent ugotoviti. Četrta je dejanje prek orodja. Peta je preverjanje dejanskega rezultata. Šesta je zaključek ali predaja.

Ta razdelitev pomaga pri diagnozi. Napačen predlog izdelka je lahko posledica slabo opisanega kataloga, napačnega iskanja ali slabe interpretacije. Težava ni nujno v modelu. Vsaki odgovornosti zato določite vhod, izhod in osebo, ki zna pojasniti, ali je rezultat pravilen.

Pri načrtovanju uporabljajte poslovne izraze. »Pridobi veljavno zalogo za izbrane šifre« je bolj uporaben korak kot »agent razmišlja«. Načrt mora povedati, katero preverljivo stanje bo obstajalo po koraku. Internih miselnih zapisov modela ne potrebujete kot dokaz uspešne izvedbe.

Stanje procesa shranite ločeno od pogovora

Primer potrebuje identifikator, trenutno fazo, uporabljene vire, različico osnutka in rezultate že izvedenih dejanj. Pogovorno okno samo po sebi ni poslovna evidenca. Če se seja prekine, mora izvajalec vedeti, kaj je potrjeno, kaj čaka in katerega koraka ne sme ponoviti.

LangGraph dokumentacija razlikuje shranjevanje stanja posamezne niti od podatkov, ki jih aplikacija hrani med različnimi nitmi. To je uporaben arhitekturni zgled, ne zahteva po določenem ogrodju. V lastni rešitvi lahko isto ločitev uredite z evidenco primerov in ločeno zbirko poslovnega znanja.

Za distributerja bi bile faze lahko novo povpraševanje, dopolnitev podatkov, preverjanje ponudbe, osnutek, čakanje na odobritev in zaključeno. Vsak prehod naj ima razviden razlog. Sprememba zahteve kupca ustvari novo različico osnutka, zato star predlog ne sme tiho postati veljaven za novo situacijo.

Pogodba orodja določa mejo dejanja

Orodje opišite z jasnim namenom, obveznimi parametri in možnimi rezultati. Agent naj ne prejme le sporočila »uspeh«, temveč na primer identifikator ustvarjenega osnutka ter njegovo stanje. Tako lahko naslednji korak preveri obstoj rezultata v ciljnem sistemu.

Ločite pripravo od izvršitve. Iskanje izdelkov, branje razpoložljivosti in izdelava predloga imajo drugačne posledice kot pošiljanje ponudbe. V diagramu in izvedbi naj bodo to različne operacije. S tem lahko za vsak del določite drugačne pogoje, preverjanja in dovoljeno stopnjo samostojnosti.

Predvidite tudi nejasen rezultat. Če povezava prekine po zahtevi za zapis, ne veste nujno, ali je zapis uspel. Proces naj preveri ciljno evidenco, preden poskusi znova. Podrobnejši načrt za takšne situacije obravnava članek o integraciji agentov s CRM in ERP.

Omejite ponavljanje in določite izhode iz zanke

Agent lahko večkrat poskusi poiskati manjkajočo informacijo, vendar naj bo meja izrecna. Določite dovoljene poskuse, časovni okvir in pogoj za predajo. Mej ne izbirajte samo po ceni klica modela. Pomembna sta tudi čakalni čas sodelavca in vrednost še odprtega poslovnega primera.

Ločite začasno tehnično napako od nerešljive poslovne nejasnosti. Ponovitev poizvedbe lahko pomaga pri začasni nedosegljivosti kataloga. Ne bo pa rešila situacije, v kateri kupec ni navedel zahtevanega modela. Za drugi primer potrebujete dopolnitev podatkov, ne več istega računanja.

Veljavni zaključki vključujejo uspešen osnutek, zahtevo za dopolnitev, zavrnitev neustreznega primera in tehnično predajo. Če v sistemu obstaja samo stanje »končano«, izgubite pomemben podatek o tem, zakaj je primer zapustil avtomatizirano pot.

Spremljajte prehode in izide, ne le števila klicev

OpenTelemetry opisuje sledi kot način povezovanja operacij v celoten potek zahteve. V agentic flowu ta ideja pomaga povezati poslovni primer, klic orodja in končni izid. Število žetonov samo ne pove, ali je ponudba pravilna ali ali je primer obtičal v čakalni vrsti.

Praktičen pregled naj pokaže, v kateri fazi se primeri ustavljajo, koliko jih potrebuje popravek in koliko človeškega dela ostane. Čas modela ločite od časa čakanja na sistem ali odobritev. Sicer lahko optimizirate majhen del poti, medtem ko glavni zastoj ostane nedotaknjen.

Za prvi pregled zadostuje majhen nabor reprezentativnih primerov z znanim pričakovanim izhodom. Dodajte nepopoln vhod, nedosegljivo orodje, podvojen dogodek in spremenjeno zahtevo. Cilj je preveriti vedenje celotnega toka, ne le pokazati en privlačen posnetek uspešnega odgovora.

Primer prehoda skozi flow: nepopolno povpraševanje

Predpostavimo, da kupec navede vrsto izdelka in želeno uporabo, ne pa zahtevane različice. Sprožilec ustvari primer, vhodni pregled pa označi manjkajočo lastnost. Agent najprej preveri, ali jo je mogoče razbrati iz drugih delov povpraševanja. Če je ni, pripravi usmerjeno vprašanje in primer prestavi v čakanje na dopolnitev.

Ko dopolnitev prispe, jo povežite z obstoječim primerom. Ne ustvarite novega vzporednega postopka samo zato, ker je nastalo novo sporočilo ali dogodek. Sistem preveri, kaj se je spremenilo, dopolni stanje in nadaljuje pri identifikaciji izdelka. Dopolnitev ne pomeni, da so vsi nadaljnji podatki avtomatično potrjeni.

Po potrjenem ujemanju orodje vrne šifro izdelka, uporabljeni vir in podatek o razpoložljivosti. Izračun uporabi dogovorjeno cenovno podlago. Agent sestavi osnutek z označenimi izjemami, preverjanje pa potrdi obvezna polja. Nato osnutek preide v vrsto za pregled, kjer je viden tudi razlog, zakaj potrebuje človeka.

Ta primer pokaže, zakaj je zasnova stanj uporabnejša od enega velikega navodila. V vsakem trenutku lahko odgovorite, kaj manjka, kdo je na potezi in kaj se bo zgodilo po novem vhodu. Pri spremembi zahteve po že pripravljenem osnutku tok ne preskoči preverjanja samo zato, ker je prejšnja različica že obstajala.

Kaj naj podjetje dobi pred začetkom razvoja

Prva uporabna dobava je zemljevid procesa: sprožilec, faze, podatkovni viri, odločitve, orodja, preverjanja in izhodi. Ob njem naj bo seznam odprtih vprašanj. Nejasna pravila so del obsega projekta in jih je treba razrešiti, preden postanejo nepredvidljivo vedenje v produkciji.

Pri NUMEDIA takšno zasnovo povezujemo z odgovornimi ljudmi in izvedbenim načrtom. Izbrana platforma pride v ospredje takrat, ko so zahteve dovolj jasne za primerjavo. Proces mora ostati razložljiv tudi vodji oddelka, ki ne pozna razvojnega ogrodja.

Naslednji korak je procesni brief. Ta arhitekturno skico spremeni v izvedbeno naročilo z mejo naloge in merili sprejema. Šele ko ekipa enako razume uspešen rezultat, je smiselno podrobno načrtovati integracije in pilot.

Viri in metodologija

1. Building effective agents (Anthropic, dostop 2026-10-19)
2. Workflows and agents (LangChain, dostop 2026-10-19)
3. Persistence (LangChain, dostop 2026-10-19)
4. Traces (OpenTelemetry, dostop 2026-10-19)

Pogosta vprašanja