Desarrollo impulsado por especificaciones con agentes de programación con IA: una guía práctica
Desarrollo guiado por especificaciones con agentes de codificación de IA: un flujo de trabajo de cuatro fases, archivos AGENTS.md y SPEC.md, roles de múltiples agentes, niveles de madurez y cómo detectar desviaciones.
Fuentes: Spec-Driven Development with AI Coding Agents: The Definitive Guide
Herramientas como Claude Code, GitHub Copilot, Cursor y Windsurf ahora generan, reestructuran y prueban código mucho más rápido de lo que cualquier persona podría hacerlo. Sin embargo, la velocidad sin precisión tiende a convertirse en una desventaja. Muchos equipos que utilizan estas herramientas trabajan en un ciclo constante de solicitar información, recibir resultados, corregir errores y volver a solicitar, y este ciclo empeora a medida que crece la base de código. La causa suele no ser el modelo, sino el hecho de que nadie tiene un método disciplinado para indicarle al agente qué se desea obtener.
El desarrollo guiado por especificaciones (SDD) es una solución. Consiste en tratar una especificación estructurada como el producto principal del proceso de entrega: el documento a partir del cual se deriva, se verifica y se gestiona el código.
La base conceptual
Cómo falla el coding por intuición
“Codificación por ambiente” significa describir el resultado deseado de forma conversacional y orientar la salida mediante preguntas informales de seguimiento. Funciona bien para tareas aisladas, prototipos rápidos y experimentos de una sola sesión. Falla gravemente a gran escala, y la razón merece ser comprendida.
Decadencia del contexto
Cada sesión tiene lugar dentro de una ventana de contexto, que representa la cantidad limitada de información sobre la que el agente puede razonar en un momento dado. Durante la codificación por ambiente, el estado del proyecto solo existe dentro del historial de chat. A medida que la conversación se alarga, las decisiones arquitectónicas iniciales, las restricciones de seguridad y las elecciones de bibliotecas quedan fuera de ese marco. El agente entonces sustituye esas opciones por alternativas plausibles, a menudo sin indicarlo. Eso es la decadencia del contexto.
El síntoma típico es la deriva en la implementación: una separación gradual entre lo que el agente cree que está construyendo y lo que la empresa solicitó originalmente. El código pasa sus pruebas, funciona por sí solo y parece correcto, pero viola las reglas estructurales o de negocio establecidas anteriormente. En los sistemas empresariales, este es el tipo de defecto más difícil de diagnosticar y más costoso de corregir.
La idea central
SDD se basa en un principio arquitectónico: la especificación es el artefacto principal, y la implementación se deriva de ella. Esto va más allá de un simple ajuste en el flujo de trabajo; invierte el modelo tradicional, en el que el código viene primero y la documentación lo sigue.
En este enfoque, la especificación es legible por máquinas, está controlada por versiones, es dinámica y ejecutable. Funciona como un contrato entre la intención humana y la ejecución del agente, y este trabaja dentro de los límites del contrato en lugar de adivinar. Un contrato preciso genera resultados predecibles, mientras que uno ambiguo produce variaciones. En resumen, no se puede controlar lo que construye un agente hasta que no se haya definido con exactitud qué se desea construir.
Seis elementos de una especificación legible por máquinas
Una especificación destinada a un agente debe superar la ambigüedad del lenguaje natural. Los seis elementos que suelen considerarse necesarios para evitar que el agente haga suposiciones no deseadas son:
- Resultados, los logros que debe alcanzar el trabajo.
- Alcance, incluyendo lo que se deja explícitamente fuera.
El flujo de trabajo de SDD
Cuatro fases con puntos de control humano
El flujo de trabajo consta de cuatro fases secuenciales, y cada una incluye un punto en el que una persona debe intervenir. Estos puntos de control humano no son una burocracia. Evitan que los errores se agraven posteriormente, y saltarse uno para “actuar más rápido” suele tener el efecto contrario.
Fase 1: especificar. El desarrollador expone la intención a nivel general, y ya sea el agente o el propio desarrollador la desarrollan en una especificación funcional estructurada: rutas de usuario, resultados empresariales, criterios de aceptación y límites claros del alcance. La tarea de esta persona consiste en realizar una revisión arquitectónica, analizando el resultado en busca de alucinaciones, omisiones y interpretaciones erróneas antes de comenzar cualquier planificación. Debe posponerse la fase 2 hasta que la fase 1 esté libre de ambigüedades: una especificación vaga rara vez conduce a una implementación vaga, sino a una que es segura de sí misma pero incorrecta.
Fase 2, plan. Una vez aprobada la especificación, el agente elabora un plan técnico que abarca las decisiones arquitectónicas, los modelos de datos, los contratos de API y las elecciones tecnológicas. El plan incluye restricciones organizativas como “conservar los datos en PostgreSQL” o “cada punto de extremo de API requiere autenticación JWT”. La revisión humana en esta etapa permite detectar errores arquitectónicos antes de que se incluyan en las miles de líneas generadas.
Fase 3, desglose de tareas. El plan aprobado se divide en tareas pequeñas que pueden probarse de forma independiente. La granularidad es probablemente la variable más subestimada en el desarrollo dirigido por pruebas. Una tarea debe poder implementarse y verificarse en una sola ejecución del agente; si obliga al agente a manejar más de tres aspectos distintos, es demasiado grande. Una lista bien dividida también sirve como estructura de apoyo para el desarrollo dirigido por pruebas, ya que cada tarea cuenta con una condición de éxito clara antes de comenzar el trabajo y el proyecto dispone de puntos de validación frecuentes.
Fase 4, implementar y verificar. El agente escribe el código tarea por tarea, generando resultados específicos que pueden auditarse y relacionarse con un requisito concreto. Esta fase se combina con un patrón de verificador, en el que un agente genera el código mientras que otro agente o un conjunto de pruebas automatizadas lo comprueban en relación con los criterios de aceptación.
Actualización de la especificación en ambas direcciones
Una de las prácticas más importantes, y que a menudo se incumple, es la actualización bidireccional. Supongamos que durante la fase 4 el agente toma una decisión que la especificación no abarca, como elegir una biblioteca por razones de rendimiento o manejar un caso límite de manera poco evidente. Esa decisión debe escribirse de inmediato de vuelta en la especificación.
Si no es así, se acumula la “deuda de especificaciones”: la intención documentada y el comportamiento real se separan. Esa divergencia convierte una especificación en vigor en un archivo obsoleto en el que nadie confía y, con el tiempo, nadie lo lee, volviéndose inútil justo cuando más se necesita, durante los cambios posteriores asistidos por IA. La regla es simple: cuando la implementación se desvía de la especificación, actualízala ahora, no en el próximo sprint. La deuda de especificaciones crece más rápido que la deuda técnica, ya que contamina el punto de partida de cada generación posterior de ejecuciones.
Artefactos de persistencia y la constitución del proyecto
Por qué los agentes necesitan una constitución
Un agente de programación no tiene memoria entre sesiones. Cada nueva sesión comienza únicamente con lo que se introduce en su contexto. Al no existir mecanismo de persistencia, cada sesión es como una hoja en blanco, sin conocimiento alguno sobre sus estándares de seguridad, convenciones de nomenclatura, bibliotecas prohibidas ni decisiones arquitectónicas.
La “constitución del proyecto” es un conjunto de artefactos persistentes que resuelven este problema. Se trata de archivos estructurados que se guardan en el repositorio junto al código fuente, brindando al agente el conocimiento institucional necesario para actuar como un miembro del equipo informado y no como un externo.
Los artefactos principales
AGENTS.md o CLAUDE.md, el manual de operación. Este es el más importante: un README para el agente, que se lee al inicio de cada sesión para entender cómo funciona este proyecto en particular. Debe estar escrito pensando en su análisis por máquinas antes que en su legibilidad por humanos. Un archivo eficaz contiene tres tipos de información:
- Detalles operativos que el agente no puede deducir: comandos de compilación exactos con flags, cómo se ejecutan las pruebas, configuración del linter y nombres de las variables de entorno.
- Convenciones de nombramiento y estructura: para qué sirve cada directorio, cómo se nombran los archivos y cómo se organizan los módulos.
- Una jerarquía de gravedad para las acciones del agente, que utiliza un sistema de señales consistente. Siempre realice tareas como la detección de errores, ejecución de las pruebas afectadas y cumplimiento de las convenciones de nomenclatura. Pregunte primero antes de modificar los esquemas de la base de datos, agregar dependencias o alterar los contratos de API. Nunca guarde secretos, edite los archivos
.envni modifique la lógica de autenticación sin revisión previa.
SPEC.md, la especificación viva. Esta es la descripción oficial de lo que debe hacer el sistema. No se trata de un registro histórico; refleja el comportamiento deseado actual, incluyendo todas las decisiones tomadas durante la implementación. Si el código difiere de SPEC.md, se actualiza el archivo, y cuando cambian los requisitos, primero se edita SPEC.md y luego la implementación.
PLAN.md, el registro de la arquitectura. Contiene las decisiones arquitectónicas, las elecciones tecnológicas y las restricciones a nivel de todo el sistema. Responde a la pregunta “¿por qué se construyó de esta manera?”, proporcionando la lógica que impide que agentes e ingenieros posteriores anulen decisiones tomadas con cuidado.
Archivos de configuración específicos para herramientas. Cada herramienta tiene su propia convención para los archivos de reglas. Merece mención el formato .mdc de Cursor, ya que combina Markdown con información preliminar en YAML para asociar reglas a patrones de globos de archivos. Las reglas de backend, como los requisitos de autenticación y los patrones de acceso a la base de datos, solo pueden aplicarse cuando el agente trabaja en archivos de backend, evitando que el contexto irrelevante afecte su memoria de trabajo durante el trabajo en el frontend.
Orquestación multiagente
Por qué un solo agente no es suficiente
Un único agente encargado de todo el código de una empresa llega a un límite importante: la ventana de contexto. Un sistema grande con 100,000+ archivos, varios servicios, flujos de datos complejos y un conjunto completo de pruebas no cabe en el contexto de un solo agente. El agente debe decidir qué incluir, y esas decisiones generan puntos ciegos.
La idea detrás de la orquestación multiagente es imitar el funcionamiento de un equipo humano eficaz, con roles definidos, entregas ordenadas y una especificación que todos consideran como la verdad.
Tres roles
Coordinador. Este agente actúa como gerente de proyecto y arquitecto. Posee la visión general del proyecto, es decir, la especificación completa, la lista de tareas y las restricciones arquitectónicas. Divide la especificación en subespecificaciones, las entrega a los implementadores, vigila los conflictos entre los flujos de trabajo paralelos y se asegura de que completar una tarea no dañe la arquitectura en su conjunto.
Implementador. Los implementadores son especialistas. Cada uno recibe una subespecificación que abarca una tarea o un pequeño grupo de tareas relacionadas, y trabaja en un árbol de trabajo de Git aislado para evitar conflictos a nivel de archivos con otros implementadores que trabajan en paralelo. No sabe nada sobre el trabajo fuera de su asignación y no es responsable de él. Ese aislamiento no es una limitación; es lo que hace que el resultado sea determinista, verificable y susceptible de revisión.
Verificador. El verificador tiene un objetivo opuesto. Mientras que el implementador intenta completar la tarea, el verificador busca dónde el resultado no cumple con la especificación. Este enfoque basado en la confrontación proviene de la verificación formal y la investigación en seguridad, y se encuentra entre los mecanismos de calidad más sólidos que ofrece SDD. El verificador examina la salida en relación con los criterios de aceptación y busca deficiencias funcionales, violaciones de las políticas de seguridad, incumplimientos de las restricciones de rendimiento y desviaciones de la especificación. Al encontrar una discrepancia, no corrige el código; en su lugar, informa al coordinador con una descripción estructurada que relaciona el fallo con un requisito específico.
En los sistemas de producción, este verificador adversarial no debería ser opcional. Un agente que escribe y verifica su propio código casi siempre considerará su trabajo aceptable, y el valor del verificador radica en ser independiente del implementador y oponerse a él.
Ejecución paralela con worktrees
Una de las capacidades más valiosas de los SDD multiagente es el paralelismo: varios implementadores trabajando al mismo tiempo en diferentes características o servicios, cada uno en su propio worktree. En proyectos grandes con pocas dependencias entre tareas, el tiempo de entrega puede reducirse drásticamente.
Los worktrees de Git lo hacen posible. Cada agente cuenta con un directorio de trabajo separado vinculado al mismo repositorio, lo que evita conflictos de archivos mientras el coordinador supervisa el progreso de todas las líneas de trabajo desde un único lugar. Una vez que el verificador da su aprobación, el coordinador fusiona los worktrees completados y mantiene el branch principal limpio.
Diagramas como código
Por qué los diagramas deben formar parte de la especificación
Tradicionalmente, los diagramas de arquitectura se han dibujado posteriormente, como documentación del código que ya existe. En el enfoque SDD, ellos se incluyen desde el inicio, como parte de la especificación y el plan, antes de cualquier implementación.
La razón es diagnóstica. Al solicitar a un agente que genere un diagrama Mermaid válido a partir de una especificación, se le obliga a razonar explícitamente sobre el flujo de datos, las dependencias de servicios y las transiciones de estado antes de escribir código. Un diagrama desordenado o incoherente en esta etapa es una señal fiable de que la especificación es ambigua o tiene defectos estructurales, y corregir tales problemas en un diagrama cuesta mucho menos que hacerlo en código ya desplegado.
Formatos
Los formatos basados en texto, especialmente Mermaid y D2, son superiores a las imágenes binarias para este propósito. Se pueden versionar y comparar sus diferencias, y los agentes pueden leerlos directamente. También se pueden actualizar a medida que evoluciona la especificación, lo que mantiene alineada la documentación estructural con la implementación.
Tres niveles de madurez
Los profesionales han establecido tres niveles de SDD. No se trata de una escalera que todo equipo debe subir en orden; son perfiles de compromisos diferentes para contextos distintos, y saber cuál se adapta a su situación es lo primero que se debe considerar antes de cualquier implementación.
Nivel 1: especificación primero. Se elabora una especificación detallada para una tarea concreta. Una vez completada y verificada la implementación, la especificación se considera desechable: se puede conservar como referencia pero no se mantiene. Es adecuada para funcionalidades aisladas, migraciones puntuales y experimentos en los que no resulta justificado el mantenimiento del Nivel 2. Sus defensores afirman que este nivel permite aprovechar aproximadamente el 60% del valor de los SDD a una fracción del costo, lo que lo convierte en un punto de partida sensato para los principiantes. Úselo para una nueva funcionalidad bien delimitada con criterios de aceptación claros, sin dependencias entre servicios y con un plazo de entrega medido en días.
Nivel 2, basado en especificaciones (el valor predeterminado recomendado). La especificación es un socio igual al código a lo largo de toda la vida útil del proyecto, y ambos se mantienen. Cuando cambian los requisitos, primero se modifica la especificación; y cuando la implementación se desvía, la especificación se actualiza de inmediato para registrar el comportamiento real y las razones detrás de él. Esto podría parecer un mantenimiento doble, pero en la práctica reduce el costo total: evita la degradación del contexto a lo largo de las sesiones, permite que los nuevos miembros del equipo (humanos y de IA) se integren de manera fiable, y hace que los cambios posteriores asistidos por IA sean mucho más confiables. Es la base para los sistemas en producción, los proyectos en equipo y cualquier cosa que se espere que siga evolucionando.
Nivel 3, especificación como fuente (experimental). La especificación es el único artefacto principal. El código se trata como salida compilada, se regenera según sea necesario y nunca se edita a mano. Representa el punto final teórico del SDD, donde los ingenieros se encargan de mantener las especificaciones y la IA de las implementaciones. Presenta un problema sin resolver: el determinismo. Especificaciones idénticas pueden generar código sintácticamente diferente, aunque funcionalmente equivalente, de una ejecución a otra, lo que dificulta enormemente las comparaciones, la depuración y la revisión. Considérelo como algo experimental. Puede ser adecuado para proyectos desde cero con especificaciones altamente completas, una sólida gobernanza basada en IA y tolerancia a herramientas inmaduras, pero no se recomienda para sistemas de producción críticos a fecha de 2026.
Guías por rol
Ingenieros y arquitectos
La habilidad principal del ingeniero pasa a ser la ingeniería de contexto. Escribir una sintaxis correcta es algo que los agentes realizan a velocidad máxima, por lo que el valor del ingeniero radica en definir un contexto arquitectónico preciso, seleccionar qué puede ver el agente y verificar que su salida se ajuste a la intención estructural del sistema. Esto incluye crear archivos AGENTS.md y SPEC.md adecuados, establecer reglas de gobernanza para las bibliotecas (una lista explícita de dependencias permitidas y prohibidas), especificar requisitos de seguridad y cumplimiento en un formato legible por máquinas, y estructurar las tareas de modo que las distintas consideraciones permanezcan separadas.
Rutina inicial para los ingenieros:
- Antes de desarrollar cualquier funcionalidad asistida por IA, cree o actualice SPEC.md para que contenga los seis elementos descritos anteriormente.
- Revise AGENTS.md y confirme que los comandos de compilación, los patrones de prueba, las reglas de nomenclatura y la jerarquía de gravedad sigan reflejando la realidad.
Un bloque de restricciones es una plantilla útil para incluir en cualquier especificación. Enumera la pila tecnológica (toda la tecnología requerida), las bibliotecas prohibidas (especificadas por completo), los requisitos de seguridad (cómo se autentican los usuarios, qué tipo de cifrado se espera, cómo se pueden manejar los datos), los límites de rendimiento (latencia y ancho de banda objetivo), los requisitos de pruebas (umbral de cobertura y tipos de pruebas necesarios) y los patrones arquitectónicos (los obligatorios y aquellos que deben evitarse).
Gerentes técnicos de producto
De los PRD a los resúmenes de comportamiento. Un documento clásico de requisitos del producto supone la existencia de ingenieros humanos que lo leerán, discutirán sobre él e implementarán sus decisiones según su propio criterio. En el enfoque SDD, el resultado del TPM debe ser un resumen de comportamiento: una descripción legible por máquinas de cómo el producto debe responder a necesidades específicas del usuario, con la precisión que exigen las operaciones del agente.
La diferencia va más allá del estilo. Un PRD puede decir “mejorar la experiencia de pago”. Un resumen de comportamiento debe especificar qué hace el flujo actual de pago, qué problemas causan a los usuarios, qué cambios de comportamiento se consideran mejoras, cómo se mide el éxito, qué casos límite deben abordarse y qué acciones el sistema nunca debe realizar.
El ciclo del prototipo. SDD permite que un TPM acorte el proceso habitual de transición del diseño a la ingeniería. En lugar de esperar los bocetos de un diseñador y luego que un ingeniero los desarrolle, el TPM puede generar prototipos interactivos directamente a partir de una descripción del comportamiento y evaluar el funcionamiento real en lugar de pantallas estáticas. Si el prototipo no cumple con la visión inicial, se actualiza la especificación y el agente regenera la implementación, de modo que el ciclo de retroalimentación se basa en la especificación y no en el código. Esto elimina varios puntos de traducción (PRD, luego la transición al diseño y luego a la ingeniería) donde normalmente se pierde la intención original.
CTOs y líderes de ingeniería
Gobernanza. La prioridad de un CTO en una organización centrada en agentes es contar con un marco de gobernanza que permita a la IA acelerar la entrega sin comprometer la calidad, la seguridad ni el cumplimiento normativo. SDD proporciona la capa de control, pero solo con disciplina organizativa. Tres mecanismos son clave a gran escala:
- Control de versiones para las especificaciones. SPEC.md, PLAN.md y AGENTS.md se encuentran en el mismo repositorio que el código y pasan por los mismos procesos de revisión y aprobación.
- Rastreo de auditorías. Cada cambio generado por la IA debe poder rastrearse hasta un requisito específico de la especificación, lo cual no es opcional en industrias reguladas.
- Control humano en cada transición de fase. Nada avanza de forma autónoma, desde la especificación hasta la planificación y la implementación, sin aprobación en cada paso.
Los CTO también deben evaluar las herramientas de programación con IA según este marco, preguntándose qué tan bien cada una admite archivos de reglas persistentes, puntos de revisión, trazabilidad y flujos de trabajo multiagente.
Midiendo el retorno. Las organizaciones que adoptan SDD suelen indicar que el desarrollo parece más lento durante las primeras dos a cuatro semanas, ya que los ingenieros dedican tiempo a las especificaciones en lugar de centrarse en el código. La observación es correcta, pero la interpretación es engañosa. El trabajo de especificación no representa una carga adicional nueva; se trata de una tarea que antes se realizaba de forma informal e inconsistente, y después de la implementación, cuando costaba más. Las métricas que muestran el verdadero retorno se encuentran en etapas posteriores:
- el tiempo desde el requisito hasta el código listo para producción, es decir, verificado, revisado e implementado, y no simplemente escrito,
- porcentaje de retrabajo, la proporción de funcionalidades terminadas que deben hacerse de nuevo porque los requisitos no se comprendieron correctamente,
- tiempo de recuperación del contexto, el tiempo que necesita un desarrollador o agente para volver a ser productivo con código que no se ha modificado en 30 días, y
- tasa de escape de defectos, la proporción de defectos detectados durante la revisión de las especificaciones en comparación con los detectados después del despliegue.
Se informa que los equipos con prácticas SDD maduras logran reducir el retrabajo entre un 40% y un 60%, además de disminuir significativamente el tiempo de recuperación del contexto, ya que las especificaciones proporcionan la información necesaria que de otro modo requeriría horas de análisis del código. Estas cifras provienen de informes de profesionales y no de estudios controlados, por lo que debe medir su propio punto de referencia.
Deriva de intenciones
Qué es
El derive de intención es la brecha gradual que se abre entre los requisitos originales del negocio y el comportamiento del código en producción. No es algo nuevo en el trabajo asistido por IA y constituye uno de los problemas más antiguos de la ingeniería de software, pero los agentes de programación añaden un acelerante peligroso. Ellos se optimizan para que el código sea plausible y pase las pruebas, no para que se alinee con los objetivos del negocio. Si se les pide que desarrollen un sistema de procesamiento de pagos, escribirán código que pase todas las pruebas y cubra todos los casos especificados. Si la especificación es incompleta o obsoleta, el agente llena las lagunas con valores predeterminados estadísticamente probables extraídos de sus datos de entrenamiento. Estos valores son adecuados para sistemas genéricos, pero pueden ser desastrosos para las reglas específicas de su negocio. El peor tipo de derive es aquel que solo se detecta cuando causa costos al cliente, una auditoría de cumplimiento o un incidente en producción, ya que los agentes son muy buenos para generar código que parece correcto aunque esté ligeramente erróneo.
Defensas
- Una especificación en tiempo real. La primera defensa consiste en una especificación que se actualiza al instante a medida que se toman decisiones. Cualquier desviación de SPEC.md, por pequeña que sea o por bien justificada que esté, se registra de inmediato, de modo que el archivo describa siempre el comportamiento actual y no la intención original.
- Verificación adversaria. El patrón de verificación también sirve para detectar desviaciones. Al comparar los resultados con la especificación en cada tarea, se detectan las desviaciones en el nivel más mínimo posible, antes de que se agraven a lo largo de varios ciclos de implementación.
- Seguimiento de la cobertura de especificaciones. Las configuraciones más avanzadas registran la proporción de requisitos que cuentan con pruebas automatizables y verificables. Un requisito sin pruebas puede desviarse sin que se note, y trabajar hacia una cobertura total representa el desarrollo guiado por pruebas aplicado a nivel de requisitos.
Un AGENTS.md mínimo
Un AGENTS.md listo para producción puede ser breve. Como mínimo, debe incluir una descripción de un párrafo del proyecto, los comandos exactos para compilar, probar y verificar la sintaxis, las convenciones para nombrar y organizar los directorios, las listas de siempre, primero pregunta y nunca, enlaces a SPEC.md y PLAN.md, y las reglas de gobernanza de la biblioteca. Adapte cada parte a su tecnología y a los requisitos de su organización.
Dónde lo deja esto
El desarrollo basado en especificaciones no es una moda pasajera ni una pequeña mejora en los hábitos existentes. Cambia la naturaleza del trabajo de ingeniería. Con agentes de programación, el cuello de botella en la entrega ya no es la rapidez con la que se genera la sintaxis, sino la precisión con la que se define la intención. La especificación es el producto, el código es lo que la implementa, y en la construcción de software con agentes, la especificación es el resultado más importante del ingeniero.
Leer más
- Notas prácticas: Estoy ejecutando un agente de programación IA localmente y es casi dos veces — Guía paso a paso de las Notas prácticas: Estoy ejecutando un agente de programación IA localmente y es casi dos veces: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
- Ingeniería de agentes en cinco capas: desde especificaciones y agentes paralelos hasta reglas y supervisión — Karpathy habla del cambio respecto al código basado en intuiciones. Conoce las cinco capas de la ingeniería de agentes: especificaciones, orquestación, reglas codificadas, revisión humana y observabilidad, además de un plan semanal.