Agentų era: technologijų gigantų kova dėl debesijos kontrolės

2025-aisiais debesijos technologijos jau ne tik vykdo komandas, bet ir pradeda interpretuoti žmogaus ketinimus.

Ten, kur serveriai kadaise eilutė po eilutės vykdydavo nurodymus, dabar veikia DKM įgalinti agentai – jie supranta užduotis natūralia kalba ir koordinuoja įvairių įrankių bei paslaugų sąveiką, siekdami konkretaus rezultato. Kiekviena didžioji technologijų bendrovė iš esmės pertvarko savo infrastruktūrą pagal naują paradigmą – autonomines sistemas, gebančias samprotauti, ieškoti informacijos ir veikti beveik be žmogaus įsikišimo.

Agentinė ekosistema – tai daugiasluoksnis programinės įrangos ir infrastruktūros karkasas, leidžiantis DI agentams savarankiškai mąstyti, planuoti ir veikti siekiant konkretaus tikslo. Didžiosios technologijų bendrovės kuria savas agentines ekosistemas – naujos kartos architektūrą, skirtą dirbtinio intelekto valdomoms programoms ir paslaugoms.

Agentinės ekosistemos

Pagrindinės technologijų bendrovės kuria ir komercializuoja šiuos dirbtinio intelekto (DI) pajėgumus, agentų eroje siekdamos atsiriekti savo pyrago dalį – tapti pamatiniu sluoksniu būsimos DI plėtros architektūroje.

Įmonė	Pasiūla	Trumpa apžvalga
„Microsoft“	„Azure AI Foundry“, „AutoGen“, „Copilot Studio“	Siūlo visą paslaugų rinkinį, skirtą agentų kūrimui, saugai ir diegimui, glaudžiai integruotą į „Microsoft 365“ ekosistemą. „Azure AI Foundry“ – išsami dirbtinio intelekto programų kūrimo platforma, o „Copilot Studio“ – patogus įrankis pokalbiniams agentams kurti. „AutoGen“ – karkasas, leidžiantis kurti daugiagentinius pokalbius ir automatizuotas darbo eigas, dažnai naudojamas kaip „Azure AI Foundry“ platformos dalis. Kartu šie įrankiai sudaro daugiasluoksnę sistemą: „Copilot Studio“ atsako už naudotojo sąsają, „Azure AI Foundry“ – už vidinę infrastruktūrą, o „AutoGen“ valdo sudėtingą daugiagentę logiką.
„Google“	„Vertex AI Agent Builder“	„Vertex AI Agent Builder“ – tai įrankių rinkinys „Google Cloud“ platformoje, skirtas pažangių dirbtinio intelekto agentų kūrimui, diegimui ir valdymui. Jis pritaikytas plačiam naudotojų spektrui – nuo verslo specialistų, dirbančių vizualioje „no-code“ aplinkoje, iki kūrėjų, kuriems reikalingi galingi atvirojo kodo karkasai.
„Amazon Web Services“ (AWS)	„Bedrock Agents“, „AgentCore“, „Amazon Q Developer“	„Amazon“ siūlo platų dirbtinio intelekto agentų paslaugų spektrą. „Bedrock Agents“ – aukšto lygmens paslauga, skirta agentų kūrimui ir diegimui, idealiai tinkama konfigūravimui be poreikio rašyti kodą. „AgentCore“ – modulinė infrastruktūros platforma, suteikianti kūrėjams galimybę itin tiksliai valdyti agentinių sistemų kūrimą, nepriklausomai nuo pasirinkto karkaso ar modelio. „Amazon Q Developer“ – specializuotas dirbtinio intelekto asistentas kūrėjams ir IT specialistams, padedantis spartinti užduočių atlikimą AWS ekosistemoje.
„OpenAI“	„AgentKit“, „Agents SDK“	„OpenAI“ siūlo visavertę agentinę ekosistemą, skirtą dirbtinio intelekto agentų kūrimui, diegimui ir tobulinimui. Ji apima tiek vizualinius, tiek programavimo įrankius. „AgentKit“ – „OpenAI“ vizualinė sąsaja ir platforma, skirta agentams kurti bei diegti, o „Agents SDK“ – programiškai valdomas karkasas, leidžiantis tiksliai kontroliuoti agentų elgseną. Šie du įrankiai sukurti veikti išvien, kad mišrios komandos – kūrėjai ir kitų sričių specialistai – galėtų bendradarbiauti kuriant agentus.
„Salesforce“	„Agentforce“	„Agentforce“ – „Salesforce“ platforma, skirta kurti, pritaikyti ir diegti autonominius dirbtinio intelekto agentus verslo procesų automatizavimui. Tiesiogiai integruota į „Salesforce“ ekosistemą, ji padeda įmonėms kurti skaitmeninę darbo jėgą, galinčią atlikti įvairias užduotis pardavimų, klientų aptarnavimo, rinkodaros ir kitose srityse.
IBM	„Watsonx“	„IBM“ agentinė ekosistema sukurta platformos „Watsonx“ pagrindu. Tai išsami, verslui orientuota priemonių visuma, skirta dirbtinio intelekto agentų kūrimui, koordinavimui ir valdymui. Ekosistema pritaikyta lanksčiam diegimui – ji leidžia įmonėms integruoti agentus į esamą technologinę infrastruktūrą, teikiant pirmenybę saugumui ir atsakingo darbo su dirbtiniu intelektu principams.

