Un asistente de IA puede ayudarte a escribir código, generar pruebas y revisar documentación. Sin embargo, pedirle que haga todo a la vez no siempre es la mejor estrategia. Cuando una tarea exige criterios claros y verificaciones distintas, puede ser útil distribuir el trabajo entre agentes especializados.
La idea no es crear más agentes por crear. Es asignar responsabilidades concretas, proporcionar el contexto adecuado y establecer cómo se revisan los resultados.
Estas son cinco cosas que conviene entender antes de incorporar agentes especializados a un proyecto de software.
1. Un agente especializado tiene una responsabilidad definida
Un agente especializado es un sistema de IA configurado para atender una clase de tareas. Puede utilizar un modelo de lenguaje, instrucciones específicas, contexto, herramientas y reglas de ejecución.
Por ejemplo, un agente revisor podría recibir el objetivo de evaluar cambios de código, identificar riesgos de seguridad y señalar problemas de mantenibilidad. Su trabajo no sería implementar toda la funcionalidad, sino revisar lo que otro componente produjo.
No necesitas entrenar un modelo desde cero para especializarlo. En muchos casos, la especialización surge de cómo se configura el agente y de los recursos que tiene disponibles. Eso tampoco lo convierte automáticamente en experto ni garantiza que todas sus observaciones sean correctas.
2. La especialización permite separar criterios de trabajo
En un proyecto puedes definir responsabilidades distintas:
- Developer: implementa cambios a partir de una tarea y sus criterios de aceptación.
- Reviewer: examina calidad, legibilidad, diseño y posibles problemas de seguridad.
- QA: prepara o ejecuta comprobaciones para detectar fallos.
Cada responsabilidad requiere información y criterios diferentes. Un agente que escribe código prioriza cumplir el comportamiento solicitado; un revisor busca defectos y decisiones discutibles; uno de QA intenta comprobar que el resultado se comporta como se espera.
Separar funciones puede mejorar la claridad del proceso, pero también añade coordinación, tiempo de ejecución y consumo de recursos. Para una corrección pequeña, un solo agente con una revisión humana puede ser suficiente.
3. Más contexto no siempre significa mejores resultados
Un error común es entregar el repositorio completo y todas las conversaciones a cada agente. Eso puede introducir información irrelevante, aumentar el costo y dificultar que identifique lo importante.
Conviene proporcionar el contexto mínimo suficiente para cada tarea: el objetivo, los archivos relevantes, las convenciones del proyecto, las restricciones y una definición clara de lo que se considera terminado.
Por ejemplo, un revisor de una API en .NET necesita comprender el cambio, los contratos afectados, las reglas de seguridad y las pruebas relacionadas. Probablemente no necesita la documentación completa de la aplicación móvil si no guarda relación con la revisión.
El contexto debe ajustarse a la tarea. Si es demasiado limitado, el agente puede pasar por alto dependencias importantes; si es demasiado amplio, puede perder precisión.
4. Las herramientas amplían lo que un agente puede hacer
Un modelo puede sugerir cómo ejecutar una prueba. Un agente con herramientas autorizadas puede, además, invocar el comando correspondiente y examinar el resultado.
Según su configuración, un agente podría:
- Leer archivos y consultar la documentación del repositorio.
- Buscar referencias y analizar diferencias entre versiones.
- Ejecutar pruebas, validaciones estáticas o compilaciones.
- Proponer cambios y preparar un resumen para revisión.
La distinción fundamental es entre proponer una acción y haberla ejecutado realmente. Si el agente afirma que las pruebas pasaron, debe existir evidencia de que se ejecutaron y de cuál fue el resultado.
Las herramientas también representan riesgos. Limita los permisos, protege credenciales y define qué acciones necesitan aprobación humana, especialmente al modificar datos, desplegar software o interactuar con sistemas externos.
5. Varios agentes pueden colaborar, pero necesitan coordinación
Imagina una solicitud: agregar una funcionalidad a una API.
- El agente Developer implementa el cambio.
- El agente Reviewer evalúa el código y devuelve observaciones si encuentra problemas.
- El agente QA comprueba el comportamiento con las pruebas disponibles.
- Si Reviewer o QA encuentran errores, el trabajo vuelve a Developer para hacer correcciones.
- Se repiten las verificaciones pertinentes antes de presentar el resultado a una persona.
Este es un flujo conceptual, no una arquitectura obligatoria. Algunos sistemas ejecutan tareas en paralelo; otros incorporan aprobaciones intermedias. El workflow define el orden y las transiciones; los agentes realizan las tareas que les corresponden.
El estado final del diagrama, «Listo para revisión humana», es deliberado. Que una herramienta no detecte errores no significa que el software sea seguro, completo o apto para producción.
Cómo comenzar sin complicar tu proyecto
No hace falta construir una plataforma multiagente desde el primer día. Para probar el enfoque:
- Elige una tarea repetible, por ejemplo, revisar un pull request.
- Define una sola responsabilidad para el agente.
- Especifica la información que recibirá y el formato de su respuesta.
- Dale acceso únicamente a las herramientas necesarias.
- Establece criterios de aceptación y un punto de revisión humana.
- Compara el resultado con tu proceso actual antes de añadir otros agentes.
Un ejemplo de salida útil para un Reviewer sería un informe con archivo, ubicación, gravedad, motivo y recomendación. Eso permite evaluar hallazgos concretos en lugar de recibir comentarios vagos como «el código puede mejorar».
Errores comunes al diseñar agentes especializados
Confundir especialización con infalibilidad. Tener instrucciones para revisar seguridad no equivale a una auditoría profesional ni elimina los falsos positivos.
Crear un agente para cada paso mínimo. Multiplicar roles puede generar más transferencias de contexto que valor real.
No definir cuándo termina una tarea. Sin criterios de aceptación, los agentes pueden continuar haciendo cambios innecesarios.
Permitir acciones sin controles. Ejecutar comandos o modificar sistemas exige permisos apropiados, registros y límites claros.
Confiar solo en el resumen del agente. Cuando una verificación importa, hay que revisar la evidencia: pruebas ejecutadas, cambios realizados y errores encontrados.
Un caso práctico: añadir un endpoint en .NET
Supongamos que necesitas agregar un endpoint para consultar información de un recurso.
Developer recibe el contrato esperado, las convenciones del proyecto y los archivos relevantes. Implementa el endpoint y deja constancia de sus cambios.
Reviewer contrasta la implementación con los requisitos: validación de entradas, manejo de errores, autorización, consultas a datos y consistencia con el diseño existente. Si encuentra un problema, lo documenta para su corrección.
QA ejecuta las pruebas disponibles y señala qué escenarios se verificaron y cuáles no. Si una prueba falla, el trabajo vuelve a Developer y se repite la validación correspondiente.
El resultado no es «la IA terminó, publica el código». Es una propuesta de cambio acompañada por observaciones y evidencia, lista para revisión humana.
Reflexión final
Los agentes especializados son útiles cuando las responsabilidades están bien definidas y existe una forma de comprobar su trabajo. Su valor no depende del número de agentes, sino de la calidad de las tareas, el contexto, las herramientas y los controles que los rodean.
En el siguiente tema de la serie veremos qué es un AI harness y cómo se relaciona con la ejecución y supervisión de estos procesos.