Construir agentes no es generar prompts
El humano co-diseña cuando las decisiones aún son baratas de cambiar; no se limita a aprobar un agente terminado.
El problema de crear directamente desde una descripción
Una descripción en lenguaje natural es un buen punto de partida, pero una mala fuente única de verdad. Puede expresar la intención y, al mismo tiempo, omitir las fuentes disponibles, los criterios de calidad, las herramientas, el riesgo o las decisiones que deben seguir en manos humanas.
Pasar directamente de esa descripción a un conjunto de prompts produce varios problemas:
- la intención no se valida antes de gastar recursos en generación;
- las decisiones inferidas quedan mezcladas con las explícitas;
- los artefactos pueden contradecirse entre sí;
- la evaluación aparece tarde o se limita a una demostración favorable;
- el usuario solo puede aceptar o rechazar el resultado completo;
- la evolución posterior pierde la procedencia del diseño inicial.
La creación necesita un proceso propio. No es un modo más del runtime que ejecuta agentes, del mismo modo que compilar un programa no es una variante de ejecutarlo.
Un ciclo de vida, no una generación
Distintos proveedores y equipos han utilizado la expresión Agent Development Lifecycle para describir procesos con nombres diferentes pero una estructura semejante: identificar una oportunidad, diseñar, construir, evaluar, desplegar, observar y mejorar. No existe una única norma universal denominada ADLC; se trata de una convergencia de prácticas.
En ALLAN, Agent Forge organiza esa convergencia en cinco etapas:
| Etapa | Pregunta principal | Evidencia que debe quedar |
|---|---|---|
| Intake | ¿Existe un trabajo suficientemente definido y merece una capacidad nueva? | Decisión de continuar, reformular o reutilizar. |
| Comprensión | ¿Qué propósito, contexto, herramientas, evaluaciones y límites se deducen del brief? | Contrato intermedio y supuestos visibles. |
| Generación | ¿Qué artefactos declarativos materializan ese contrato? | Bundle coherente y trazable. |
| Validación | ¿Los artefactos cubren el trabajo y respetan sus límites? | Resultados de validación y evaluación. |
| Entrega | ¿Cómo entra la versión en un ciclo de gobierno posterior? | Versión identificable y registro de la entrega. |
El ciclo no termina en la entrega. El uso real genera evidencia para revisar la capacidad, pero esa mejora pertenece a otro proceso: crear y operar son responsabilidades relacionadas, no intercambiables.
El gate temprano: quizá no haya que crear otro agente
La comprobación de preparación debe ocurrir antes de las fases costosas. El brief se contrasta con el catálogo disponible y con el resultado esperado:
- ¿ya existe una capacidad que realiza ese trabajo?;
- ¿conviene revisar una versión existente?;
- ¿la necesidad es estable o solo una tarea puntual?;
- ¿una automatización determinista sería suficiente?;
- ¿existe una señal observable de utilidad?
El resultado legítimo puede ser no crear, combinar o reformular. Un sistema de creación que siempre produce un agente optimiza la actividad de la fábrica, no el valor para la organización.
El contrato intermedio
La fase de comprensión no debería entregar texto suelto a la generación. Debe producir un contrato intermedio inmutable: el blueprint del agente.
El blueprint reúne:
- descripción original y propuesta enriquecida, conservando la diferencia;
- taxonomía funcional;
- flujos y evaluaciones propuestos;
- perfil de herramientas y permisos;
- perfil de riesgo y autonomía;
- caso de uso y señales de éxito;
- supuestos aplicados sin confirmación humana.
Extracto. Cada generador recibe el mismo contrato de solo lectura y produce únicamente el artefacto que le corresponde. La concurrencia deja de ser una improvisación y pasa a ser una propiedad del diseño.
La inmutabilidad permite versionar las decisiones. Cuando una persona corrige una herramienta, una evaluación o un límite de autonomía, no se sobrescribe el pasado: se crea una nueva versión del blueprint.
Generación paralela, validación conjunta
Los artefactos que definen un agente tienen dependencias comunes, pero muchos pueden elaborarse en paralelo si comparten el mismo blueprint: constitución, manifiesto, flujos, skills, evaluaciones y metadatos de interoperabilidad.
El paralelismo reduce la latencia acumulada, aunque aumenta la concurrencia y por tanto debe respetar presupuestos. Su ventaja más importante no es la velocidad: obliga a separar el contrato compartido de los resultados independientes.
La validación vuelve a reunir esos resultados:
- ¿los flujos cubren las tareas declaradas?;
- ¿las evaluaciones cubren los criterios de calidad?;
- ¿las herramientas existen y están autorizadas?;
- ¿la política de riesgo coincide con el margen de actuación?;
- ¿el agente puede superar escenarios mínimos sin romper sus límites?
Una evaluación no es un adorno informativo. Cuando define una condición de entrega, actúa como gate. Esto no convierte al evaluador en una garantía de calidad absoluta: los evaluadores automáticos también requieren calibración, casos adversariales y revisión humana.
Co-diseño humano
En modo interactivo, la comprensión puede detenerse y presentar las decisiones estructurales cuando aún son baratas de cambiar. La persona confirma, edita o responde; el contrato se versiona y el proceso continúa.
En un modo no interactivo, las ambigüedades deben resolverse mediante valores predeterminados conservadores y quedar registradas como supuestos. Una inferencia no confirmada no debe hacerse pasar por una decisión del usuario.
También la reescritura de la descripción debe ser visible y reversible. El texto enriquecido es una propuesta; no sustituye silenciosamente al original.
La autonomía se gana después de nacer
La creación puede producir agentes asistidos o supervisados. Un agente asistido analiza y propone; uno supervisado puede utilizar herramientas dentro de una política que conserva puntos de aprobación.
El nivel autónomo no debería ser una opción de nacimiento. Es una promoción posterior basada en evidencia acumulada: resultados de evaluación, historial de uso, incidentes, estabilidad de herramientas y aceptación del riesgo.
Esta regla evita que «autónomo» funcione como una descripción aspiracional. La autonomía se trata como una decisión de gobierno revisable. Es un guardarraíl adoptado por ALLAN, no una ley universal sobre el ciclo de vida de los agentes.
Interoperabilidad desde el origen
La interoperabilidad no consiste únicamente en exponer una API. Un agente debe poder declarar capacidades, modalidades de intercambio y contratos de descubrimiento sin revelar su memoria o sus herramientas internas.
El protocolo A2A define un modelo abierto para descubrir capacidades y gestionar tareas entre agentes opacos. MCP define una frontera para exponer herramientas y contexto a modelos y aplicaciones. Son problemas relacionados, pero no equivalentes: uno organiza interacción agente-agente; el otro, acceso a capacidades externas.
Los artefactos de interoperabilidad deben derivarse del mismo blueprint que el resto del agente. Añadirlos manualmente después favorece la deriva entre lo que el agente declara y lo que realmente puede hacer.
Estado y límites
Las etapas principales de Forge cuentan con implementación y pruebas en la revisión examinada de ALLAN. Permanecen en evolución la activación completa en la experiencia de usuario, determinados controles comerciales, la validación contra esquemas oficiales de interoperabilidad y el ciclo exterior basado en evidencia operativa.
Por ello, este texto publica el modelo de creación y sus invariantes, no una afirmación de disponibilidad total. Tampoco sostiene que un proceso estructurado elimine la incertidumbre propia de los modelos: la hace observable y gobernable.
Referencias
Fuentes editoriales de ALLAN
Platform Server/docs/agent-forge-design.md.- Planes de implementación asociados, utilizados únicamente para contrastar el estado y no como material publicable.
Fuentes externas
- OpenAI, A practical guide to building agents, guía técnica, consultada en 2026.
- IBM, What is the agent development lifecycle?, publicación técnica de proveedor, consultada en 2026.
- Salesforce Architects, The Agent Development Lifecycle, guía de arquitectura, consultada en 2026.
- NIST, Artificial Intelligence Risk Management Framework 1.0, 2023.
- A2A Project, Agent2Agent Protocol Specification 1.0.0, especificación oficial.
- Model Context Protocol, Specification 2025-11-25, especificación oficial estable consultada en 2026.