Kontrolės filosofijos

Už įtaigių demonstracijų ir reklaminių šūkių slypi kiekvienos technologijų milžinės strategija. Kiekviena jų siekia kontrolės savaip – ir stato už skirtingą ateities viziją.

„Microsoft“ kuria įmonėms skirtą agentų operacinę sistemą, glaudžiai susiejančią agentinius pajėgumus su „Azure“ ir „Microsoft 365“. Jos pasiūlymas – vientisa integracija su jau turima infrastruktūra. Tačiau ši patogumo kaina aiški: kiekvienas sukurtas agentas dar labiau įtraukia į priklausomybę nuo „Microsoft“ debesijos, tapatybės valdymo sistemų ir duomenų sluoksnio. Įmonėms, jau veikiančioms šioje ekosistemoje, tai reiškia sklandų diegimą. Visiems kitiems – Fausto sandorį.

„Google“ pasirinko kūrėjų palaikomą atvirumo strategiją, kurią įkūnija „Agent Development Kit“ (ADK) ir „Agent2Agent“ (A2A) protokolas. Ji grindžiama prielaida, kad ateitį lems fragmentacija: jei agentai turės veikti tarp skirtingų tiekėjų ir modelių, esminiu infrastruktūros elementu taps „Google“ suderinamumo sluoksnis. Tačiau tokios strategijos palaikymas brangiai kainuoja, o pati „Google“ ne kartą yra apleidusi kūrėjų platformas, kai šios nustojo augti. Galbūt dėl A2A techninių pajėgumų abejonių nekils, tačiau ar 2028-aisiais jis vis dar bus palaikomas?

„AWS“ agentus laiko pagrindiniais infrastruktūros elementais. „Amazon“ siūlo modulinius kūrimo blokus, veikiančius pagal principą „mokėk tiek, kiek naudoji“, kurie natūraliai įsilieja į esamus „DevOps“ darbo srautus. Tai vadinamasis „atsinešk savo architektūrą“ požiūris: maksimalus lankstumas – didžiausias sudėtingumas. Jis grindžiamas prielaida, kad įmonės turi pakankamai inžinerinės kompetencijos kurti ir palaikyti individualias agentų sistemas – saugus pasirinkimas pagrindinei „AWS“ klientūrai, tačiau rimta kliūtis mažesnėms organizacijoms.

„OpenAI“ daugiausia dėmesio skiria greitam prototipų kūrimui ir kūrėjų darbo spartai. „Agentic API“ ir „Agents SDK“ leidžia per kelias minutes paleisti veikiantį agentą – tokį prieinamumo lygį gali pasiūlyti nedaugelis konkurentų. Pastaruoju metu bendrovė pristatė išsamesnę agentinę ekosistemą su funkcijomis, pritaikytomis gamybiniam stabilumui užtikrinti. Vis dėlto dalis įmonių svarbiausioms užduotims vis dar renkasi brandesnes platformas.

