Dentro de IBM Bob: agentes, subagentes y el nuevo modelo de desarrollo de software

Cuando el trabajo deja de ser una conversación lineal, la arquitectura del contexto y la delegación se convierten en parte del diseño del sistema.

De pedir código a delegar trabajo

En un asistente tradicional, el usuario formula una pregunta y recibe una respuesta. En un sistema agéntico, la unidad fundamental cambia: el usuario entrega un objetivo y el sistema organiza trabajo. Para conseguirlo necesita memoria de la tarea, herramientas, permisos y capacidad de dividir un problema en partes.
IBM Bob incorpora subagentes precisamente para realizar tareas enfocadas en contextos separados. Según su documentación, un subagente se ejecuta con su propia ventana de contexto, recibe una tarea acotada y devuelve un resumen al agente principal. Esta separación evita llenar la conversación central con grandes cantidades de información irrelevante y permite especialización.

Figura 3. Patrón conceptual de coordinación entre intención, agente principal, subagentes y herramientas. Elaboración CPS.

Agente, subagente, skill, tool y harness: no son lo mismo

La herencia watsonx dentro del harness: elegir el modelo por tarea

Una arquitectura agéntica no debería asumir que todas las tareas requieren el mismo modelo. Analizar una arquitectura, completar una edición local, clasificar un ticket o revisar una vulnerabilidad tienen perfiles diferentes de costo, latencia y razonamiento. Bob incorpora precisamente esta idea mediante orquestación multimodelo: la plataforma decide qué modelo resulta adecuado para una tarea, en lugar de obligar al desarrollador a administrar manualmente proveedores, versiones y tokens.
Para un Arquitecto de IA, esto cambia el diseño del harness. El “modelo” deja de ser el centro fijo del sistema y se vuelve un recurso intercambiable detrás de una política de enrutamiento. Lo estable deben ser la intención, las reglas, las herramientas, la evidencia y los criterios de aceptación. Bob puede recurrir a Granite, Claude, Mistral u otros modelos especializados; el proceso de ingeniería debe seguir siendo coherente aunque cambie el motor que resuelve una subtarea.
Esta es una lección especialmente útil para organizaciones que ya trabajaron con Watson o watsonx: el valor acumulado no está únicamente en un modelo concreto, sino en haber desarrollado contexto empresarial, reglas, integraciones y gobierno que pueden reutilizarse al pasar a una arquitectura más agéntica.

Por qué el aislamiento de contexto importa

En nuestros ejercicios con arquitecturas multiagente —por ejemplo, separar funciones de PMO y Contraloría— una lección aparece rápidamente: compartir todo con todos no mejora necesariamente la calidad. Aumenta el ruido, mezcla responsabilidades y consume contexto. Es preferible que el agente principal entregue a cada subagente exactamente lo necesario y reciba de regreso un artefacto o resumen que pueda integrar.
Bob documenta dos tipos de subagentes: Explore, orientado a exploración de codebase en solo lectura, y General, con acceso completo a herramientas para trabajos autónomos. Conceptualmente, la diferencia refleja un principio de mínimo privilegio: no toda investigación necesita permisos de escritura o ejecución.

Un ejemplo: implementar una nueva API

Supongamos que un equipo necesita incorporar un endpoint para registrar una operación sensible. En un enfoque agéntico, el trabajo podría organizarse así:

1. El agente principal interpreta la historia y sus criterios de aceptación.
2. Un subagente Explore localiza controladores, modelos, convenciones de validación y pruebas existentes.
3. El modo Plan propone cambios, dependencias y riesgos.
4. Tras la aprobación, Agent modifica los archivos necesarios.
5. Una skill de seguridad verifica controles mínimos: validación de entrada, gestión de secretos y logging.
6. Se ejecutan pruebas y análisis estático; los resultados regresan al agente principal.
7. El humano revisa el diff y decide si el cambio continúa hacia el pipeline.

Lo relevante no es si esta secuencia exacta ocurre siempre de forma automática. Lo importante es que el trabajo puede diseñarse como un proceso explícito, con límites, entradas y salidas verificables.

El repositorio debe contener más que código

Los agentes funcionan mejor cuando pueden encontrar decisiones y reglas cerca del trabajo. Por eso la documentación arquitectónica, los ADR, estándares de seguridad, convenciones de nombres, Definition of Done y ejemplos de referencia dejan de ser “documentación administrativa” y se vuelven contexto operativo.
Esta idea conecta con algo que hemos aplicado en otros dominios: una IA puede ser muy capaz, pero si la organización no formaliza sus reglas, el agente termina adivinándolas. La calidad de la automatización depende de la calidad del conocimiento institucional disponible.

El papel del Arquitecto de IA

• Diseñar qué información entra al contexto y qué información queda fuera.
• Definir fronteras entre agente principal y subagentes.
• Convertir prácticas repetibles en skills.
• Asignar tools y permisos bajo mínimo privilegio.
• Definir gates de aprobación y evidencia.
• Medir no sólo velocidad, sino calidad, riesgo y retrabajo.

Conclusión

Bob permite observar el desarrollo de software como una red de trabajo especializada. El IDE deja de ser sólo un editor y se acerca a un entorno de coordinación. Esa evolución abre oportunidades importantes, pero obliga a diseñar con rigor el contexto, la delegación y los permisos. La arquitectura agéntica es, en esencia, arquitectura de responsabilidades.

Diseña tu primer flujo agéntico

CPS puede tomar un caso de uso real —una API, una modernización, documentación o pruebas— y convertirlo en un flujo reproducible con roles, skills, herramientas, aprobaciones y métricas.
Solicita un workshop de diseño de agentes y subagentes para desarrollo.