Què diferencia un agent d’un chatbot, quina feina té sentit delegar-li i com mantenir el control.
Continguts
1. Què no és un agent d’IA
Un chatbot, per si sol, respon. Un script, un programa amb instruccions predefinides, executa unes regles. Un agent d’IA rep un objectiu, decideix els passos, utilitza eines, verifica el resultat i s’atura o pregunta quan no pot continuar.
La diferència no és que escrigui millor. És que pot avançar en una tasca i comprovar què ha passat després d’actuar.
Això no vol dir que hagi de tenir l’última paraula. A Èmfasi, el nostre agent de desenvolupament pot preparar una solució, però no donar la tasca per tancada.
La meva regla és aquesta: «el bot proposa i jo decideixo». Delego part de l’execució, no la responsabilitat sobre el resultat.
A Què és una agència AI-first i què hauria d’aportar realment a un client vaig explicar l’enfocament general. Aquí vull concretar què hi ha darrere d’un agent i quines condicions estableixo abans de deixar-lo treballar.
2. Les quatre peces i un recorregut real
Per entendre com funciona un agent, separo quatre peces:
Model: interpreta l’objectiu i raona sobre el pas següent.
Eines: permeten actuar. Poden ser API, connexions entre aplicacions; servidors MCP, un mecanisme per oferir eines al model; terminal, per executar ordres; o navegador.
Memòria o context: documentació, tasques i historial necessaris per treballar.
Bucle de control: observa, decideix, actua, verifica i repeteix dins dels seus límits.
En el nostre flux de desenvolupament, el recorregut comença amb una tasca. L’agent crea una branca, una línia de treball separada del codi principal, i escriu els canvis.
Després executa el build, el procés que construeix el web i comprova que es pot generar. Prova el resultat en un navegador i prepara una pull request, una proposta de canvis per revisar, amb una captura i una vista prèvia.
Una persona revisa la feina i decideix si es pot tancar la tasca.
Si falla el build, la feina queda bloquejada encara que l’agent afirmi que ha acabat. També hi ha un límit d’intents: no pot encadenar correccions indefinidament.
El model proposa passos, però les comprovacions determinen si la feina pot avançar. Una afirmació de l’agent no substitueix una prova.
3. Per a què serveixen de veritat
La primera pregunta no és què pot fer la IA, sinó què val la pena automatitzar.
Miro quatre senyals: freqüència, fricció, risc d’error i cost de revisió. Busco tasques repetides, passos que dificulten la feina, errors evitables i resultats que es puguin revisar sense haver de refer-ho tot des de zero.
En el nostre cas, les comprovacions periòdiques dels webs han permès detectar problemes de mesurament. La utilitat és trobar alguna cosa que necessita atenció, no produir un informe perquè ara sigui fàcil generar-lo.
També hi ha tres raons per frenar: un procés inestable, informació d’entrada poc fiable o un resultat que ningú no pugui comprovar.
Vaig desenvolupar aquests criteris a Quins processos automatitzar primer amb IA i quins no. Afegir un agent no canvia la pregunta de fons: quina feina val la pena delegar i qui la podrà verificar.
Si no sé com distingir un resultat correcte d’un d’incorrecte, encara no tinc una tasca ben definida per a un agent.
4. Per a allò que és exacte, codi. Per interpretar, un model
Haver construït agents no m’ha portat a posar un model en cada decisió.
Per a allò que és exacte utilitzo regles deterministes: davant de les mateixes condicions, el codi pren la mateixa decisió. Reservo el LLM, o model de llenguatge, per a allò que necessita interpretació.
Un exemple és el nostre sistema de primera resposta davant d’incidències web. Confirma el problema, fa comprovacions externes, crea una tasca i avisa. Les decisions segueixen regles escrites en codi. El model només redacta l’avís.
En aquest flux, el model no té eines per actuar: decideix el codi. Redactar un missatge no li dona permís per executar accions.
En un altre sistema, dedicat a comprovar la salut dels webs, les verificacions funcionen sense consultar cap model. No necessiten interpretar una petició: necessiten aplicar unes condicions i assenyalar desviacions.
Això obliga a distingir entre un agent d’IA i una automatització convencional. No tot el que automatitzem és un agent, ni necessita ser-ho.
El meu criteri no és afegir intel·ligència artificial a tots els passos. És assignar-li una funció concreta. Si les regles ja resolen una comprovació, no introdueixo un model perquè torni a decidir el mateix. Si necessito interpretar informació o redactar una explicació, aleshores valoro la seva intervenció.
5. Límits per disseny, no per instruccions
No baso la seguretat en un prompt, les instruccions que rep el model. Demanar-li que no faci alguna cosa no equival a impedir que pugui fer-la.
Aplico el mínim privilegi: cada agent disposa únicament dels accessos i les operacions necessaris per a la seva funció. No rep accés general a la infraestructura pel fet de necessitar una eina concreta.
També ha de quedar rastre de les seves accions i ha d’existir una manera d’aturar-ne l’execució. Els límits no poden dependre del fet que el model recordi obeir-los.
En desenvolupament, preparar una proposta no significa poder incorporar-la al codi principal. I tancar una tasca continua sent una decisió humana.
Un exemple domèstic ajuda a entendre la diferència: consultar el consum d’una rentadora no és el mateix que apagar-la. La lectura pot estar permesa, mentre que l’acció ha de passar per un control addicional amb salvaguardes. Llegir i actuar no han de compartir necessàriament el mateix permís.
El que delimita un agent no és només l’objectiu que rep. També són les accions que el sistema li permet dur a terme per assolir-lo.
6. Primer en mode ombra, amb una sortida mesurable
Abans d’incorporar-lo a la feina habitual, cada agent funciona en mode ombra: treballa, però el seu resultat només el veu el responsable.
No dono per superada aquesta fase perquè una demostració surti bé. Fixo per endavant un criteri mesurable, com un percentatge mínim de propostes acceptades o un període sense falses alertes crítiques.
El percentatge o el període han de quedar escrits abans d’avaluar. Així evito decidir després que el resultat ja sembla suficient.
Però hi ha una lliçó anterior: mesurar abans d’especificar.
En preparar un agent per revisar la qualitat de les tasques, vam contrastar les nostres premisses amb l’historial real. Diverses no se sostenien.
No era un problema del model ni de les seves instruccions. Era un problema de com havíem definit la necessitat que volíem resoldre.
Per això separo dues comprovacions: primer, si el problema és realment com creiem; després, si el sistema es comporta com necessitem.
El mode ombra serveix per avaluar el funcionament. No substitueix l’anàlisi prèvia. Un agent dissenyat sobre premisses no verificades genera soroll amb molta eficiència.
7. El cost no s’acaba en generar un resultat
En l’agent de desenvolupament separo el cost de produir codi del cost de verificar-lo. Són parts diferents de la feina i totes dues compten.
A això s’hi afegeix la revisió humana. Una proposta barata de generar no implica que la tasca completa hagi sortit barata.
També distingeixo el consum del model de la resta de costos. Una automatització determinista pot funcionar sense consumir tokens, les unitats de text que processa un model. Això no elimina la seva execució, manteniment o supervisió.
Hi ha decisions d’estalvi que tenen poc a veure amb fer l’agent més sofisticat. Valoro una subscripció davant del pagament per ús mitjançant una API quan el volum ho permet.
I prefereixo un cron del sistema, un programador que inicia tasques a hores fixades, abans que mantenir un agent actiu esperant que arribi el moment de treballar.
No m’interessa únicament quant costa generar una resposta. M’interessa quant costa arribar a un resultat que algú pugui revisar i acceptar. En el nostre flux de desenvolupament, el càlcul no s’acaba quan apareix el codi.
8. La feina es desplaça cap a revisar i decidir
La IA abarateix produir. No abarateix decidir ni verificar.
Si produïm el doble amb la mateixa taxa d’error, tenim el doble d’errors. Per això no em serveix mesurar l’avenç únicament per la quantitat de feina generada.
En el nostre flux de desenvolupament, una proposta no es converteix en feina acabada perquè l’agent ho digui. Ha de superar les comprovacions i la revisió d’una persona.
Això canvia on posem l’esforç. Generar codi deixa de ser l’única feina visible. Llegir-lo, provar-lo i decidir si resol la tasca continuen formant part del lliurament.
A Èmfasi, l’estàndard intern és de revisió, no de «més agents». L’autor respon del codi, tant si l’ha escrit ell com si l’ha escrit la IA.
Delegar l’escriptura no permet delegar també aquesta responsabilitat. La feina pot començar amb una proposta de l’agent, però acaba amb algú que l’entén i se’n fa responsable.
Si no ho has llegit i provat, no està fet.
