Práctica de Flujos de Trabajo, Solicitudes HTTP e Integración con WhatsApp

🔁 1. Repaso práctico: Flujo de Trabajo de Clasificación de Correos

Se retomó el laboratorio de la clase anterior (clasificar correos en Consulta/Registro de vacaciones) para que el alumno lo replicara en una cuenta nueva. Puntos clave reforzados:

• El nodo Clasificar analiza el asunto y/o cuerpo del correo y lo agrupa en categorías predefinidas (p. ej. «Consulta» y «Registro de vacaciones»).
• Para que la clasificación dependa del contenido real del correo entrante (y no de un texto fijo de prueba), se debe usar contenido dinámico (el ícono de «rayito») apuntando al cuerpo del correo recibido, en vez de escribir un texto estático.
• Cuando se usa un agente dentro del flujo de trabajo para responder una consulta, es fundamental definir bien las instrucciones (prompt) del agente; un prompt poco elaborado puede hacer que la IA devuelva demasiada información sin formato adecuado.

⚠️ Problema detectado: formato de salida en correos

Al enviar la respuesta del agente por correo, el texto llegaba con sintaxis Markdown sin procesar (por ejemplo, asteriscos **texto** para negritas) porque Outlook no interpreta ese formato. La solución aplicada fue indicar explícitamente en el formato de salida del nodo que la respuesta debe ser**»texto plano»**, evitando HTML o Markdown.

📖 Esto se relaciona con la funcionalidad de salida JSON/estructurada de los nodos de mensaje: se puede elegir entre salida de texto simple o una salida estructurada/personalizada, y ese formato queda «bloqueado» al guardar el mensaje. [learn.microsoft.com], [learn.microsoft.com]

---

📚 2. Fuentes de conocimiento: limitación de profundidad

Al intentar usar un sitio web público como fuente de conocimiento para el agente (por ejemplo, una página sobre subsidio por maternidad), se observó una limitación técnica real: el sitio no puede tener más de 2 niveles de profundidad en su URL (dominio + 1 nivel); si tiene 3 o más, Copilot Studio no permite indexarlo correctamente.

📖 Nota: la documentación oficial no publica un límite explícito de «niveles de profundidad de URL» para sitios web públicos, pero sí establece los límites de origenes soportados (p. ej., 25 sitios web en modo generativo, 4 URLs públicas en modo clásico) y las limitaciones conocidas de indexación en fuentes tipo SharePoint (4-6 horas de sincronización, límites de archivos y carpetas). [learn.microsoft.com], [cloudwithsingh.ca]

También se confirmó que, a diferencia de los flujos de agente (donde se podía cargar un documento directamente como conocimiento del nodo), en los flujos de trabajo el conocimiento del agente debe provenir de un origen persistente como SharePoint, no se puede simplemente «arrastrar» un archivo suelto.

---

💳 3. Nuevo episodio de agotamiento de créditos

Al igual que en la clase anterior, varios intentos de publicar y probar el flujo de trabajo fallaron con el mensaje**»Necesitas créditos para continuar»**, tanto en la cuenta nueva de prueba como en cuentas ya usadas. Se reafirmaron las siguientes conclusiones:

• Los flujos de agente (deterministas) no consumen créditos de Copilot Studio para su ejecución básica.
• Los flujos de trabajo con nodos de IA (Clasificar, Agente, Prompt) sí consumen créditos, y ese consumo puede agotarse rápidamente incluso en cuentas de prueba nuevas.
• Cuando el nodo de clasificación no tiene créditos disponibles, retorna null, lo que provoca que el nodo switch/condicional no encuentre ninguna categoría válida y el flujo falle silenciosamente.

---

🧩 4. Nodo «Builder» (obsoleto) vs. Nodo de Agente

Se intentó mostrar el nodo clásico**»Builder»** (una función que permitía enviar un prompt a un LLM dentro de un flujo de agente clásico), pero ya no estaba disponible en las cuentas actuales. El docente explicó que:

• El nodo Builder sólo permitía definir instrucciones (prompt) y formato de salida, sin soporte para conocimiento ni herramientas adicionales.
• Microsoft ha estado reemplazando estas funciones por el nodo de Agente dentro de flujos de trabajo, que es más completo porque permite añadir conocimiento, herramientas y otros agentes conectados.

📖 Esto es coherente con el rol actual del nodo de Prompt/Ejecutar indicación, disponible en flujos de agente (no en flujos de trabajo con el harness de GitHub Copilot), que realiza una única llamada de IA con instrucciones y formato de salida configurable. Para un comportamiento equivalente dentro de un flujo de trabajo, la recomendación oficial es usar una acción de agente sin herramientas configuradas. [learn.microsoft.com]

---

🌐 5. Solicitudes HTTP: fundamentos (Laboratorio 1)

Este fue el tema central y nuevo de la clase. Se explicó cómo los sistemas se comunican entre sí mediante HTTP, usando como ejemplo práctico la PokéAPI (pública y gratuita) y una API de consulta de DNI peruano.

Estructura de una solicitud HTTP

Elemento	Descripción
🔗 URL	Dirección del recurso o endpoint al que se realiza la consulta
⚙️ Método	GET (obtener información) o POST (enviar/crear información); también existen PUT, PATCH, DELETE
📋 Headers (cabeceras)	Metadatos que describen la solicitud: Content-Type (tipo de contenido enviado, ej. application/json), Host, User-Agent, y especialmente Authorization (token/clave de acceso, equivalente a una contraseña)
📦 Body (cuerpo)	Datos enviados en la solicitud (solo aplica normalmente a POST/PUT); usualmente en formato JSON

Formato JSON (repaso)

Se explicaron los tipos de datos básicos de JSON: cadenas de texto (entre comillas), números, booleanos (true/false), nulos (ausencia de valor) y arreglos/colecciones (agrupados con corchetes [ ]).

📖 Documentación oficial sobre el nodo de solicitud HTTP en Copilot Studio: permite llamar a APIs REST externas seleccionando el método (GET, POST, PATCH, PUT, DELETE), configurando encabezados y cuerpo, y mapeando la respuesta a una variable de Power Fx mediante un esquema JSON de muestra. [learn.microsoft.com], [learn.microsoft.com]

---

💬 6. Laboratorio 2: Integración de un agente con WhatsApp (Green API)

Usando un proveedor externo (Green API, no oficial de Microsoft), se construyó un ejemplo completo de envío de mensajes de WhatsApp desde un flujo de agente:

1. Se creó una cuenta de prueba en Green API y se vinculó un número de WhatsApp escaneando un código QR.
2. Se identificó la URL de envío de mensajes (sendMessage), el método POST, y el body esperado en formato JSON (número de teléfono + mensaje).
3. Se creó un nuevo agente con una herramienta tipo flujo de agente llamada «Enviar WhatsApp»:
   • Entradas: número de teléfono (tipo texto) y mensaje (tipo texto).
   • Acción: nodo de Solicitud HTTP apuntando a la URL de Green API, con encabezado Content-Type: application/json y el cuerpo armado dinámicamente con las variables de entrada.
   • Salida: respuesta al agente confirmando el envío.
4. Al conversar con el agente y pedirle «enviar un mensaje a tal número», el orquestador del agente detectó automáticamente que debía usar esa herramienta, pasó los parámetros correctos, y el mensaje llegó exitosamente a WhatsApp.

Este ejercicio demostró en la práctica cómo un flujo de agente actúa como herramienta personalizada para que el agente conversacional ejecute acciones externas sin necesidad de un conector nativo.

---

❓ Preguntas y respuestas más destacadas de la clase