„Salesforce“ siekia sukurti „no-code“ diegimo aplinką verslo naudotojams, paversdama „Agentforce“ agentų kūrimo įrankiu. Tikslinė auditorija – ne kūrėjai, o pardavimų vadovai ir rinkodaros komandos, norinčios automatizuoti procesus be programavimo. Rizika akivaizdi: tokie sprendimai dažnai paviršutiniški ir tinka tik paprastoms darbo eigoms. Susidūrę su sudėtingesniais reikalavimais, techninių žinių neturintys naudotojai nebesugeba jų išplėsti, o tiekėjai už individualius pritaikymus taiko gerokai didesnes kainas.

„IBM“ savo sprendimus pozicionuoja reguliuojamoms industrijoms, orientuodamasi į atitikties užtikrinimą per „Watsonx Orchestrate“. Pasiūlymas grindžiamas hibridiniu diegimu, duomenų suverenumu ir atsekamumo užtikrinimu – esminiais saugos aspektais finansų, sveikatos apsaugos ir viešojo sektoriaus srityse. Tačiau kontrolės ir atitikties prioritetai dažnai reiškia viena: inovacijos – paskiausiai. „IBM“ iššūkis – įrodyti, kad griežtai reguliuojami agentai gali išlaikyti konkurencingą našumą.

---

Tikroji priešprieša nėra tarp atvirumo ir kontrolės. Esmė – kokį kompromisą pasirinks įmonės. Ar jos rinksis integraciją vietoj lankstumo („Microsoft“)? Greitį vietoj brandumo („OpenAI“)? O gal paprastumą vietoj galios („AWS“)? Atsakymas nulems, kas artimiausiais metais valdys debesijos pajamas – ir kurios įmonės liks įkalintos architektūrose, iš kurių kelio atgal nebėra.

Pagrindiniai agentinių ekosistemų komponentai

Nors konkrečių įrankių pavadinimai skiriasi, pagrindiniai agentinės ekosistemos komponentai visose „Big Tech“ platformose išlieka tie patys:

• Mąstymo / kognityvinis sluoksnis – agento „smegenys“, veikiančios didžiųjų kalbos modelių (DKM) ir specializuotų planavimo algoritmų pagrindu. Šis komponentas atsakingas už instrukcijų interpretavimą, sudėtingų užduočių išskaidymą į mažesnes dalies užduotis ir daugiapakopio plano sudarymą siekiant tikslo.
• Atminties sluoksnis – saugo informaciją, suteikiančią agentui kontekstą dabartiniams ir būsimiems veiksmams. Jį sudaro:
  • Trumpalaikė atmintis – valdo esamo pokalbio ar užduoties kontekstą.
  • Ilgalaikė atmintis – naudojama nuolatiniams duomenims, pavyzdžiui, naudotojų nuostatoms ar organizaciniams duomenims, kaupti; dažnai veikia su vektorinėmis duomenų bazėmis, leidžiančiomis atlikti semantinę paiešką.
• Duomenų gavimo / konteksto sluoksnis – leidžia agentui pasiekti išorinę, tikralaikę ir konkrečiai sričiai būdingą informaciją, esančią už jo mokymosi duomenų ribų. Tai daroma per tokias sistemas kaip žiniatinklio paieška, žinių bazės ar dokumentų saugyklos.
• Veiksmų / įrankių sluoksnis – sąsaja, leidžianti agentui atlikti veiksmus realiame pasaulyje. Šis sluoksnis per API jungtis integruojasi su įvairiais įrankiais ir verslo sistemomis, kad galėtų vykdyti tokias užduotis kaip el. laiškų siuntimas, duomenų bazių atnaujinimas ar kodo paleidimas smėliadėžėje.
• Koordinavimo sluoksnis – valdo bendrą darbo srautą, derina įvairius komponentus ir leidžia keliems agentams bendradarbiauti. Šiame sluoksnyje veikia tokie karkasai kaip „LangGraph“ ir „CrewAI“.
• Grįžtamojo ryšio ir mokymosi sluoksnis – leidžia agentui tobulėti laikui bėgant: rinkti naudotojų atsiliepimus, vertinti savo veiklą ir atnaujinti žinias ar veikimo strategiją.
• Valdymo, saugos ir stebėsenos sluoksnis – itin svarbus įmonių diegimui. Šis sluoksnis užtikrina saugumo kontrolę, prieigos teises, veiksmų atsekamumą ir stebėsenos įrankius, leidžiančius agentams veikti saugiai ir patikimai.

Technologinis peizažas: kur slypi tikrieji skirtumai

