El 2025 podria ser l'any dels agents d'IA, si poden sobreviure a l'infern empresarial

Durant dècades, les empreses han intentat automatitzar les tasques de back-office, l'entrada de dades, els processos de facturació i altres fluxos de treball repetitius. Però tot i que el programari ha evolucionat, la veritable automatització d'extrem a extrem segueix sent esquiva per a la majoria de les empreses. Ara, amb el ràpid augment dels grans models de llenguatge (LLM) i l'aparició d'"agents d'IA" capaços de raonar i actuar de manera autònoma, hi ha una creença creixent que el 2025 podria ser l'any en què finalment veiem un important salt endavant en l'automatització empresarial.

Sam Altman ha afirmat públicament que "el 2025, podrem veure els primers agents d'IA s'incorporen a la plantilla i canvien materialment la producció de les empreses", mentre que Marc Benioff està orientant Salesforce cap a "AgentForce" en previsió d'un futur on es deleguin molts processos organitzatius. als agents especialitzats. Aquestes prediccions plantegen una pregunta central: els agents d'IA poden superar els complicats obstacles dels sistemes empresarials del món real? En aquest article, examinarem les dificultats úniques de l'automatització empresarial i explorarem algunes de les solucions prometedores (però encara madurant) actuals. També compartirem proves pràctiques amb un flux de treball aparentment senzill a Salesforce (SFDC), creant una comanda de distribuïdor per a un compte nou, que revela la complexitat que s'amaga darrere de les escenes.

Per què és tan difícil l'automatització empresarial?

Sobre el paper, automatitzar les tasques empresarials sembla senzill: engegueu un script per iniciar sessió, ompliu formularis i feu clic a "enviar". A la pràctica, la complexitat és sorprenent. Les empreses confien en una infinitat de sistemes de registre com Salesforce, SAP, Oracle i moltes solucions pròpies. Cada sistema té la seva pròpia web de permisos, fluxos d'autenticació i lògica empresarial personalitzada. A més, aquests sistemes sovint estan molt personalitzats. És habitual veure interfícies d'usuari especialitzades, camps de dades addicionals i fluxos de treball personalitzats que difereixen d'una empresa a una altra.

Segons una enquesta conjunta de MuleSoft i Deloitte, les grans empreses poden utilitzar una mitjana de 976 sistemes diferents per donar suport a les operacions diàries ( font ). Aquesta fragmentació significa que una eina d'automatització ha de parlar amb múltiples sistemes, cadascun amb el seu propi matís; alguns amb API robustes, altres sense cap. Sovint, les tasques més senzilles impliquen connectar dades entre aplicacions antigues i antigues i nous serveis basats en núvol. Fins i tot les plataformes estàndard com Salesforce poden esdevenir laberíntiques un cop s'estableixin fluxos de treball personalitzats i integracions de tercers.

En aquest context, els agents impulsats per LLM prometen un enfocament més flexible: poden analitzar dades, raonar sobre els propers passos i fins i tot navegar per interfícies gràfics d'usuari complicades, almenys en teoria. Però, com veureu a l'exemple següent, la realitat d'aconseguir que un agent d'IA faci fins i tot un flux de treball bàsic de Salesforce sense ajuda humana és més complicada del que molts s'imaginen.

Un exemple pràctic: creació d'una comanda de distribuïdor personalitzada a Salesforce

La Tasca

Imagineu que sou soci de vendes d'una empresa de fabricació de bicicletes que utilitza Salesforce. Acabeu de vendre 1 bicicleta Dynamo X1 gran per 5.000 dòlars a un distribuïdor nou anomenat "Northern Trail Cycling". La teva feina és:

1 - Autentiqueu-vos a Salesforce (amb les credencials proporcionades).

2 - Creeu un compte nou per al distribuïdor.

3 - Creeu una comanda de distribuïdor i afegiu la línia de comanda (la bicicleta).

4 - Presentar aquesta comanda a la fabricació per a la seva aprovació.

