Agent-Native seob ühe toimingu kasutajaliidese, API ja AI-agendiga

Builder.io tõi 14. oktoobril 2026 Agent-Native’i avalikku beetasse. Avatud lähtekoodiga TypeScripti raamistikus saavad sama toimingut kasutada rakenduse kasutajaliides, AI-agent, HTTP API, käsurida ning MCP ja A2A ühendused. Arendaja saab hoida sisendi valideerimise ja äriloogika ühes kohas, kuid juurutuse õigused ja töökindlus sõltuvad endiselt rakenduse seadistusest.

Sõltumatu Writeble’i käsitlus kirjeldab beetaväljalaset ühise toimingukihina inimese juhitava rakenduse ja agendi vahel. Agent saab tegevust kutsuda tööriistana, selle asemel et jäljendada inimese samme kasutajaliideses. Ühine tegevus võib vähendada korduvat koodi, ent eri kutsujatele tuleb endiselt anda tuvastatav identiteet ja sobivad õigused.

Toimingu definitsioon on ühine, kasutusviisid erinevad

Avaliku Agent-Native’i repositooriumi näites koondab defineAction toimingu kirjelduse, Zodiga määratud sisendskeemi, HTTP seadistuse ja käivitatava run-funktsiooni. Kirjeldus aitab agendil tööriista valida, skeem kontrollib argumente ning Reacti kasutajaliides kutsub sama toimingut useActionQuery kaudu. Näidistoimingu hello puhul muudab üks muudatus run-funktsioonis nii kasutajaliidese kui ka agendi vastust; eraldi API marsruuti selleks kirjutama ei pea.

Sama toimingu saab avada ka HTTP päringule, MCP kliendile, teisele agendile A2A kaudu ja käsureale. Need on erinevad ligipääsuteed: veebivaade vajab nähtavat tagasisidet, agent selget tööriistakirjeldust ja väline klient protokollile vastavat ühendust. Ühise definitsiooni väärtus tekib siis, kui valideerimine ja ärireeglid jäävad toimingusse ega hargne kanali kaupa uuteks teostusteks.

Raamistik seob agendi töö ka rakenduse andmete ja olekuga. Kui agent muudab kirjet, saab inimene muudatust samas rakenduses näha; valitud vaade või kirje võib anda agendile konteksti. Kohalikuks arenduseks on ette nähtud PGlite ja tootmiskeskkonna püsivaks andmebaasiks PostgreSQL. See eristus loeb eriti rakendustes, kus tegevuse tulemus peab säilima pärast arendusprotsessi lõppu.

Näidistoiming näitab, kus dubleerimine lõpeb

Võtame tingliku taotluse oleku muutmise. Ühine toiming võtaks sisendiks taotluse tunnuse ja soovitud oleku, kontrolliks väärtusi, rakendaks lubatud üleminekute reegleid ning salvestaks tulemuse. Kasutajaliidese nupp ja agendi tööriistakutse saaksid kasutada sama teostust; vajaduse korral võiks tegevuse avada välisele süsteemile HTTP kaudu. Näide kirjeldab võimalikku arhitektuuri, mitte Agent-Native’i valmis taotluste haldamise funktsiooni.

Kui mõni olekuvahetus vajab inimese kinnitust, peab otsus kehtima sõltumata sellest, kas kutse tuleb veebivaatest või agendilt. Kinnituse küsimine on aga kanaliti erinev: kasutajaliides võib näidata dialoogi, agent peab tegevuse peatama ja väliskutse vajab viisi kinnituse oleku edastamiseks. Seega jagatakse tegevuse reeglit, mitte kogu suhtlusvoogu. Sama sisendskeem ei tähenda ka automaatselt, et kõigil kutsujatel oleks õigus sama kirjet muuta.

Siin ilmneb äriloogika dubleerimise hind. Kui olekuvahetuse lubatavus on eraldi API kontrolleris ja agendi tööriistas, võib ühe tee muudatus jätta teise vanade reeglite juurde. Ühise toimingu korral on reegli muutmiseks üks keskne koht, kuid meeskond peab siiski otsustama, millised toimingud agendile ja välistele klientidele avada. Iga uus ligipääsutee laiendab rakenduse kasutuspinda.

Ühine andmestik muudab vastutuse nähtavaks

Raamistiku autentimine, õigused, organisatsioonid, meeskonnad ja reaalajas sünkroonimine annavad ühisele andmestikule raami. Sama kirje nägemine ei anna siiski muutmisõigust: valitud kirje on kontekst, mitte volitus. Agendile antud õigus peab olema seostatav inimese või teenusega, kelle nimel ta tegutseb, ning piiratud konkreetse tegevusega.

Taotluse näites peaks auditijälg näitama, kes muutuse algatas, milline agent selle täitis, millist kirjet puudutati ja kas muudatus vajas kinnitust. Nii saab eristada inimese enda klõpsu, delegeeritud tegevust ja välise kliendi päringut ka siis, kui kõik läbisid sama toimingu. Selle eristuse vajadust selgitab ka agendi identiteedi sidumine toiminguga.

Ühine olek võib vähendada agendi- ja veebivaate lahknevust, kuid toob kaasa samaaegsete muudatuste küsimuse. Kui inimene muudab kirjet ajal, mil agent kasutab varem valitud konteksti, peab rakendus määrama, kas toiming lükatakse tagasi, küsitakse uut kinnitust või kasutatakse värsket seisu. Konkreetne konfliktireegel tuleb kujundada rakenduse andmemudeli järgi.

Beeta sobivus sõltub juurutuse piiridest

Agent-Native’iga saab arendada kohalikus koodibaasis või Builder.io veebikeskkonnas; oma juurutuse puhul jääb kood arendaja hoidlasse. Kasutada saab oma PostgreSQL-i andmebaasi ja mudeliteenuse võtit või kohalikku Ollama mudelit. Need valikud annavad kontrolli infrastruktuuri üle, ent tähendavad ka vastutust saladuste, varukoopiate, uuenduste ja teenuse töö jälgimise eest.

Tootmiskasutuse otsus sõltub sellest, kas iga kutsuja autenditakse enne toimingut ja kas õiguste kontroll seob kasutaja, agendi ning organisatsiooni konkreetse kirjega. Samuti on vaja määrata, kuidas säilib olek PostgreSQL-is, kuidas käsitletakse samaaegseid kirjutusi ning kas auditijälg eristab inimese, agendi ja välise kliendi tegevust. Isehostimisel lisandub vastutus mudelivõtmete, andmebaasi ja versiooniuuenduste eest. Need on rakenduse arhitektuurilised nõuded, mitte beetaversiooni olemasolust tulenevad garantiid.

Ühise toimingumudeli suurim proovikivi on kanaliülene õiguste piir. Kui sama olekumuutust saab käivitada kasutajaliidesest, agendist ja välisest protokollist, peab iga tee jõudma sama ärireeglini koos õige identiteedi ja jälgitava otsusega.

Loe ka:

• Eesti AI-agendi identiteet seob iga toimingu inimese ja limiidiga
• Dockeri ENV võib jätta võtme image’isse — kasuta build secret’it
• 38% küsitletud AI-kasutajatest varjab kolleegide eest oma parimaid prompte