Nepaisant rinkodaros blizgesio, visos agentinės ekosistemos turi panašią sandarą: mąstymo sluoksnį (DKM), atminties sluoksnį (vektorinės duomenų bazės ir paieškos sistemos), koordinavimo sluoksnį (darbo srautų sistemos) ir kontrolės sluoksnį (valdymas, stebėsena, kaštų kontrolė). Tačiau kiekvienas tiekėjas sustiprino vis kitą sluoksnį – ir šie pasirinkimai atskleidžia, kur, jų manymu, vyks tikrieji mūšiai.

Mąstymas ir modelių prieiga

„OpenAI“ ir „Microsoft“ valdo aukščiausio našumo modelius (GPT-5, o3) bei tiksliojo derinimo infrastruktūrą jų pritaikymui. „Azure AI Foundry“ ir „AutoGen“ karkasas suteikia dirbtinio intelekto sistemoms labiau struktūruotą mąstymo būdą. Užuot tiesiog spėjęs kitą žodį sekoje, agentas gali planuoti į priekį, taikyti simbolinę logiką ir koordinuoti kelių agentų veiklą. Tačiau ši galia turi kainą: jei jūsų agentai apmokyti pagal GPT-5 mąstymo stilių, perėjimas prie „Claude“ ar „Gemini“ modelių reikštų užklausų perrašymą, rezultatų pervertinimą ir susitaikymą su laikinu efektyvumo nuosmukiu.

Atmintis ir duomenų gavimas

„Google“ ir „AWS“ pirmauja duomenų infrastruktūros integracijos srityje. „Vertex AI Agent Builder“ natūraliai jungiasi su „BigQuery“, „AlloyDB“ ir „Google“ debesijos saugykla, todėl įmonių duomenys iš karto tampa prieinami agentams. „Bedrock Agents“ žinių bazės siūlo panašius pajėgumus S3 vektorinių duomenų bazių ekosistemoje. Tuo tarpu „IBM watsonx.data“ dėmesį sutelkia į nestruktūruotus, senesnės kartos duomenis – pavyzdžiui, PDF failus, el. laiškus ar sutartis – kuriuos dauguma konkurentų ignoruoja, nors tokia informacija dažnai sudaro net apie 80 % įmonių žinių bazės. Kompromisas akivaizdus: gili integracija reiškia, kad agentų architektūra tampa neatskiriama nuo duomenų infrastruktūros.

Koordinavimas ir daugiagentės sistemos

„Microsoft“ ir „Salesforce“ tiki, kad ateitis priklauso ne pavieniams agentams, o jų tinklams. Tiek „AutoGen“, tiek „Agentforce“ leidžia kūrėjams apibrėžti daugiagentes darbo eigas: vienas agentas atlieka tyrimą, kitas – sintezę, trečias – užtikrina kokybę. Tokia struktūra primena realių komandų darbą, tačiau kartu didina darbo srautų sudėtingumą ir kaštus. Klausimas išlieka: ar daugumai verslo problemų spręsti iš tiesų reikia koordinuotų agentų komandų? Ankstyvieji agentinių sistemų diegimai rodo, kad dauguma užduočių vis dar sėkmingai atliekamos pasitelkus vieno agento architektūrą.

Valdymas, atitiktis ir paaiškinamumas

Šioje srityje dominuoja „IBM“ ir „Microsoft“, orientuotos į reguliuojamas industrijas, kuriose agentų veiksmų ir duomenų kilmės atsekamumas yra būtinas. „Watsonx.governance“ fiksuoja kiekvieną agento sprendimą, saugodama mąstymo sekas vėlesniems auditams. „Microsoft“ integracija su „Entra ID“ (anksčiau – „Azure AD“) reiškia, kad agentų prieigos teisės perduodamos per esamas įmonių tapatybės sistemas. „AWS“ sparčiai vejasi su „Bedrock Guardrails“, tačiau kūrėjams orientuota „AWS“ kultūra lemia, kad dirbtinio intelekto valdymas čia išlieka labiau priedas nei pamatas. Šiuo atveju valdymas reiškia agentų veiklos priežiūrą ir atsekamumą – procesus, užtikrinančius, kad DI sistemos veiktų saugiai, skaidriai ir laikydamosi nustatytų taisyklių. Rizika akivaizdi: finansų, sveikatos apsaugos ir kitose itin reguliuojamose industrijose nepakankamas valdymas nėra funkcionalumo trūkumas – tai nepriimtina sąlyga.