Per a una execució exitosa, esperem que el resultat final sembli el següent:

Sembla prou senzill, però el diable està en els detalls. La instància de Salesforce de l'empresa està personalitzada: utilitza un objecte i un flux personalitzats de "comanda de distribuïdor", una funció especial d'arrossegar i deixar anar per afegir productes i un pas amagat d'"enviament a la fabricació" sense etiquetatge clar. Vaig provar aquest escenari utilitzant diversos enfocaments emergents d'automatització impulsats per IA per veure com es mesuren.

Claude Ús de l'ordinador

Què és?

Claude Computer Use és una nova característica d'Anthropic, introduïda amb Claude 3.5 Sonnet v2 . Fa un pas més enllà el paradigma de trucada de funcions LLM estàndard donant a Claude tot un entorn d'escriptori en contenidors per "veure" i "controlar". Pot capturar captures de pantalla, interpretar-les mitjançant un raonament visual/espacial i realitzar accions a nivell del sistema operatiu com ara clics del ratolí, desplaçaments i pulsacions de tecles.

Des de la perspectiva d'un usuari, li doneu a Claude una tasca d'alt nivell ("Inicieu la sessió a Salesforce i creeu aquesta comanda de distribuïdor") i Claude intenta fer-ho exactament. Recorre una seqüència de:

1. Captura d'una captura de pantalla i interpretació.
2. Emissió d'accions d'IU (clics del ratolí, pulsacions de tecles, ordres bash).
3. Repetint fins que la tasca s'hagi completat (o es rendeixi).

Posant-ho a prova

Comencem amb l'enfocament més senzill d'executar la implementació de referència d'Anthropic sense cap canvi a l' indicador del sistema . Aquí hi ha l'inici de la interacció que mostra el missatge inicial, el pla proposat per Claude i l'escriptori amb el qual està començant la interacció.

Observar l'escriptori en contenidors de Claude va ser inicialment impressionant. Va obrir el navegador, va visitar l'URL de Salesforce, va iniciar sessió amb les credencials proporcionades i va navegar a "Comptes". Va crear perfectament un compte nou per a Bike Production Company , introduint els detalls correctes al formulari i després va intentar crear una nova comanda de distribuïdor. Les coses anaven bé fins que es va trobar amb la interfície personalitzada d'arrossegar i deixar anar per afegir la bicicleta. El sistema es va bloquejar intentant realitzar un arrossegar i deixar anar basat en píxels.

Després d'alguns errors, va intentar trobar un mètode alternatiu (com ara un botó ocult "Afegeix un element"). El primer intent amb el botó "editar" no va tenir èxit.

"Noto que al diàleg d'edició no hi ha una manera clara d'afegir productes. Permeteu-me provar un enfocament diferent fent clic al menú desplegable Comandes de distribuïdor per veure si hi ha altres opcions".

Finalment, va trobar el seu camí descobrint una manera d'afegir nous elements a través de la pestanya "relacionat", només per fallar quan els activadors dinàmics de l'aplicació no actualitzen automàticament el total de la comanda. Els desenvolupadors de l'aplicació SFDC no van completar el desenvolupament d'aquesta ruta de codi, esperant que l'usuari humà només segueixi el mètode d'arrossegar i deixar anar. En resum, el flux va ser dissenyat per a humans, no per a un agent d'IA.

Llavors, Claude va intentar localitzar el botó "enviar a la fabricació", que estava enterrat sota una pestanya personalitzada. A falta de coneixements previs d'aquest pas, va patir uns quants minuts més. Finalment, vaig haver d'intervenir, afegir manualment la bicicleta a la comanda i assenyalar Claude al botó corresponent. Després d'aproximadament 10 minuts i uns 0,80 dòlars en costos d'ús, el procés encara no estava totalment automatitzat. Era fàcil veure per què Anthropic anomena aquesta funció experimental: es necessiten moltes baranes i millores del món real abans que l'ús de l'ordinador pugui estar realment preparat per a la producció.

