Un mismo proceso puede ser demasiado complejo para resolverlo con un prompt y, aun así, no necesitar un agente especializado para ese proceso. Esa distinción es importante porque la conversación sobre agentes de IA suele empezar demasiado tarde: cuando ya hemos decidido que queremos uno.
La pregunta útil para un estudio de arquitectura es otra: ¿qué problema profesional estoy intentando resolver y cuál es el nivel mínimo de autonomía que necesito?
En algunos casos bastará con una consulta en el chat del proyecto. En otros convendrá definir un workflow y ejecutarlo con una herramienta agentic como ChatGPT Work. Y solo cuando el valor dependa de que el sistema mantenga iniciativa y decida dinámicamente cómo avanzar puede compensar configurar un agente especializado o dedicado al proceso.
La complejidad, por sí sola, no justifica un agente. Lo que lo justifica es la combinación entre variabilidad, necesidad de decisión dinámica y capacidad de mantener esa autonomía bajo control.
Un proceso claro puede no necesitar un agente especializado
Hay procesos de arquitectura exigentes, largos y con mucha documentación que siguen siendo bastante previsibles.
Pensemos en la revisión completa de un proyecto antes de una entrega. Hay que contrastar memoria, planos, cuadros, superficies, mediciones y otros documentos. Puede exigir horas de trabajo y bastante criterio profesional. Pero, si el estudio sabe qué debe revisar, con qué criterios y cómo registrar las incidencias, el recorrido puede definirse de antemano.
En ese caso no necesitamos configurar un agente especializado para ese proceso. Podemos definir un workflow de revisión y ejecutarlo, por ejemplo, con ChatGPT Work dentro del Proyecto de ChatGPT.
Conviene separar aquí dos capas: el diseño del proceso y el producto con el que lo ejecutamos. OpenAI define Work como un agente para trabajos largos y de varios pasos. Usar Work no convierte el proceso profesional en un agente especializado ni convierte a Work en un workflow.
Puede ejecutar un protocolo acotado porque el arquitecto ha fijado de antemano objetivos, documentos, controles y salida.
Lo relevante aquí no es la etiqueta tecnológica. Es que el arquitecto sigue definiendo el procedimiento: qué revisar, qué criterios aplicar, qué salida espera y dónde debe existir una revisión humana.
Por tanto, una tarea puede ser muy compleja y seguir encajando mejor en un workflow bien diseñado, aunque ese workflow se ejecute mediante un sistema agentic.
La primera prueba: ¿el proceso necesita decidir el camino?
Aquí aparece la frontera realmente útil.
Anthropic distingue entre workflows, donde modelos y herramientas siguen rutas predefinidas, y agentes, donde el modelo dirige dinámicamente el proceso y el uso de herramientas.
Microsoft plantea una distinción similar: si los pasos y el orden de ejecución están bien definidos, un workflow suele ser la opción adecuada; si la tarea es abierta y necesita planificación o uso autónomo de herramientas, empieza a tener sentido un agente.
OpenAI también recomienda reservar los agentes para situaciones en las que la solución determinista se queda corta, por ejemplo cuando existen decisiones complejas, reglas difíciles de mantener o mucha información no estructurada.
Traducido a un estudio de arquitectura: un agente especializado empieza a aportar valor cuando no podemos saber de antemano qué recorrido tendrá que seguir en cada caso.
Qué muestran dos casos AEC reales
Esta distinción no es solo conceptual. Dos trabajos recientes en AEC ayudan a ver dónde aparece el valor de la agencia y, al mismo tiempo, dónde deben mantenerse los límites.
Meng, Tong y Zhao (2026) desarrollan un framework agentic que transforma bocetos de cerchas en documentación orientada a fabricación.
Lo relevante no es la tarea concreta, sino la arquitectura: el sistema resuelve ambigüedades, incorpora validaciones de ingeniería, mitiga errores, recupera la tarea cuando algo falla y mantiene checkpoints humanos. La agencia aporta porque el recorrido no es completamente fijo, pero no se elimina el control profesional.
Speiser et al. (2026) presentan un sistema multiagente para preparar evaluaciones de riesgo en seguridad de construcción combinando LLM y grafos de conocimiento.
El sistema estructura y genera borradores, pero conserva evaluación experta y se presenta como investigación/prototipo con límites de integración y escalabilidad. Una arquitectura multiagente sofisticada no equivale, por sí sola, a estar preparada para operar sin supervisión.
Son trabajos de investigación reciente y no prueban una adopción comercial generalizada. Sí muestran algo relevante para esta decisión: flexibilidad, recuperación y control humano pueden formar parte del mismo diseño agentic.
Un mismo proyecto, tres decisiones distintas sobre la autonomía
La diferencia se entiende mejor con un ejemplo corriente.
Imaginemos que durante el desarrollo de una vivienda el cliente pide cambiar la distribución de una zona. El cambio parece pequeño, pero puede afectar a superficies, instalaciones, carpinterías, mediciones, memoria o decisiones anteriores.
Si quiero saber qué repercusiones puede tener, puedo abrir el chat del Proyecto y preguntar. La IA consulta el contexto disponible y me ayuda a analizarlo. El arquitecto inicia la consulta, dirige la conversación y decide cuándo necesita profundizar.
Si lo que quiero es revisar el proyecto completo antes de entregar, puedo definir un workflow de revisión y ejecutarlo en Work con un protocolo establecido: comprobar coherencia documental, superficies, referencias, nomenclaturas, correspondencia entre memoria y planos, mediciones y otras verificaciones definidas por el estudio.
El recorrido es amplio, pero conocido. Work sigue siendo un agente; lo predefinido aquí es la arquitectura del proceso profesional, no la naturaleza del producto que lo ejecuta.
Configurar un agente especializado empieza a tener sentido en otro tipo de situación: cuando quiero que el sistema mantenga el seguimiento de cambios, decisiones y pendientes del proyecto y pueda reaccionar de manera diferente según lo que vaya encontrando.
Por ejemplo, entra nueva documentación o una decisión del cliente. El sistema identifica a qué asunto corresponde, recupera antecedentes, detecta que el cambio puede afectar a instalaciones, decide consultar determinada documentación, encuentra una incompatibilidad, comprueba si existe una decisión previa relacionada y prepara los puntos que requieren revisión del responsable del proyecto.
No hemos fijado toda esa secuencia de antemano. El sistema decide el recorrido dentro de un marco definido. Esa capacidad de elegir qué hacer a continuación es la que empieza a justificar configurar un agente dedicado al seguimiento.
El caso más interesante para un agente especializado: seguimiento de cambios, decisiones y pendientes
Para un estudio pequeño o mediano, este me parece uno de los casos más relevantes.
Un proyecto no avanza como una cadena limpia de tareas. La información llega por múltiples vías y momentos: reuniones, correos, documentación de colaboradores, decisiones del cliente, incidencias, modificaciones de planos o consultas internas. Parte de la carga profesional consiste en mantener mentalmente las relaciones entre todo ello.
Un chat del proyecto puede responder muy bien cuando preguntamos "¿qué quedó pendiente con instalaciones?" o "¿qué decisiones afectan a esta zona?". Pero sigue siendo una herramienta reactiva: alguien tiene que recordar que debe hacer la pregunta.
Un agente especializado puede asumir una función distinta. Puede observar nueva información dentro de las fuentes autorizadas, relacionarla con el contexto existente y decidir si hace falta alguna comprobación adicional.
A partir de ahí puede preparar tareas, señalar contradicciones, agrupar asuntos relacionados o pedir una validación cuando llega a un punto que no debe resolver por sí mismo.
El valor no está en redactar mejor. Está en reducir la necesidad de que el arquitecto dirija manualmente cada paso de la investigación.
Esto no significa darle libertad total. Para un estudio de arquitectura, el punto de partida razonable sería que el agente pueda leer, relacionar, investigar y proponer. Las acciones con impacto técnico, contractual o externo deberían requerir aprobación.
La segunda prueba: ¿puedes acotar lo que el agente puede hacer?
Necesitar flexibilidad no basta. Un proceso también tiene que ser gobernable.
Antes de convertirlo en un proceso gestionado por un agente especializado conviene poder responder con claridad a varias cuestiones.
Resultado y criterio de aceptación
El agente especializado debe tener una misión concreta. "Ayudar con el proyecto" no es suficiente. "Mantener el seguimiento de cambios, decisiones y pendientes y preparar para revisión los posibles impactos" sí empieza a ser operable.
También necesitamos saber qué aspecto tiene un resultado aceptable. Si no podemos describirlo, tampoco podremos evaluar si el agente está funcionando.
Fuentes, herramientas y permisos
Hay que definir qué documentación puede consultar, qué sistemas puede utilizar y qué acciones tiene autorizadas.
No es lo mismo permitir que lea actas y planos que permitirle enviar una respuesta a un cliente, cambiar documentación del proyecto o actualizar un sistema de gestión. La autonomía debe crecer de forma proporcional al riesgo.
Esta cuestión es especialmente relevante porque los agentes pueden acceder a datos, aplicaciones y herramientas. NIST está trabajando actualmente en estándares y controles relacionados con identidad, autorización, seguridad y evaluación de agentes. Para un estudio, la traducción práctica es sencilla: un agente útil no necesita acceso ilimitado; necesita los permisos mínimos suficientes para hacer bien su trabajo.
Aprobación, escalado y responsabilidad
También debe estar claro cuándo tiene que detenerse.
Un agente que analiza una modificación de distribución puede investigar qué documentación se ve afectada. Pero si encuentra una posible incidencia de cumplimiento normativo, una decisión técnica o una comunicación contractual, debe escalarla al profesional responsable.
El agente puede ampliar la capacidad de análisis del estudio. No cambia quién responde profesionalmente del proyecto.
Qué debe pasar cuando algo sale mal
Esta es otra diferencia importante entre una demostración y un proceso profesional.
Un agente va a encontrarse con documentación incompleta, versiones contradictorias, archivos que no puede interpretar o situaciones que no encajan en las instrucciones previstas. El diseño del sistema tiene que contemplar esos escenarios.
¿Qué hace si no encuentra la fuente que necesita? ¿Cómo identifica que dos documentos pueden pertenecer a versiones diferentes? ¿Cuándo deja de seguir investigando y pide ayuda? ¿Cómo sabemos qué ha consultado para llegar a una conclusión?
La capacidad de detenerse, explicar la incertidumbre y escalar el problema es más importante que aparentar autonomía.
No hay un único salto de autonomía
Conviene evitar una visión binaria: o workflow o agente autónomo.
En la práctica podemos avanzar por niveles.
Primero, un sistema puede limitarse a leer y proponer. Después puede preparar acciones para que una persona las apruebe. Más adelante, cuando el proceso se ha probado suficientemente, determinadas acciones de bajo riesgo pueden ejecutarse dentro de límites claros.
En el seguimiento de un proyecto, por ejemplo, el agente podría empezar identificando cambios y proponiendo tareas. En una fase posterior podría crear esas tareas automáticamente, pero seguir necesitando aprobación para modificar documentación o comunicarse externamente.
El nivel adecuado no es el más avanzado. Es el mínimo nivel de autonomía que elimina trabajo de coordinación sin trasladar al sistema decisiones que deben seguir siendo profesionales.
Cómo decidir: consulta puntual, workflow o agente especializado
Una regla práctica puede ayudar.
Si la necesidad aparece de forma puntual y el arquitecto sabe qué quiere preguntar, probablemente basta con el chat del proyecto.
Si la tarea es recurrente y compleja, pero podemos definir por adelantado los pasos, los controles y la salida, probablemente conviene diseñar un workflow. La revisión completa previa a una entrega es un buen ejemplo.
Ese workflow puede ejecutarse con Work. Work es un agente, pero aquí se utiliza para llevar a cabo un procedimiento profesional acotado, sin necesidad de configurar un agente especializado dedicado a esa función.
Si el proceso es recurrente pero cada caso obliga a decidir qué información consultar, qué herramienta utilizar o cuál debe ser el siguiente paso, empieza a tener sentido configurar un agente especializado.
El seguimiento de cambios, decisiones y pendientes es un ejemplo especialmente claro porque la secuencia depende continuamente de lo que ocurre en el proyecto.
Y todavía falta una última condición: esa capacidad de decisión debe poder mantenerse dentro de límites. Si no podemos definir fuentes, permisos, criterios de aceptación, puntos de aprobación y escalado, el proceso todavía no está preparado para recibir más autonomía.
En un artículo anterior sobre agentes de IA para arquitectos defendía que los agentes no deberían entrar por la puerta de la promesa tecnológica, sino por la del proceso. El siguiente paso es precisar algo más: ni siquiera un proceso bien definido necesita necesariamente convertirse en agente.
A veces la mejor solución será una consulta con buen contexto. Otras, un workflow ejecutado de principio a fin, incluso mediante una herramienta agentic. Y solo cuando el valor dependa de que el sistema pueda decidir dinámicamente cómo avanzar compensa configurar un agente especializado para ese proceso.
La pregunta, por tanto, no es "¿podemos convertir este proceso en un agente?". Es más exigente: "¿qué autonomía necesita realmente este proceso para funcionar mejor y qué parte estamos preparados para delegar sin perder control profesional?".