Stebėsena ir kaštų kontrolė

Šioje srityje užtikrintai pirmauja „AWS“ su „CloudWatch“ telemetrija ir tikralaike kaštų stebėsena sistemoje „AgentCore“. Kiekvienas API iškvietimas, kiekvienas sunaudotas ženklas ir kiekvienas įrankio panaudojimas yra registruojamas bei skaidriai įkainojamas. Tai ypač svarbu, nes agentų kaštus numatyti sunku: agentas, kuris įprastai pasitelkia tris įrankius, gali iškviesti dešimt – ir gerokai padidinti sąskaitą. Kalbant apie detalų kaštų priskyrimą, „Google“ ir „Microsoft“ vis dar vejasi „AWS“. Šių spragų pasekmes jau pajuto pirmosios įmonės, pradėjusios diegti agentines sistemas. Tuo tarpu „OpenAI“ beveik nesiūlo jokių kaštų kontrolės priemonių, sąmoningai teikdama pirmenybę ne finansiniam nuspėjamumui, o kūrėjų patirčiai.

Tikrasis technologinis skirtumas

Konkurencija čia vyksta ne dėl pažangiausių modelių ar gausiausių funkcijų, o dėl architektūrinių prielaidų:

• „Microsoft“ daro prielaidą, kad įmonėms svarbiausia glaudi integracija – todėl jos pasirengusios susitaikyti su priklausomybe nuo „Microsoft“ ekosistemos.
• „AWS“ remiasi prielaida, kad įmonės turi IT inžinierių komandą ir siekia didžiausio lankstumo.
• „Google“ tiki, jog svarbiausias veiksnys bus sąveika tarp skirtingų sistemų, o ne vieno tiekėjo ekosistema.
• „OpenAI“ daro prielaidą, kad kūrėjai mainais į pažangiausius įrankius toleruos nenuspėjamumą.
• „IBM“ skaičiuoja, kad pagrindine dirbtinio intelekto diegimo kliūtimi įmonėse taps valdymo ir atitikties reikalavimai.

Kiekviena iš šių prielaidų – statymas už skirtingą ateitį. Ir tik kelios iš jų pasitvirtins.

Kova dėl standartų

Po paviršiuje matomos konkurencijos dėl modelių ir funkcijų vyksta tylesnė, bet kur kas reikšmingesnė kova – dėl protokolų, kurie nulems, kaip agentai bendraus tarpusavyje. Tai ne vien techninė infrastruktūra: tas, kas valdys šiuos standartus, turės galią formuoti būsimą interneto architektūrą.

Šiuo metu ryškėja du protokolai, tampantys jungiamąja agentinio interneto grandimi – jie atskleidžia strategiškai skirtingas vizijas.

Modelio konteksto protokolas (angl. MCP), kurį 2024 m. lapkritį pristatė „Anthropic“, jau 2025 m. vasarį turėjo daugiau nei tūkstantį kūrėjų bendruomenės sukurtų jungčių. Pagrindinės dirbtinio intelekto platformos – „OpenAI“, „Google“, „Microsoft“ ir „AWS“ – MCP pritaikė kaip standartinį metodą, kuriuo agentai pasiekia įrankius ir duomenis. Dirbtinio intelekto pasaulyje MCP galima įsivaizduoti kaip USB-C jungtį – universalią sąsają, leidžiančią agentams jungtis prie duomenų bazių, API, failų sistemų ir verslo programinės įrangos be individualių integracijų.

Tačiau būtent čia technologijų diegimas išryškina strateginius ketinimus. „Salesforce“ MCP adaptacija išlieka griežtai apribota ir saugoma nuosavybės teisių – 2025 m. liepą „Agentforce“ aplinkoje MCP buvo prieinamas tik bandomuoju režimu. Platesnė bendrovės platforma išlieka uždara išorės kūrėjams, nors atvirumas viešai deklaruojamas. Šis modelis vis plačiau matomas visoje industrijoje: standartai deklaruojami kaip atviri, tačiau realiai taikomi pasirinktinai – tam, kad kontrolė liktų tiekėjo rankose.