Pot ser millor?

Malgrat les seves vores aspres, el concepte és emocionant. La IA basada en la visió per a la interacció amb GUI està millorant ràpidament i la corba de costos per a la inferència està baixant ràpidament. Un estudi recent a16z suggereix que per al mateix rendiment, els costos de LLM estan disminuint aproximadament 10 vegades l'any. En principi, les futures versions de Claude podrien ser més ràpides, més barates i més precises en tasques visuals/espacials com ara arrossegar i deixar anar.

No obstant això, el problema fonamental continua sent que les interfícies d'usuari empresarials, especialment les més antigues o molt personalitzades, poques vegades es creen tenint en compte l'automatització. Les interaccions a nivell de píxels són fràgils. Els canvis menors al disseny o les finestres emergents dinàmiques poden trencar tot el flux. També hi ha una investigació creixent sobre marcs de GUI basats visualment, però fer que aquests siguin de qualitat per a centenars de fluxos de treball diferents és una tasca important.

Navegadors sense cap: saltar la GUI per complet

Un enfocament alternatiu és ignorar completament els "caixes delimitadors visuals". Si la vostra aplicació objectiu s'executa en un navegador web, podeu automatitzar-vos a nivell DOM, saltant captures de pantalla i interaccions basades en píxels. Tot i que els navegadors sense cap tradicionals com Playwright i Selenium s'associen sovint amb marcs de prova, està sorgint una nova generació de navegadors sense cap enfocats en casos d'ús d'IA. Aquestes plataformes més noves es basen en Playwright i Selenium per permetre interaccions més dinàmiques basades en LLM.

BrowserBase

BrowserBase n'és un exemple. Funciona com una plataforma d'infraestructura que allotja i escala les sessions del navegador sense requerir que els desenvolupadors gestionen contenidors. El patró d'interacció gira al voltant de l'anàlisi del contingut HTML d'una pàgina en components (per exemple, formularis, botons) assignats als seus xPaths i passar aquesta estructura a un LLM que trieu. Aleshores, el LLM genera el següent conjunt de codi de Playwright per executar, permetent la interacció amb el DOM mitjançant el codi en lloc dels clics tradicionals de la GUI. Com que és purament sense cap, fa servir menys o cap captures de pantalla, mantenint la durada del context curta i la latència més baixa que un enfocament complet d'"entorn d'escriptori".

Més recentment, BrowserBase va enviar la seva biblioteca de codi obert StageHand per facilitar les coses als desenvolupadors. En el model original, les interaccions encara eren molt manuals, la qual cosa requeria que els desenvolupadors treballessin amb els detalls de baix nivell del navegador sense cap, inclosa escriure directament codi de Playwright i analitzar manualment HTML. Amb StageHand, BrowserBase proporciona un nivell d'abstracció més alt, permetent als desenvolupadors utilitzar ordres de llenguatge natural basades en intencions com ara "navegar" o "extreure". Aquest enfocament també inclou alguns processaments per convertir HTML en brut en components, cosa que facilita al LLM gestionar les tasques. Tanmateix, els usuaris encara han de crear les seves pròpies capes d'orquestració per connectar i gestionar els fluxos de treball, ja que StageHand en si no ofereix una orquestració integrada.

Per provar BrowserBase, vaig utilitzar el seu parc infantil per a desenvolupadors, que proporciona una consola per escriure codi de Playwright i un escriptor d'indicacions LLM per produir automàticament aquests scripts. La idea és fer una navegació en diversos passos: iniciar sessió, crear un compte, crear una comanda de distribuïdor. Però la plataforma espera que vosaltres mateixos orquestriu els passos. Començant amb la mateixa indicació donada a Claude, BrowserBase va ensopegar, ja que no podia raonar en diversos passos. Així que vaig procedir a proporcionar un missatge de llenguatge natural per a cada pas i vaig observar si el codi de dramaturg generat estava fent el que es pretenia. A la captura de pantalla següent, podeu veure la sèrie de sol·licituds i el codi de dramaturg generat.