#	Pregunta del alumno	Respuesta del docente	Refuerzo con documentación oficial
1	«¿Por qué la información para responder tiene que estar en SharePoint? ¿No puedo simplemente cargar un documento suelto en el flujo de trabajo?»	En los flujos de trabajo el conocimiento del agente debe provenir de un origen persistente (SharePoint); solo en los flujos de agente clásicos se podía adjuntar un documento directo al nodo.	El origen SharePoint se conecta vía GraphSearch, respeta permisos y etiquetas de sensibilidad del usuario, con límites propios de sincronización e indexación [learn.microsoft.com], [learn.microsoft.com]
2	«¿La actividad no muestra el detalle exacto del error, solo que un nodo falló?»	Correcto, para depurar mejor se recomienda usar la «vista de código» del nodo y pasarla como contexto a un asistente de IA (Copilot, ChatGPT, Gemini) en lugar de solo mirar la pestaña Actividad.	—
3	«¿Ambos flujos (agente y trabajo) consumen créditos por igual?»	No: los flujos de agente deterministas casi no consumen créditos; los flujos de trabajo con nodos de IA (clasificar, agente, prompt) sí consumen créditos de forma variable, y pueden agotarse fácilmente en cuentas de prueba.	Los flujos consumen capacidad de Copilot Studio por cada acción de IA ejecutada [learn.microsoft.com]
4	«¿En qué se diferencia el header Content-Type del header Authorization?»	Content-Type indica qué tipo de dato se envía (ej. JSON, imagen); Authorization es la credencial que autoriza la operación en el servidor —es como la «contraseña» de la solicitud.	El nodo de solicitud HTTP permite agregar encabezados personalizados, incluyendo tokens de autenticación tipo Authorization: Bearer <token> [learn.microsoft.com]
5	«¿Se puede hacer esta integración con WhatsApp directamente desde Copilot Studio, sin herramientas externas como Hoppscotch?»	Sí, lo mismo que se probó en Hoppscotch (una herramienta externa para probar APIs) se puede replicar dentro de Copilot Studio usando el nodo de Solicitud HTTP dentro de un flujo de agente usado como herramienta.	El nodo de solicitud HTTP está disponible directamente en el diseñador de flujos de agente de Copilot Studio [learn.microsoft.com]

---

✅ Conclusiones y recomendaciones

• Verificar siempre el formato de salida de los nodos de IA cuando la respuesta se enviará por un canal que no soporta Markdown (como el correo electrónico): usar formato de «texto plano» en esos casos.
• Diseñar el prompt del agente con precisión, indicando explícitamente el formato deseado de respuesta (saltos de línea, extensión, tono), ya que un prompt genérico puede generar respuestas extensas o mal formateadas.
• Monitorear proactivamente el consumo de créditos antes de iniciar una sesión de práctica con flujos de trabajo, especialmente en cuentas de prueba, para evitar interrupciones a mitad de un laboratorio.
• Familiarizarse con los fundamentos de HTTP y JSON (URL, método, headers, body) es esencial para cualquier integración con sistemas externos, ya sea mediante conectores nativos o el nodo de Solicitud HTTP.
• Usar flujos de agente como herramientas personalizadas es una alternativa poderosa cuando no existe un conector nativo para un servicio de terceros (como ocurrió con la integración de WhatsApp vía Green API).
• Ante los cambios frecuentes de la plataforma (nodos que desaparecen, límites que cambian), es recomendable validar siempre contra la documentación oficial más reciente antes de asumir que un comportamiento observado es una limitación permanente.

---

📚 Referencias oficiales de Microsoft Copilot Studio

1. Realización de solicitudes HTTP (nodo de solicitud HTTP) [learn.microsoft.com]
2. Make HTTP requests (English) [learn.microsoft.com]
3. Salida JSON en mensajes/prompts [learn.microsoft.com]
4. Agent flows overview – beneficios y consumo de capacidad [learn.microsoft.com]
5. Agregar SharePoint como origen de conocimiento [learn.microsoft.com]
6. Resumen de fuentes de conocimiento [learn.microsoft.com]
7. Agregar un nodo de indicación (Prompt) a un flujo de agente [learn.microsoft.com]
8. Usar flujos de agente con el agente (como herramientas) [learn.microsoft.com]

---