„Google“ Agent2Agent (A2A) protokolas atlieka kitokią funkciją – ir atskleidžia kitokią silpnąją grandį. Jis pristatytas 2025 m. balandį, bendradarbiaujant su daugiau nei penkiasdešimčia partnerių, tarp jų „Microsoft“, „Salesforce“, „IBM“ ir didžiosiomis konsultacijų bendrovėmis. A2A leidžia agentams bendrauti tarpusavyje. Tų pačių metų birželį protokolas perduotas „Linux Foundation“, siekiant užtikrinti ilgalaikį neutralumą ir nepriklausomybę nuo tiekėjų.

A2A ir MCP sukurti taip, kad vienas kitą papildytų: MCP valdo agentų ryšius su įrankiais, o A2A – agentų tarpusavio bendradarbiavimą. Kartu jie sudaro pamatą daugiagentėms sistemoms, apimančioms įvairias įmonių platformas.

Vis dėlto „Google“ atvirumo strategija šiuo atveju yra gynybinė, o ne idealistinė. Bendrovė aiškiai nurodo, kad A2A sukurtas remiantis vidine „Google“ patirtimi plečiant agentinių sistemų mastą – tai netiesioginis pripažinimas, jog įmonė siekia pramonės palaikymo, kad agentiniame pasaulyje išliktų reikšminga. Paversdama A2A atvirojo kodo sprendimu, „Google“ stato už plačią tarpusavio sąveiką, kuri, jos manymu, bus svarbesnė už bet kurio tiekėjo uždarą, integruotą ekosistemą. Tai visiška priešingybė „Microsoft“ strategijai.

Strateginiai interesai – milžiniški. 2000-aisiais įmonės varžėsi dėl naršyklių, 2010-aisiais – dėl debesijos API. Dabar mūšio laukas – koordinavimas: sluoksnis, kuris nulemia, kurie agentai gali bendrauti su kuriomis sistemomis, pagal kokias saugos politikas ir kokius valdymo reikalavimus.

Tiekėjas, kuris laimės protokolų karą, nustatys:

• Kokių žinių agentai galės įgyti – kokie duomenų šaltiniai suderinami su MCP.
• Ką agentai galės atlikti – kokie įrankiai prieinami per standartizuotus protokolus.
• Kaip agentai bendradarbiaus – ar daugiaplatformės agentų komandos apskritai įmanomos.

Europai, kur duomenų suverenumas ir tarpusavio sąveika yra politiniai prioritetai, tai turėtų kelti nerimą. Ankstyvosios MCP adaptacijos jau atskleidžia nerimą keliančias tendencijas: 2025 m. birželį „HubSpot“ tapo pirmąja CRM platforma, pristačiusia gamybinės versijos MCP integraciją – ir tai nebuvo Europos tiekėjas. Kaip įprasta, standartus nustato Amerikos įmonės, o Europos verslams belieka juos priimti.

Galutinis rezultatas nulems, ar agentai liks įmonių valdomais įrankiais, ar taps nauju priklausomybės sluoksniu, kuriame perėjimo kaštai bus matuojami iš naujo kuriamomis darbo eigomis ir integracijomis.

Tikrasis klausimas – ne kuris protokolas laimės, o ar apskritai gali išlikti iš tiesų atviras standartas, kai tiekėjai suinteresuoti pririšti vartotojus prie savo sistemų. Ar „atviri protokolai“ netaps dar vienu būdu centralizuoti kontrolę, prisidengiant sąveikumo idėja?

Pasekmės įmonėms ir kūrėjams

Agentinių ekosistemų įsisavinimas reiškia priverstinę migraciją į iš esmės kitokį programinės įrangos kūrimo ir veikimo modelį. Dauguma organizacijų tam dar nėra pasirengusios.

Architektūra – keičia viską

Įprastas modelis – naudotojas siunčia užklausą → programa ją apdoroja → API grąžina rezultatą – užleidžia vietą kur kas sudėtingesnei sistemai: agentų tinklui, kuris interpretuoja užklausas, derasi su kitais agentais, savarankiškai kviečia įrankius ir pateikia rezultatus, galinčius sutapti arba nesutapti su naudotojo lūkesčiais.