A la pràctica, em vaig trobar amb una desalineació ocasional entre l'entorn del navegador de Playground i els formularis HTML que calia omplir. Els botons es van representar de manera estranya, els temps d'espera es van ampliar i els camps del formulari no es van carregar exactament com s'esperava. Malgrat aquests errors, el codi de dramaturg generat per LLM va aconseguir iniciar sessió, crear un compte i omplir parcialment el formulari de comanda del distribuïdor. Tanmateix, arrossegar i deixar anar per afegir l'element va tornar a ser un obstacle. Vaig passar uns set minuts jugant-hi abans de rendir-me. Estava clar que la plataforma encara no és apta per a aquest tipus d'automatització. Probablement funcioni millor per als casos d'ús del raspat web.

Skyvern

Skyvern és un enfocament sense cap més tot en un que afegeix orquestració per defecte. A diferència de BrowserBase, que requereix que els usuaris defineixin i gestionen els passos manualment, Skyvern intenta gestionar l'orquestració de manera immediata. Sota el capó, funciona de manera similar a BrowserBase, com es veu al seu codi de codi obert , però també afegeix un agent web que pot orquestrar i raonar els passos. Això inclou un mode de visió opcional que envia captures de pantalla al LLM juntament amb els components extrets i els seus xPaths per ajudar en la presa de decisions.

Per abordar les limitacions de la creació manual de passos a BrowserBase, vaig decidir provar Skyvern utilitzant el seu servei gestionat, centrant-me específicament en el mode de flux de treball. Aquest mode està dissenyat per a processos de diversos passos i volia avaluar el rendiment que funciona amb el nostre flux de treball de Salesforce. Malauradament, l'execució va gastar més de 15 passos de raonament i 1 $ de crèdits bloquejats en el procés d'autenticació de dos factors (2FA). La IP allotjada de Skyvern es va marcar, activant 2FA i no hi havia manera de proporcionar manualment un codi o compartir una galeta per evitar la situació. Això posa de manifest el repte permanent de l'autenticació a la configuració empresarial i subratlla per què estan sorgint startups com Anon per centrar-se únicament en solucions d'autenticació per als agents d'IA.

L'equip de Skyvern posiciona la plataforma com a adequada per a tasques més senzilles i petites, amb l'automatització del formulari de contacte com el cas d'ús principal compatible. Altres casos d'ús potencials (per exemple, feines, factures) encara es mostren com a "en formació", cosa que indica que la plataforma comença amb una automatització centrada en casos d'ús senzill en lloc de les necessitats més complexes dels fluxos de treball empresarials. Tot i que és prometedor, està clar que Skyvern és més adequat per a escenaris menys complicats en aquesta etapa del seu desenvolupament.

Compensacions

Els navegadors sense cap s'ometen les conjectures a nivell de píxels, la qual cosa sovint condueix a menys errors i a una execució més ràpida. Però tan bon punt arribeu a funcions avançades com ara arrossegar i deixar anar o aplicacions complexes d'una sola pàgina, és possible que hàgiu de tornar a l'anàlisi parcial de captures de pantalla o al codi especialitzat. Els navegadors també poden trobar-se a la llista negra 2FA i IP. Per a aplicacions empresarials multi-inquilí, només l'autenticació pot ser complicada i és possible que encara necessiteu capes d'orquestració personalitzades.

Una altra limitació és que aquestes plataformes es basen en la generació de codi dinàmicament mitjançant LLM cada vegada que s'executa el flux de treball. Atès que els LLM són inherentment no deterministes, el codi que s'obté pot variar segons les execucions, cosa que fa que sigui difícil auditar o verificar la coherència. Aquesta imprevisibilitat pot provocar problemes, especialment en fluxos de treball sensibles. Tot i que l'emmagatzematge en memòria cau del codi generat sembla estar al full de ruta d'algunes plataformes, suposa reptes importants per als LLM. Fins i tot els canvis menors en el processament d'indicadors o lots durant la inferència poden produir resultats completament diferents, cosa que complica el procés de memòria cau.

