Konačni rezultat A2A suradnje prihvaća imenovana poslovna uloga, a ne protokol, agent ni tim koji je tehnički predao zadatak. Poslovni prihvat A2A rezultata traži razdvajanje tri radnje: predaja zadatka, provjera rezultata i odluka o poslovnom odobrenju. A2A uređuje komunikaciju između agenata. Ne dodjeljuje poslovnu ovlast, ne potvrđuje vjerodostojnost izvora i ne zatvara neriješene iznimke.
A2A protokol opisuje način komunikacije između agenata. U takvoj suradnji jedan agent može drugome poslati zadatak, primiti status ili preuzeti rezultat. To je koristan sloj interoperabilnosti kada više sustava sudjeluje u jednom tijeku rada.
MCP ima drukčiju ulogu: povezuje agenta s alatima i podacima. U praksi je korisno razlikovati pitanje "kako agent dolazi do podataka ili alata" od pitanja "kako agent surađuje s drugim agentom". Ni A2A ni MCP sami po sebi ne odgovaraju na treće, poslovno pitanje: tko smije reći da je rezultat prihvatljiv za narudžbu, knjiženje, plan proizvodnje, poruku kupcu ili drugu službenu radnju.
Protokol može prenijeti status poput dovršeno, neuspješno ili zahtijeva dodatnu informaciju. Takav status opisuje izvršenje komunikacijskog zadatka. Ne predstavlja automatski poslovni prihvat.
Ta razlika postaje važna kada rezultat ulazi u ERP ili mijenja obvezu organizacije. U ORKA pristupu službene ERP transakcije ostaju vezane uz jasno određene poslovne uloge, pravila procesa i provjerljive zapise. Orkasta može podržati svakodnevnu suradnju oko rada, a Trueforce specijalizirane inženjerske potrebe, no vlasništvo nad poslovnom odlukom mora ostati izričito imenovano kod naručitelja procesa.
U dobro postavljenom procesu iste osobe ne moraju obavljati sve tri radnje. Bitno je evidentirati prijelaze i uvjete za svaki prijelaz.
Predaja zadatka počinje kod vlasnika poslovnog zahtjeva ili kod sustava kojem je takva predaja dopuštena. Zadatak treba sadržavati najmanje:
Tehnički pošiljatelj poruke nije nužno vlasnik zahtjeva. Primjerice, integracija može poslati A2A zadatak u ime ERP procesa. Poslovni vlasnik ipak treba odrediti svrhu zadatka, dopuštene podatke i posljedice pogrešnog rezultata.
Prihvat rezultata je provjera ispunjava li izlaz unaprijed definirane kriterije. Tu provjeru može obaviti sustav, poslovna uloga ili kombinacija automatizirane kontrole i ljudskog pregleda.
Prihvat rezultata nije isto što i potvrda kako je agent vratio odgovor. Rezultat može biti tehnički potpun, ali poslovno neprihvatljiv. Može sadržavati podatak iz nedopuštenog izvora, propustiti obavezno polje, imati nerazriješenu nesigurnost ili izaći iz zadane ovlasti.
Kriteriji prihvata trebaju biti provjerljivi. Umjesto opisa poput "rezultat mora biti kvalitetan", koristiti pravila poput:
Vlasnik kriterija prihvata treba biti imenovana poslovna uloga. Tehnički tim može izgraditi provjeru, ali ne bi trebao prešutno određivati prihvatljiv poslovni rizik.
Poslovno odobrenje jest odluka o sljedećoj službenoj radnji. Ono može značiti objavu plana, slanje naloga, pokretanje nabave, knjiženje dokumenta ili predaju rezultata kupcu. Za tu odluku potrebna je ovlast koja proizlazi iz poslovnog procesa, ne iz činjenice kako je agent dovršio zadatak.
Odgovornost između AI sustava ne smije zamagliti ovu točku. Agent koji sastavlja prijedlog, agent koji provjerava dokument i agent koji šalje rezultat mogu imati različite zadatke. Nijedan od njih ne preuzima poslovnu ovlast samo zato što je zadnji u lancu.
Prije povezivanja agenata preko A2A, tim može proći kroz četiri kratka pitanja.
Koji rezultat ulazi u poslovnu odluku? Odvojiti radne bilješke, preporuke i nacrte od rezultata koji pokreće službenu radnju. Samo za drugi tip rezultata treba definirati poslovni prihvat.
Tko posjeduje ulaz? Za svaki ključni ulaz navesti vlasnika podatka. To može biti računovodstvo za kontni plan, nabava za odobreni popis dobavljača, proizvodnja za radni nalog ili druga određena funkcija. Vlasnik nije nužno tehnički administrator izvora.
Tko donosi odluku? Imenovati ulogu s ovlasti za odobrenje, eskalaciju ili odbijanje. Ako je odluka potpuno automatizirana, proces ipak treba navesti poslovnog vlasnika automatiziranog pravila i osobu ili ulogu za iznimke.
Što se događa kada rezultat nije čist? Definirati zaustavljanje, usmjeravanje na pregled i evidentiranje razloga. Neriješena iznimka ne smije nestati u statusu dovršeno.
Ovaj okvir često otkriva kako problem nije u interoperabilnosti, nego u nejasnom vlasništvu nad podacima i odlukama. Screening poslovnog procesa može poslužiti za mapiranje tih prijelaza prije tehničke izvedbe.
Zamislimo hipotetski proces u kojem prvi agent iz ulaznog dokumenta izdvaja podatke, drugi uspoređuje izdvojene stavke s odobrenim podacima iz ERP-a, a treći priprema prijedlog za daljnju obradu.
Predaja zadatka treba odrediti koji je dokument dopušten ulaz, koji ERP zapisi služe kao referenca i koje polje mora pratiti identifikator izvora. Drugi agent može vratiti podudaranje, nepodudaranje ili nedostatak podatka. Treći agent može urediti prijedlog za poslovnog korisnika.
Poslovni prihvat ne pripada trećem agentu. Pripada ulozi koja ima ovlast odobriti daljnju obradu dokumenta, prema pravilima organizacije. Ako nedostaje referentni zapis, ako se iznos ne podudara ili ako izvor nije prepoznat, rezultat ide u unaprijed određen tok iznimke. Agent može označiti iznimku i proslijediti potrebne činjenice. Ne može sam zatvoriti poslovni spor bez pravila i ovlasti.
Ovaj primjer ne propisuje jedan univerzalan prag automatizacije. Prihvatljiva razina automatizacije ovisi o vrsti odluke, pouzdanosti izvora, posljedicama pogreške i postojećim kontrolama procesa.
A2A može urediti razmjenu zadataka, ali ne rješava nekoliko ključnih pitanja.
Potpuna automatizacija može smanjiti ručni rad u stabilnim i jasno ograničenim dijelovima procesa. S druge strane, može prenijeti skriveno pravilo ili pogrešan izvor kroz više sustava brže nego ručni proces. Zato kontrolu treba oblikovati prije širenja opsega automatizacije.
Prije puštanja procesa u rad, zabilježiti sljedeće:
Ako tim ne može jasno imenovati vlasnika ulaza, odluke i iznimke, nije spreman prenijeti poslovni prihvat na automatizirani tok. Kao sljedeći korak, mapirati jedan konkretan proces od izvora do službene ERP transakcije i označiti svaki prijelaz odgovornosti. Za strukturirani razgovor o tom opsegu, razgovarajte s ORKA timom .