En las últimas entregas de esta serie hemos ido montando, pieza a pieza, un sistema de desarrollo agéntico para Business Central: instrucciones, skills y prompts. Cada una de esas piezas resuelve una parte del problema, pero todas comparten una limitación: hay que invocarlas nosotros, una a una, cada vez que las necesitamos.
Hoy damos el siguiente paso. ¿Qué pasa cuando todas esas piezas se juntan bajo un rol con memoria propia, capaz de decidir qué necesita usar en cada momento? Eso es un agente, y es justo lo que vamos a ver en este artículo: cómo crear el primer agente de nuestro flujo de desarrollo AL, un consultor de requisitos, y cómo lo conectamos con un segundo agente arquitecto mediante un mecanismo de traspaso de trabajo (handoff).
 |
Prompt vs. agente: la diferencia que lo cambia todo
Un prompt es una instrucción de un solo uso: se invoca, responde y termina. Hace exactamente lo que el texto pide, una única vez.
Un agente, en cambio, es un rol persistente con identidad propia. Tiene herramientas limitadas a lo que le corresponde hacer —si es un agente desarrollador, hará tareas de desarrollo; si es un agente consultor, hará tareas de consultoría— y sigue un flujo de estados a medida que avanza en su trabajo.
La diferencia clave está en el comportamiento:
- Un agente se niega a hacer lo que no le toca. Si una tarea no forma parte de su rol, no la ejecuta.
- Un agente sabe cuándo debe pasar el trabajo a otro agente, en lugar de intentar resolverlo todo él mismo.
En resumen: un prompt responde una pregunta puntual; un agente sostiene una conversación con reglas propias, sabe decir "esto no me corresponde" y sabe a quién entregarle el testigo cuando termina su parte.
La anatomía de un agente
Un agente se define mediante un conjunto de propiedades que determinan quién es, qué puede hacer y cuándo debe ceder el paso a otro.
Nombre y descripción. El nombre identifica al agente (por ejemplo, Business Central Requirements Consultant) y la descripción resume su propósito: en este caso, un agente de consultoría orientado a levantar requisitos funcionales.
Tools (herramientas). Aquí se define a qué puede acceder el agente: lectura y edición de ficheros, búsqueda de información, conexión a servidores MCP concretos, etc. Este control es más potente de lo que parece a primera vista: se puede, por ejemplo, restringir a un agente para que solo pueda crear ficheros nuevos y nunca modificar código ya existente. Cuanto más estricto sea el conjunto de herramientas, más predecible y seguro es el comportamiento del agente.
Modelo. Cada agente puede usar un modelo de IA distinto según la exigencia de su tarea. Un agente que redacta documentación funcional puede funcionar perfectamente con un modelo más ligero, mientras que un agente arquitecto, que debe razonar sobre estructuras técnicas complejas, puede necesitar un modelo más potente. Esta separación no solo mejora los resultados: también ahorra tokens, porque no usamos el modelo más caro para tareas que no lo requieren.
Handoff. Es la propiedad que no habíamos visto hasta ahora en instrucciones ni en prompts sueltos: define a quién se le entrega el trabajo cuando el agente termina su parte. En nuestro caso, el agente consultor, al finalizar la especificación funcional, hace un handoff automático al agente arquitecto, indicándole que debe generar la especificación técnica a partir de lo que el consultor ha dejado listo.
El agente consultor de requisitos
Además de las propiedades anteriores, el agente consultor incorpora una descripción de comportamiento detallada:
- Rol: actuar como consultor funcional, nunca como técnico. No debe mencionar nombres de objetos, tablas ni estructuras de datos — eso es responsabilidad del arquitecto.
- Principio rector: no inventar. Si algo no está claro, preguntar. El agente debe generar todas las preguntas necesarias para dejar la funcionalidad completamente definida antes de avanzar.
- Flujo de trabajo: leer lo que ha trasladado el cliente, preguntar si falta información, identificar los gaps funcionales que necesitan aclaración y, con todo resuelto, generar el documento de especificación.
- Formato del documento: un nombre corto y legible, estado inicial "borrador" (pendiente de validar con el cliente), un resumen de la necesidad, una sección de preguntas abiertas y una sección de "fuera de alcance".
- Punto de control humano: el flujo se detiene en un paso concreto para esperar validación humana antes de dar la especificación por cerrada — es la pieza de human-in-the-loop que ya vimos en el patrón de prompts, ahora integrada dentro del comportamiento del agente.
- Límites explícitos: el agente tiene prohibido proponer soluciones técnicas, saltarse ambigüedades o decidir por su cuenta qué tablas se van a usar. Su única responsabilidad es entregar una definición funcional completa y correcta.
Estos agentes se guardan en una carpeta .github/agents, siguiendo la misma organización que ya usamos para skills y prompts. En este caso, guardamos dos: el consultor y el arquitecto.
Cómo se invoca un agente en Copilot
Hasta ahora, en Copilot Chat trabajábamos con el modo agente genérico, o invocando prompts sueltos con /. Al definir agentes propios, estos aparecen directamente en el selector de modo, junto a las opciones habituales de agent, ask y plan. En nuestro caso, aparecen ahí el Requirements Consultant y el Solution Architect.
Seleccionar uno de estos agentes cambia el comportamiento de toda la conversación: a partir de ese momento, todo lo que escribamos pasa primero por las reglas de ese agente, en lugar de tener que invocar manualmente un prompt o una skill cada vez.
Un caso real: reservas de equipos en RentalFlow
Para ver el agente en acción, partimos de un caso concreto. El cliente de la extensión —una empresa que alquila maquinaria y equipos, como excavadoras— gestiona sus equipos mediante fichas con información como el estado (alquilado, disponible, en mantenimiento). El cliente envía un correo pidiendo una funcionalidad nueva: poder reservar equipos con antelación, además de alquilarlos directamente, incluyendo la posibilidad de cancelar una reserva.
Ese correo, copiado tal cual, es el único input que se le pasa al agente consultor. No hace falta indicarle qué prompt usar ni qué skill invocar: el propio rol del agente ya sabe qué hacer con esa información.
El resultado es una especificación en estado borrador que resume lo entendido y, sobre todo, plantea las preguntas funcionales que un consultor senior le haría al cliente antes de dar nada por cerrado: ¿puede reservarse un equipo aunque esté actualmente alquilado?, ¿hay que registrar el motivo de una cancelación?, ¿existe un límite máximo de antelación para reservar? Son exactamente el tipo de preguntas que un consultor haría en una reunión de levantamiento de requisitos, y que aquí quedan explícitas y documentadas antes de tocar una sola línea de código.
Con las respuestas incorporadas, el agente vuelve a generar la especificación, ahora sin preguntas abiertas, y la guarda como fichero en el estado "ready for architecture" — lista para el siguiente paso del flujo. Ese documento es, en la práctica, el contrato funcional que se presentaría al cliente para validar antes de empezar el desarrollo: sin tablas, sin objetos, sin nada técnico, solo la funcionalidad acordada.
El handoff en acción: del consultor al arquitecto
Aquí es donde se ve el valor real de la propiedad de handoff. El agente consultor tiene definido en su configuración a quién debe entregar el trabajo al terminar: el agente arquitecto. Ese handoff no es solo una indicación genérica, sino un prompt concreto que se dispara automáticamente: generar la documentación técnica a partir de la especificación funcional recién creada.
Esto demuestra que este enfoque agéntico no es solo una herramienta para desarrolladores: sirve igual de bien para el rol de consultor, ayudando a formular las preguntas que a veces se nos pueden pasar por alto, y dejando un rastro documental claro de cada decisión funcional antes de pasar a la parte técnica.
Qué sigue
Con la especificación funcional cerrada y entregada al agente arquitecto, el siguiente paso natural es ver cómo esa especificación funcional se transforma en una especificación técnica, y cómo esa especificación técnica alimenta después el desarrollo real en AL. Ese será el contenido del próximo vídeo de la serie.
De momento puedes ver el video aquí:
No hay comentarios:
Publicar un comentario