Eszközök

Intuit kétszer építette újra ügynökarchitektúráját négy hónap alatt — a hibák a nyelvi átadásoknál összegződtek

A főszereplő az Intuit és annak mesterséges intelligencia alelnöke, Nhung Ho, aki a VB Transform 2026 konferencián ismertette a vállalat ügynökarchitektúrájának kétszeri újraépítését nagyjából négy hónap alatt.

Intuit kétszer építette újra ügynökarchitektúráját négy hónap alatt — a hibák a nyelvi átadásoknál összegződtek

Intuit korán kezdett el kísérletezni ügynök-alapú (agentic) mesterséges intelligenciával, de a sikerhez vezető út nem volt egyenes. A VB Transform 2026 konferencián Nhung Ho, az Intuit mesterségesintelligencia-ért felelős alelnöke elmondta, hogy nagyjából négy hónap leforgása alatt kétszer építették át az ügynökarchitektúrát.

Mi történt: specialistáktól az orkesztrációig, majd vissza a készségekhez

Az első átalakítás során a vállalat a specialistákból álló ügynökflottáról egy központi orkesztrációs rétegre állt át, amelynek feladata az volt, hogy a felhasználói feladatra automatikusan kiválassza és összerendezze a megfelelő ügynököket. Ez az orkesztrátor megoldás körülbelül három hónapig működött — amit Ho félig tréfásan a 2026-os ügynökfejlesztés felgyorsult ütemében nagyjából egy évnek írt le.

Az orkesztráció azonban strukturális hibába ütközött: az ügynökök egymásnak természetes nyelven adták át az eredményeket, és minden átadásnál elveszett olyan kontextus, amelyet a következő ügynöknek a helyes működéshez kellett volna. Ho példája szerint ha 10 ügynök adja tovább egymásnak a válaszokat, az átadásoknál bekövetkező hibák összegződnek, így a lánc nem csak időnként hibázott, hanem a tervezésből fakadóan egyre degradálódott.

Ez a diagnózis vezette vissza Intuitot a készségek (skills) és eszközök (tools) alapú architektúrához.

A 60 napos újraépítés és a belső meggyőzés nehézségei

A teljes, második újraépítés hatvan napot vett igénybe; a csapat azonban már 20 napon belül bemutatott egy működő első verziót. Ho hangsúlyozta, hogy az architekturális döntésnél nehezebb feladat volt a belső támogatás megszerzése: vezetőség és azoknak a mérnököknek a meggyőzése, akik az eredeti specialistákat építették.

A vezetés meggyőzéséhez bizonyítékokra támaszkodtak: Ho csapata valós, élesben keletkezett ügyfélkérésekből készített demót, és megmutatták, hogy az új architektúra jobban teljesít ugyanazokon a feladatokon. A mérnököket más érveléssel nyerték meg: a skálázhatóság ígéretével. Egy önálló ügynök egy szűk problémát oldott meg, míg egy megosztott skill vagy tool ugyanazt a képességet több ügyfél és termékterület számára is szolgáltatta. Emellett a partnercsapatok napi felelőssége is átalakult: ahelyett, hogy új ügynököket építettek volna, az értékelések (evals) futtatása és fenntartása vált a mérés és üzemeltetés középpontjává.

Ember bevonása és a jogosultságok kezelése pénzügyi adatoknál

A leglátványosabb ügyféloldali fejlesztés egy olyan funkció, amely lehetővé teszi, hogy egy élő ügynökbeszélgetésbe valós ember lépjen be — jelenleg még korai tesztelés alatt, körülbelül az Intuit ügyfélbázisának 1%-án elérhető, és „néhány héten belül” tervezik a skálázást, mondta Ho.

Az ügyfél egy beszélgetés során behívhat egy Intuit terméktámogatót, saját könyvelőt vagy Intuit könyvelői közül valakit; az így belépő személy megkapja a teljes kontextust arról, amit az ügynök eddig tett. Ho éles kontrasztot húzott a legtöbb általános AI-csevegőtermékkel: míg egy általános asszisztens végül gyakran csak azt javasolja, hogy konzultáljunk szakemberrel, az Intuit rendszere közvetlen összekötést épít be ugyanabban a beszélgetésben.

Ez a kézi átvétel egy pénzügyi adatokhoz igazított jogosultsági modell mellett működik: minden műveletet, amelyet az ügynök a felhasználó pénzügyi adataival végez, előzetes engedélyhez kötnek. Ho szerint ez az engedélykérés idővel enyhülhet, ahogy a felhasználók bizalmat építenek, ugyanakkor minden ügynöktevékenységet auditálnak, és a naplózott műveletek visszafordíthatók, ha szükséges.

Visszajelzések mennyisége és minősége megváltozott

Az új architektúra megváltoztatta a visszajelzések gyűjtését és feldolgozását is. Ho szerint a korábbi visszajelzések ritkák és bimodálisak voltak: vagy nagyon pozitívak, vagy nagyon negatívak, és jellemzően az utóbbi dominált. A csevegésalapú rendszerben viszont minden beszélgetés visszajelzésként szolgál: Intuit a korábbi körülbelül 0,3%-ról közel 100%-ra emelkedett az expliciten hozzáférhető visszajelzés arányában.

Ezt a mennyiséget már nem lehet manuálisan vizsgálni, ezért Ho újra ír kódot, hogy modelleket készítsen a visszajelzések szisztematikus elemzésére, és azonosítsa, hol hibázik a rendszer. A direkt felhasználói hangmód miatt a csapatok olyan nyers visszajelzésekkel találkoznak, amelyek egyébként ritkán jutnának el hozzájuk: „egyértelműen megmondják, hogy hol hibázott az ügynök” — Ho idézte a felhasználói reakciókat, és hozzátette, hogy az emberek hajlandóak javítani is a rendszert, ha lehetőség nyílik rá.

Összegzés

Az Intuit tapasztalata az ügynökarchitektúra gyors átalakításáról rámutat arra, hogy a designhibák — különösen a természetes nyelvű átadásokból fakadó kontextusvesztés — komoly működési kockázatot jelentenek nagy láncokban. A vállalat válasza a skills-and-tools architektúra visszaállítása, a humán beavatkozás integrálása, szigorú jogosultságkezelés és a visszajelzések nagyszabású feldolgozása volt, amelyet Ho szerint a skálázhatóság és a valós ügyféladatokon alapuló bizonyítékok indokoltak.