En general, la navegació sense cap pot ser més barata i més estable que la manipulació completa de la GUI, però està lluny de ser una solució màgica. Moltes solucions, com ara BrowserBase i Skyvern, es centren en casos d'ús més restringits (per exemple, formularis, extracció de dades) en lloc de ser la "única plataforma per automatitzar-ho tot".

API internes d'enginyeria inversa

Un tercer enfocament és evitar la pàgina web per complet interceptant les trucades de xarxa que es produeixen quan feu clic. Si podeu capturar les sol·licituds que envia el vostre navegador, podeu reconstruir aquestes trucades en codi. En principi, això evita passos desordenats basats en la interfície d'usuari i garanteix que esteu arribant a la mateixa lògica de fons que utilitza la vostra aplicació. Aquesta tendència no és del tot nova, ja que les API d'enginyeria inversa existeixen des de fa molt de temps. Tanmateix, la nova incorporació incorpora un agent d'IA per raonar les peticions de la xarxa, fent que el procés sigui més intel·ligent i adaptable.

Fa uns mesos, un producte anomenat Integuru es va llançar a Hackernews i ha cridat l'atenció pel seu enfocament de codi obert i la seva nova metodologia. Intrigat pel seu potencial, vaig decidir provar-lo, atret pel seu interessant enfocament basat en gràfics i la integració d'agents d'IA per raonar les peticions de la xarxa. La promesa de reduir dràsticament el temps i el cost de l'automatització la va convertir en una opció atractiva per explorar.

El dipòsit d'Integuru és relativament nou, però és prometedor. En el seu nucli, registra tot el trànsit de xarxa i les galetes a Chromium durant una tasca. A continuació, crea una representació gràfica de les sol·licituds, assignant quines pàgines criden a quins punts finals. Utilitzant aquest gràfic, realitza un recorregut, el passa a un LLM per generar codi per a cada node que reprodueix les mateixes sol·licituds, injectant els vostres paràmetres dinàmics (com ara "Empresa productora de bicicletes") segons sigui necessari i unint-los en funció de les dependències. Aquest enfocament podria racionalitzar teòricament el procés d'automatització de manera significativa.

A la pràctica, però, no va funcionar bé per al nostre cas d'ús, sobretot a causa de les limitacions de la finestra de context. El flux podria haver estat massa llarg perquè el LLM ho pogués gestionar amb eficàcia. Fins i tot els intents de curtcircuit el procés incrustant galetes d'inici de sessió directament i començant des de la pàgina d'inici no van tenir èxit. Tot i que sospito que la meva clau de l'API OpenAI de nivell baix va contribuir a aquests problemes, està clar que Integuru encara està en els seus inicis. El potencial hi és, però el producte requereix més perfeccionament. Les seves demostracions (com ara descarregar documents fiscals de Robinhood) van funcionar millor en marcs web moderns amb fluxos més senzills. Salesforce, amb el seu complex frontal i objectes personalitzats laberíntics, va introduir errors.

Dit això, aquest mètode encara no és una solució universal. La necessitat d'enregistrar tots els passos limita la seva flexibilitat i s'inclina cap a un enfocament més estàtic de generar codi per a fluxos específics per endavant, que recorda les eines RPA basades en regles populars fa una dècada. Això posa de manifest una limitació fonamental: tot i que l'addició de raonaments d'IA a les sol·licituds de xarxa és emocionant i pot obrir les portes per integrar-se amb sistemes que no tenen API, encara és més adequat per a tasques més controlades o repetides que per a fluxos de treball dinàmics i diversos. entorns empresarials.

AgentForce: la solució nativa de Salesforce