Tai ne tik techninis, bet ir organizacinis pokytis. Kai programinė įranga buvo deterministinė, klaidų paieška reiškė kodo sekų analizę. Kai agentas veikia netinkamai, reikia derinti jo samprotavimo eigą – peržvelgti mąstymo grandinės žurnalus, vertinti užklausų grandines ir bandyti atkurti neapibrėžtą elgseną. Tradiciniai programinės įrangos inžinieriai, kaip ir dauguma DevOps komandų, tam dar nėra pasirengę.

Įgūdžių atotrūkis – realus ir augantis

Keičiasi reikalingų kompetencijų spektras: nuo kodo rašymo pereinama prie kognityvinių darbo srautų architektūros – samprotavimo ciklų kūrimo, vertinimo kriterijų apibrėžimo, kontrolinių taškų įtraukimo ir nuokrypių stebėsenos. Vis dažniau ieškoma „užklausų inžinierių“ ir „DI darbo srautų kūrėjų“ – pareigybių, kurių prieš dvejus metus apskritai nebuvo ir kurioms vis dar nėra nusistovėjusių karjeros kelių ar mokymo programų.

Tai kuria specialistų trūkumą smulkioms ir vidutinėms įmonėms. Didžiosios technologijų bendrovės vilioja 2–3 kartus didesniais atlyginimais kūrėjus, gebančius suprasti DKM veikimą, RAG metodus ir agentų koordinavimą. Mažesnėms įmonėms belieka rinktis tarp brangių konsultantų, sukūrusių vos vieną bandomąjį projektą, ir jaunų, dar tik besimokančių kūrėjų.

Įrankiai dar nesubrendę – nepaisant rinkodaros pažadų

Taip, egzistuoja tokie Big Tech karkasai kaip „AutoGen“, „Agents SDK“, „Vertex AI Agent Builder“ ir „Agentforce“. Tačiau tai dar nereiškia, kad šios sistemos parengtos gamybai. Įmonės, pradėjusios diegti agentines sistemas, praneša:

• Samprotavimo derinimas – sudėtingas uždavinys: kai daugiagentė darbo eiga stringa 47-ajame iš 50 žingsnių, klaidų paieškai tenka analizuoti gigabaitus duomenų be jokio standartizuoto formato.
• Kaštai – nenuspėjami: agentas, suprojektuotas kviesti tris įrankius, kraštiniu atveju gali iškviesti dešimt – ir per naktį gerokai padidinti ženklų sunaudojimo sąskaitą.
• Modelių elgsena keičiasi: kai „OpenAI“ atnaujina GPT-5, net kruopščiai suderintos užklausos gali grąžinti kitokius rezultatus – be jokio įspėjimo, be versijų fiksavimo ir be atstatymo galimybės.
• Vertinimas – subjektyvus: kaip patikrinti, ar agentas „teisingai suprato“ užklausą? Tradiciniai komponentų testavimo metodai čia nebetinka.

„Microsoft“ žingsnių sekimo grandinė ir „OpenAI“ vertinimo sistema bando šias problemas spręsti, tačiau abu sprendimai išlieka tiekėjams specifiniai, dar nesubrendę ir tinkamam įgyvendinimui reikalaujantys didelių inžinerinių išteklių.

Struktūrinė priklausomybė

Įmonės tai suvokia per vėlai: agentinės architektūros kiekviename sluoksnyje sukuria priklausomybę.

• Jūsų komanda išmoksta dirbti su „AutoGen“ karkasu → perėjimas prie „Bedrock“ reiškia pakartotinius specialistų mokymus ir darbo eigų perrašymą.
• Jūsų agentai optimizuoti pagal GPT-5 mąstymo stilių → migracija į „Claude“ ar „Gemini“ reiškia, kad užklausų rezultatus teks vertinti iš naujo.
• Jūsų duomenys struktūruoti pagal „Agentforce“ → jų perkėlimas į kitą platformą reikalauja naujo duomenų gavimo sluoksnio kūrimo.
• Jūsų stebėsena paremta „CloudWatch“ → perėjimas prie „Azure“ reiškia ankstesnių telemetrijos duomenų praradimą ir naujų valdymo skydelių kūrimą.

Tai nėra tas pats, kas perėjimas iš „AWS EC2“ į „Google Compute Engine“, kur API yra panašūs. Agentų platformos iš esmės skiriasi savo mąstymo, atminties ir koordinavimo architektūra.

