El 57% d'organitzacions ja desplega agents d'IA per executar workflows multi-etapa. No tasques soltes. No prompts individuals. Processos complets amb múltiples fases, on un agent rep un objectiu, el descompon, executa cada pas i entrega un resultat integrat.
Això és avui. El que ve és més significatiu: el 81% d'aquestes organitzacions planeja abordar casos d'ús més complexos abans que acabi 2026. Un 39% desenvoluparà agents específics per a processos multi-pas. I un 16% ja executa processos cross-funcionals que creuen múltiples equips.
Això ja no és experimentació. És execució en producció, amb retorns mesurables: un ROI mitjà del 171% en inversions d'AI agents, i un 80% d'empreses que reporten retorns econòmics verificables.
El shift de fons és clar. La IA ha passat de ser un assistent que suggereix a ser un operador que executa. I això canvia profundament com es dissenyen els processos de desenvolupament de programari.
Multi-stage workflows IA: l'estat actual
Dades agregades d'implementacions enterprise 2026
El canvi fonamental: d'assistència a propietat
Durant els últims dos anys, la IA en equips de desenvolupament ha operat en mode assistència. El developer té una tasca, demana ajuda a un copilot, revisa el suggeriment, l'ajusta i l'integra. L'humà dirigeix cada pas. La IA respon.
Els workflows multi-etapa inverteixen aquesta dinàmica.
En un workflow multi-etapa, l'agent rep un objectiu d'alt nivell i opera de forma autònoma a través de diverses fases fins a produir un resultat complet. L'humà no dirigeix cada pas. Supervisa el procés, intervé quan és necessari i valida l'output final.
L'humà participa activament en cada pas. L'agent suggereix, l'humà decideix. Funciona per a tasques individuals, però no escala quan el procés té 5, 10 o 15 passos encadenats.
Aquest canvi no és només semàntic. Té implicacions pràctiques directes:
- Disseny de processos: Ja no es dissenyen tasques aïllades perquè un agent les executi. Es dissenyen fluxos complets amb criteris d'entrada, sortida i validació en cada fase.
- Rols de l'equip: El developer passa d'escriure prompts individuals a definir especificacions i criteris de qualitat. Menys execució manual, més disseny de sistemes.
- Gestió d'errors: En un workflow de 8 passos, un error al pas 3 pot propagar-se silenciosament fins al pas 8. Sense observabilitat i sense punts de control explícits, el debugging es converteix en un problema seriós.
Aquí és on la majoria d'equips s'encalla. Passar de "faig servir la IA per a una tasca" a "la IA executa un procés complet" no és afegir més prompts. És redissenyar com treballa l'equip. I les dades ho confirmen.
Els 5 pain points que frenen workflows multi-etapa
Els workflows multi-etapa generen valor mesurable. Però també exposen problemes que les tasques aïllades no revelen. Segons dades d'implementacions enterprise, hi ha cinc obstacles recurrents que frenen l'adopció a escala.
Quan un agent completa una fase i passa el resultat a la següent, es perd informació. En un workflow de 6 fases, la degradació acumulada pot fer que el resultat final no tingui relació amb la intenció original.
Els sistemes legacy exposen informació d'una forma que té sentit per a humans, però no per a agents que necessiten dades estructurades, permisos granulars i feedback en temps real.
La qualitat de l'output d'un workflow multi-etapa és directament proporcional a la qualitat del context que rep. Si la informació està dispersa entre persones, wikis i canals de Slack, l'agent opera a cegues.
No n'hi ha prou de validar que cada pas funciona per separat. Cal validar que la cadena completa produeix el resultat esperat, incloent-hi els edge cases en les transicions entre fases.
Passar de "cada developer fa servir la IA per a les seves tasques" a "l'equip opera amb workflows multi-etapa" requereix canviar rols, redefinir responsabilitats i actualitzar processos de revisió. No passa sol.
La pèrdua de context en handoffs és exactament el problema que context engineering aborda com a disciplina: no es tracta de tenir un model més potent, sinó de dissenyar com flueix la informació entre fases. A la pràctica, es manifesta com a codi que no respecta decisions anteriors, documentació que contradiu la implementació o testing que valida comportaments incorrectes.
I la gestió del canvi, com analitzem a l'èxit de la IA en equips de desenvolupament és organitzatiu, segueix sent l'obstacle que menys atenció rep i el que més impacte té. Un developer que abans escrivia codi ara defineix especificacions. Un tech lead que abans revisava PRs ara dissenya workflows. Aquests canvis requereixen lideratge explícit.
Tres casos reals: on els workflows multi-etapa generen valor
Les dades agregades mostren la tendència. Els casos concrets mostren on es materialitza el valor. Hi ha tres patrons de workflow multi-etapa que apareixen consistentment en implementacions reals.
Document Processing (Legal/Finances)
Cada fase produeix un output que alimenta la següent. Si l'extracció es fa bé, la classificació és precisa. Si la classificació és precisa, la validació humana es redueix al mínim. I si la validació és ràpida, la integració és gairebé instantània.
El que falla quan no està ben dissenyat: Sense criteris clars d'extracció (quins camps, quin format, quines excepcions), l'agent pren decisions arbitràries que es propaguen a totes les fases següents. L'humà acaba revisant-ho tot, i el workflow multi-etapa es converteix en un procés manual amb passos extra.
Product Development Workflow
El research alimenta el PRD, el PRD estructura les stories, les stories defineixen els criteris, i els criteris determinen els slices. Cada fase refina i concreta l'anterior. Un agent amb accés al context complet del producte pot mantenir coherència al llarg de les cinc fases d'una forma que un equip fragmentat no sempre aconsegueix.
El que falla quan no està ben dissenyat: Sense una especificació clara de quines dades de research són rellevants, l'agent genera PRDs genèrics. Stories que no connecten amb necessitats reals. Criteris d'acceptació que no validen el que importa. El workflow produeix artefactes que semblen complets però no serveixen.
Code-to-Deployment Pipeline (SDD)
Pipeline Spec-Driven Development
Aquest és el workflow que connecta directament amb Spec-Driven Development. L'especificació actua com a font de veritat que alimenta totes les fases posteriors. L'agent no improvisa en cada pas. Segueix un pla derivat d'un document estructurat que l'equip ha validat.
El que falla quan no està ben dissenyat: Sense una spec ben escrita, l'agent planifica sobre asuncions. Sense criteris de validació clars, el review automàtic passa codi que no compleix amb la intenció original. Sense observabilitat entre fases, un error a la fase de planning es converteix en codi incorrecte que passa tots els checks perquè els checks també estan mal definits.
El patró comú en els tres casos
La qualitat del workflow depèn de la qualitat de l'especificació inicial i del context que flueix entre fases. El model de llenguatge és secundari. El que marca la diferència és l'arquitectura del procés.
MVP + Backlog intel·ligent: especificacions clares = execució més ràpida
Hi ha un punt on els workflows multi-etapa i el desenvolupament de producte convergeixen de forma natural: el MVP.
Quan un equip construeix un MVP, la velocitat importa. Però la velocitat sense direcció genera deute tècnic i producte que no valida la hipòtesi correcta. Els workflows multi-etapa ofereixen una solució concreta a aquest problema, sempre que es combinin amb especificacions ben definides.
No una llista de features, sinó un document estructurat que defineix quin problema resol cada feature, quins criteris d'èxit té i quines restriccions tècniques apliquen.
A partir de l'especificació, un agent descompon el MVP en tasques ordenades per dependència i prioritat. No un backlog estàtic, sinó un que s'actualitza a mesura que l'equip avança.
Cada tasca s'executa com un mini-workflow: spec, plan, implementació, testing, review. L'agent manté el context de la spec original.
Cada entrega es valida contra els criteris definits al pas 1. Si la implementació es desvia, es detecta abans d'acumular deute.
Aquest enfocament redueix el time-to-market de forma concreta. No perquè el codi s'escrigui més ràpid (que també), sinó perquè s'eliminen els cicles de retreball que apareixen quan l'equip construeix sense una spec clara.
Què necessita el teu equip per passar de tasques a workflows
Passar de fer servir la IA per a tasques individuals a operar workflows multi-etapa no és un canvi d'eines. És un canvi de sistema de treball. Basant-nos en el que observem en implementacions reals i en les dades d'adopció enterprise, hi ha cinc elements que els equips necessiten.
1. Especificacions com a font de veritat
Un workflow multi-etapa sense especificació és un agent improvisant. I un agent que improvisa genera output que sembla correcte però no ho és.
Spec-Driven Development proporciona el framework: un document estructurat que defineix què es construeix, per què, amb quines restriccions i com es valida. No ha de ser un document de 50 pàgines. Ha de respondre les preguntes que l'agent necessita per operar amb autonomia.
2. Context engineering dissenyat, no improvisat
El 46% de problemes en workflows multi-etapa vénen de pèrdua de context. Això es resol amb context engineering: dissenyar explícitament quina informació rep cada fase del workflow, en quin format i amb quin nivell de detall.
- Definir quin output produeix cada fase i quin input espera la següent
- Establir un format estàndard per a la informació que flueix entre fases
- Incloure metadata de traçabilitat (d'on ve cada decisió, quina spec la respalda)
3. Punts de control humà als llocs correctes
Human-on-the-loop no significa "l'humà no participa". Significa que participa en els moments de màxim impacte. Els punts de control han d'estar després de les fases on l'error té més cost de propagació. En un workflow code-to-deployment, això sol ser després del pla i després del review. No en cada línia de codi generada.
4. Testing i observabilitat per fase
Cada fase necessita els seus propis criteris de validació. No n'hi ha prou amb un test end-to-end al final del procés. El mínim viable:
- Criteris d'acceptació automatitzats per a cada fase
- Mètriques de qualitat de l'output (no només "va completar sense error", sinó "compleix amb els criteris de la spec")
- Logs de decisió de l'agent (per què va prendre cada decisió, quines alternatives va descartar)
- Alertes quan l'output es desvia significativament de l'esperat
5. Un Centre d'Excel·lència que sostingui el canvi
Els cinc pain points són organitzatius, no tècnics. Resoldre'ls requereix algú que dissenyi els workflows, formi l'equip, estableixi els estàndards de qualitat i ajusti el sistema a mesura que l'equip aprèn.
Això és exactament el que fa un Centre d'Excel·lència d'IA: no implementar una eina, sinó construir la capacitat organitzativa per operar amb IA a escala. Com documentem a agents d'IA a empreses 2026, el 80% d'empreses ja genera retorn amb agents. Però les que escalen són les que van resoldre el problema organitzatiu.
El que SDD resol: Els 5 pain points dels workflows multi-etapa són exactament el que aborda un Centre d'Excel·lència d'IA amb SDD. La "constitució" del projecte estructura el context. Els templates d'especificació garanteixen la qualitat en cada fase. I el playbook de prompts i el flux de code review són el mecanisme de change management: canvien com treballa l'equip, no només quina eina fa servir.
De tasques a processos: el canvi que ja està passant
Els workflows multi-etapa no són el futur de la IA en desenvolupament de programari. Són el present. El 57% d'organitzacions ja els desplega, i el 81% planeja anar més enllà aquest any. El ROI mitjà del 171% confirma que el valor és real i mesurable.
Però passar de tasques aïllades a workflows complets no és qüestió d'escalar el que ja funciona. És un canvi de sistema de treball que requereix:
- Especificacions estructurades com a font de veritat
- Context engineering dissenyat, no improvisat
- Punts de control humà ben ubicats
- Testing i observabilitat en cada fase
- Una organització preparada per operar de forma diferent
Els equips que tracten la IA com un assistent per a tasques soltes obtindran millores incrementals. Els que la integren com a operador de processos complets, amb l'arquitectura correcta per sostenir-ho, obtindran millores d'ordre de magnitud.
La diferència entre uns i altres no està en el model de llenguatge que fan servir. Està en les especificacions que escriuen, el context que dissenyen i el sistema de treball que construeixen al voltant.
Fonts principals: "How enterprises are building AI agents in 2026" (Anthropic), "Multi-agent workflows often fail" (GitHub Blog), "The 2026 Guide to Agentic Workflow Architectures" (Stack AI), "Agentic workflows for software development" (McKinsey), "AI Agents In Product Management: What Changes In 2026".
Lectura complementària: Spec-Driven Development: IA en codi controlat | Context Engineering: la disciplina per a equips amb IA | Agents IA a empreses 2026
Metodologia onext: Els Centres d'Excel·lència d'IA d'onext implementen workflows multi-etapa amb Spec-Driven Development perquè els agents generin impacte estructural. Sense paralitzar lliuraments.