Cap conversa sobre l'automatització impulsada per IA a Salesforce estaria completa sense esmentar AgentForce , la gran aposta de Marc Benioff per crear "agents" dins de l'ecosistema de Salesforce. A diferència d'altres solucions que hem provat anteriorment, que estan enfocades als desenvolupadors i tenen com a objectiu automatitzar els fluxos de treball en diversos sistemes, AgentForce es posiciona com una solució integrada de codi baix específicament per a Salesforce. Empaqueta molts components i se centra en tot el flux de la plataforma Salesforce.

La idea és crear agents que resideixin completament a Salesforce i que es basen en les vostres personalitzacions. Els usuaris defineixen la descripció general d'un agent, assignen temes i enllacen accions associades que són fluxos preconstruïts definits en codi o mitjançant la interfície d'usuari de Salesforce. A continuació, es configuren els permisos, els rols d'usuari i les instruccions per permetre que l'agent funcioni. Aquest concepte teòricament permet a les empreses aprofitar les seves dades i fluxos de treball existents de Salesforce per impulsar l'automatització sense una codificació extensa.

Volia provar AgentForce directament amb el nostre exemple de comanda de distribuïdor d'eBikes. Malauradament, cal accedir a Einstein (funcions d'IA), que no està disponible en un compte de desenvolupador gratuït. En canvi, vaig explorar el seu parc infantil de 30 minuts amb l'aplicació fictícia "Coral Beach Resort". La tasca de prova va ser configurar un agent per automatitzar la creació d'una reserva, un procés una mica anàleg a una comanda de distribuïdor en el nostre escenari eBikes.

La configuració va ser força implicada, i va requerir diversos passos: definir permisos, habilitar temes, connectar-se a accions preconstruïdes, mapejar camps de dades i aclarir instruccions. Tot i que es comercialitzava com una solució de codi baix, va quedar clar que calia un coneixement important de les complexitats de Salesforce. Si la instància de Salesforce d'una empresa no té camps personalitzats ben documentats i fluxos d'acció preconfigurats, l'augment inicial pot ser substancial. De manera realista, la majoria de les empreses probablement haurien de portar integradors de sistemes o consultors per implementar i optimitzar completament aquests agents.

La naturalesa basada en regles d'AgentForce també va destacar. Els usuaris han de mapejar acuradament quins camps s'omplen o es transmeten perquè l'automatització funcioni amb precisió, fent-la més pràctica que algunes plataformes impulsades per IA. Tot i que aquest enfocament garanteix la precisió, reforça la dependència de la forta experiència de Salesforce i la infraestructura existent.

Tot i que AgentForce es limita a l'ecosistema de Salesforce, això té avantatges i inconvenients. D'una banda, és una solució empaquetada que unifica l'autenticació, els permisos d'usuari, les definicions d'eines i la lògica d'orquestració en una única plataforma. D'altra banda, molts fluxos de treball empresarials abasten diversos sistemes, i la naturalesa aïllada d'AgentForce limita la seva aplicabilitat per a necessitats d'automatització més àmplies. Marc Benioff ha afirmat que centenars de clients ja han signat acords per utilitzar AgentForce, per la qual cosa valdrà la pena fer un seguiment de la seva evolució.

Així que... Ja hi som?

A partir d'aquests experiments, està clar que les solucions actuals d'agents d'IA poden fer un treball decent de raonament sobre tasques de diversos passos i forjar un pla. El veritable repte és l'execució en un entorn desordenat i del món real amb coneixements tribals sobre com es comporten realment aquests sistemes. Les interfícies d'usuari gràfiques es van crear per a la interacció humana i la lògica personalitzada de cada empresa és com un mini forat negre de complexitat. Fins i tot si ometeu la GUI per a un enfocament sense cap o feu enginyeria inversa de les API de fons, encara us enfronteu a casos extrems, obstacles d'autenticació, límits de velocitat o fluxos de treball dinàmics que descarten el millor dels LLM.