Agentų valdymas – problema, apie kurią vengiama kalbėti

Didėjant agentų autonomijai, iškyla naujų rizikų:

• Kas atsako, kai agentas priima sprendimą, sukeliantį finansinius nuostolius ar pažeidžiantį ES reglamentus?
• Kaip atlikti agento samprotavimo auditą industrijose, kuriose galioja atitikties reikalavimai?
• Kas nutinka, kai agentas pasiekia duomenis, kuriems neturėjo leidimo?
• Kaip užtikrinti, kad agentai neplatintų šališkumo ar neleistinų rezultatų?

„IBM watsonx.governance“ ir „Microsoft Entra ID“ integracija bando šias problemas spręsti, tačiau kartu didina sudėtingumą ir kaštus. Smulkiosioms ir vidutinėms įmonėms, veikiančioms reguliuojamose industrijose, valdymo našta gali nusverti automatizacijos naudą – bent jau tol, kol standartai taps brandesni.

Tradicinis DevOps modelis netinka

„DevOps for Agents“ – nuolatinis testavimas, diegimas ir tobulinimas – skamba patraukliai, tačiau ši idėja remiasi prielaida, kad agentai veikia kaip tradicinė programinė įranga. O taip nėra.

• Neapibrėžtumas griauna CI/CD procesus: to paties testo negalima paleisti du kartus tikintis identiškų rezultatų.
• Palaipsnis diegimas rizikingas: agentas, puikiai veikiantis esant 10 % srautui, dėl naujų besiformuojančių tendencijų gali elgtis visai kitaip esant 100 % srautui.
• Atstatymas – sudėtingesnis: jei agentas mokosi iš sąveikų su naudotojais, ankstesnės versijos atstatymas nepanaikina to, ką naudotojai jau patyrė.

Mąstymo modelį reikia keisti – nuo „versijų diegimo“ prie „besivystančių sistemų mokymo ir stebėsenos“. Tai iš esmės kita disciplina, o jai reikalingi įrankiai kol kas tik pradeda rastis.

Tikrasis konkurencinis pranašumas

Ateinantis dešimtmetis apdovanos ne tas įmones, kurios įdiegs agentus greičiausiai, o tas, kurios sugebės išsiaiškinti:

1. kaip išlaikyti agentų veiklą suderintą su verslo tikslais, jiems tampant vis savarankiškesniems;
2. kaip suburti komandas, gebančias efektyviai šalinti klaidas neapibrėžtose sistemose;
3. kaip valdyti kaštus, kai dirbtinio intelekto naudojimas sunkiai prognozuojamas;
4. kaip išvengti priklausomybės nuo tiekėjų, vis dar naudojant pažangiausius įrankius.

Laimės tos organizacijos, kurios išliks skeptiškos, investuos į vidinę kompetenciją ir atsispirs spaudimui diegti agentines platformas anksčiau, nei jos bus iš tiesų tam pasirengusios.

Agentų era jau atėjo – ir ji atėjo ne kaip paruoštų sprendimų rinkinys, o kaip sudėtingų ir brangių problemų laikotarpis.

Baigiamosios įžvalgos

Agentinės ekosistemos žada mus išlaisvinti nuo rutinos – jos automatizuoja nuobodžius darbus, supaprastina sudėtingus procesus ir mąsto mūsų vardu. Tačiau istorija rodo, kad revoliucijas keliantys patogumai visada turi savo kainą.

Perleisdami agentinėms sistemoms vis daugiau kognityvinės ir operacinės kontrolės, rizikuojame pamiršti įgūdžius, dėl kurių apskritai tapome specialistais. Prieš daugiau nei dešimtmetį debesijos technologijos perėmė vietos infrastruktūrą – dabar jos perima intelektą. O kai paslauga pati tampa „mąstymo architektūra“, techninė priklausomybė pamažu įsitvirtina kultūroje.

Kontrolės iliuzija – paskutinė patogumo fazė. Kuo sklandesnė patirtis, tuo sunkiau įsivaizduoti darbą be jos. Agentams nereikia mūsų pavergti – pakanka tapti nepakeičiamiems.

Dirbtinio intelekto amžiuje tikrasis pasipriešinimo aktas – išlikti sąmoningiems: žinoti ne tik, ką gali mašinos, bet ir kodėl joms tai leidžiame.