Els reptes restants són principalment problemes d'enginyeria: construir eines robustes, integrar-se profundament amb sistemes empresarials, establir baranes i crear marcs de monitorització i orquestració fiables. Aquests es poden resoldre amb un esforç i especialització dedicats. Els LLM actuals ja demostren capacitats de raonament molt més enllà del que estava disponible fins i tot fa un any, i el seu cost està baixant ràpidament. Ara l'enfocament ha de canviar a la construcció de la infraestructura i els processos necessaris per desplegar aquestes capacitats de manera eficaç.

No obstant això, aquestes dificultats no haurien d'ocultar el progrés constant que s'està produint. Ja estem veient automatitzacions d'IA especialitzades i enfocades verticalment (per exemple, SDR o agents d'atenció al client) que poden oferir una gran precisió en un domini controlat. A mesura que cadascuna d'aquestes automatitzacions d'un sol ús madura, és possible que les veiem encadenades en fluxos de treball més amplis. En última instància, això podria ser com trencarem l'automatització d'extrem a extrem a les grans empreses: combinant diversos agents especialitzats en lloc d'esperar que un sol agent de propòsit general ho faci tot. De moment, el retorn de la inversió de la creació d'un agent des de zero potser no s'aplica a totes les tasques, excepte a les de major volum.

L'especialització i el camí a seguir

Una lliçó d'aquestes proves és la importància de l'especialització. Aconseguir una fiabilitat gairebé perfecta en un únic domini (per exemple, la creació de factures a NetSuite) requereix un ajustament important. Les startups o els equips interns que se centren en un flux de treball especialitzat poden oferir una experiència millor que una solució àmplia i genèrica. Ja estem veient una onada d'"agents verticals" que s'ocupen de tasques específiques en finances, logística, recursos humans o cadena de subministrament. Cada agent s'integraria profundament, potser combinant l'automatització de la interfície d'usuari quan sigui necessari amb trucades directes a l'API quan sigui possible, a més de la lògica alternativa i les baranes específiques del domini.

La gran pregunta segueix sent: el 2025 serà realment l'any en què aquests agents es generalitzin, o estem buscant una pista més llarga? La tecnologia avança ràpidament i l'optimisme abunda. Però de la mateixa manera que els enginyers de programari no van desaparèixer quan la generació de codi va millorar, probablement no veurem l'automatització empresarial "mans lliures" per a tots els processos. En lloc d'això, veurem millores iteratives a les butxaques especialitzades, que eventualment les unirem com un mosaic d'automatitzacions parcials.

Conclusió

El concepte d'agents d'IA autònoms és innegablement convincent, especialment en entorns empresarials on abunden les tasques repetitives. Els beneficis potencials (estalvi de temps, reducció d'errors i permetre als empleats centrar-se en un treball més creatiu i estratègic) són enormes. Tanmateix, tot i que les capacitats fonamentals dels agents d'IA són fortes, el camí cap a l'adopció generalitzada depèn de la superació dels reptes d'enginyeria, a més d'avançar en la investigació subjacent.

Construir la infraestructura adequada és clau: eines robustes, integracions fiables i solucions específiques del domini amb baranes i capes d'orquestració ben definides. La complexitat dels sistemes empresarials del món real requereix solucions especialitzades, i aquí és on els agents verticals poden destacar. Centrar-se en fluxos de treball estrets i ben definits permet als equips perfeccionar les seves solucions amb un alt grau de precisió i fiabilitat, abordant els reptes únics de cada domini. Amb el temps, aquests agents especialitzats es podrien interconnectar, creant una xarxa més àmplia d'automatitzacions.

El 2025 pot portar avenços impressionants i un nombre creixent de programes pilot. En lloc d'un món amb pilot automàtic, és més probable que veiem automatitzacions orientades i altament efectives que aborden problemes específics. El viatge cap a l'automatització empresarial completa serà iteratiu, impulsat per l'especialització i la col·laboració. L'impuls s'està generant, i resoldre aquests reptes d'enginyeria obrirà el camí per a la propera onada d'innovació empresarial.

(Crèdits d'imatge destacats a DALL-E)