|
Gol |
Pregúntate: "¿Qué resultado estoy intentando conseguir?No: "¿Qué herramientas necesito?", "¿Qué conectores debería llamar?", o "¿Qué tema debería construir?"
Describe claramente por qué debe existir el agente, qué debe lograr y quién es el público objetivo. Concéntrate en los resultados. Deja que el diseño del agente se derive del problema.
Aclarar:- El problema o brecha de valor
- Usuarios de destino
- El impacto esperado
- ¿Qué aspecto tiene el éxito?
Utiliza un formato de Jobs-To-Be-Done:
-
Como<usuario>
-
Necesito<Trabajo por hacer>
-
Así que<Resultado>
|
- Como empleado nuevo, necesito entender las políticas locales de RRHH para poder manejar la incorporación con confianza.
-
Como un Responsable de soporte informático, necesito procesar los correos de soporte automáticamente para reducir el triaje manual.
|
- Empezando por las características en vez de los resultados.
- Diseñando para casos extremos.
- Omitir criterios de éxito medibles.
|
|
Desencadenadores |
Un disparador de agente es el evento, condición o entrada específica que indica a un agente comenzar su trabajo o tarea. Una acción humana o un evento automatizado pueden iniciar el desencadenante.
Más información: Encuentra el desencadenante que se adapte a tu evento. |
- Un mensaje de usuario en el chat.
- Un nuevo correo electrónico en una bandeja de entrada compartida.
- Un nuevo récord en un sistema.
- Un trabajo programado o recurrente.
|
- Los agentes autónomos requieren activadores explícitos. Sin ellos, el agente no huye.
- El desencadenante depende de un comportamiento impredecible del usuario, por ejemplo, dependiendo de que el usuario escriba una palabra clave o frase específica.
- Trigger carece del contexto requerido, por ejemplo, el agente inicia pero no tiene suficientes metadatos (ID de registro, identidad del usuario) para actuar eficazmente.
- Los disparadores se activan con más frecuencia de lo que el escenario realmente requiere, lo que lleva a ejecuciones innecesarias y al consumo de recursos.
- El diseño del desencadenador no tiene en cuenta cuotas o límites de plataforma, lo que hace que los agentes alcancen los umbrales de uso o fallen bajo carga.
|
|
Herramientas e integraciones |
Define qué acciones debe ser capaz de realizar el agente, no solo lo que sabe.
Las herramientas permiten al agente recuperar o actualizar datos, llamar APIs, activar flujos de trabajo, enviar mensajes y completar operaciones transaccionales. Enumera los sistemas de los que depende el agente y sus limitaciones (APIs, modelos de autenticación, límites de velocidad y límites de propiedad/SLA).
Considera los resultados esperados, los criterios de éxito y calidad, los mecanismos de respaldo y el comportamiento ante errores. Las dependencias suelen impulsar la viabilidad: abórdalas pronto.
Más información: Mecanismos para añadir herramientas a los agentes. |
- Conector de ServiceNow → obtener detalles del ticket
- Microsoft Entra ID conector → capturar la ubicación del usuario
- API de Jira → actualizar elementos de trabajo
- Outlook conector → responder al correo
|
- No registrar acciones ni almacenar salidas para auditoría.
- Suponiendo que las APIs sean estables y siempre estén disponibles.
- Herramientas con permisos excesivos.
- No definir el comportamiento de respaldo de las llamadas a la herramienta (sin validación de la salida de la herramienta, sin retroceso cuando fallan las herramientas, sin ruta de escalada).
- Ignorar los límites de tasa o la limitación.
- Falta mapeo de dependencias (quién posee cada API, cuál es el acuerdo de nivel de servicio).
- No validar las condiciones previas antes de realizar acciones.
|
|
Channels |
Un canal es la plataforma o interfaz específica donde tu agente está desplegado e interactúa con los usuarios.
El canal también influye en las expectativas de los usuarios respecto a la latencia, la toma de turnos y la experiencia. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- interfaces de chat web o de voz
|
- Elegir canales en función de la comodidad o simplicidad del despliegue, en lugar de cómo y dónde trabajan realmente los usuarios.
- Suponiendo que los usuarios se adapten al canal del agente, en lugar de encontrarse con ellos donde ya están.
- Priorizar la viabilidad técnica sobre la experiencia del usuario, lo que resulta en una baja adopción incluso cuando el agente funciona correctamente.
- Diseñar priorizando el chat cuando el canal real está controlado por correo electrónico o flujo de trabajo (crear una experiencia de usuario conversacional cuando el soporte técnico se produce realmente a través de Outlook; olvidar que el correo electrónico está basado en turnos, no es conversacional)
- Ignorar las restricciones específicas del canal (Outlook requiere respuestas completas, no aclarar preguntas; Teams admite tarjetas adaptables, el correo electrónico no)
|
|
Conocimiento y datos |
Documenta la información sobre la que el agente debe razonar y la ubicación donde el conocimiento o los datos están disponibles actualmente. Considera la calidad y frescura de los datos, el contenido estructurado frente al no estructurado, y los límites de acceso y permisos.
La preparación de datos es una de las fuentes más comunes de obstáculos en etapas avanzadas si no se aborda a tiempo. |
- Documentos
- Databases
- Sitios web
- Base de conocimiento
- Sistemas internos o externos
|
- Gobernanza de datos deficiente o inconsistente. Cuando no se definen los procesos de propiedad, cadencia de actualización y actualización, los datos rápidamente se vuelven obsoletos o contradictorios.
- Confundir "documentos" con "conocimiento". Señalar grandes repositorios de documentos como fuente de verdad sin considerar si esos documentos están actualizados, bien estructurados o etiquetados de forma consistente.
- Las fuentes de conocimiento se contradicen entre sí. Múltiples versiones de una política, procedimiento o conjunto de datos llevan al agente a instrucciones contradictorias.
- Los permisos y controles de acceso no están diseñados explícitamente. El contenido sensible se expone de forma involuntaria, o el agente hace referencia a conocimientos al que los usuarios finales no tienen acceso.
- Expandir las fuentes de conocimiento sin validar los límites de seguridad, lo que resulta en agentes que comparten en exceso o fallan cuando el acceso está restringido.
|
|
Flujos y orquestación |
Define cómo se estructura y secuencia el trabajo a lo largo del agente: cuándo usar flujos o temas deterministas, cuándo confiar en la orquestación y cuándo se requiere la intervención humana. El objetivo es un comportamiento predecible, automatización segura y una escalada clara.
Cuándo usar flujos o temas:- Recogida de datos en varios pasos
- Resolución de problemas guiada o árboles de decisión
- Procesos basados en cumplimiento o políticas
- Acciones de alto impacto o irreversibles
Los temas son el mecanismo principal de la lógica determinista.
Define:- Lo que el agente puede hacer de forma autónoma
- Qué requiere aprobación, revisión o anulación humana
- Cuando el agente debe escalar o aplazar
- Cómo la retroalimentación humana se traduce en la mejora
|
- Agente de 'Ask-Me-Anything': flujos deterministas mínimos; se basa principalmente en la orquestación y el razonamiento generativo.
- Agente autónomo: Utiliza flujos o temas para imponer secuenciación, validaciones y barreras de seguridad para los pasos críticos.
- Flujos de trabajo de aprobación: El agente prepara el contexto y las recomendaciones; Los humanos aprueban o anulan acciones de alto impacto.
|
- La sobreestructuración de los flujos limita la flexibilidad y hace que el agente se sienta rígido o frágil.
- Subestructurar flujos, reducir la fiabilidad y hacer que los resultados sean impredecibles.
- No usar explícitamente temas para lógica determinista, lo que lleva a comportamientos ad hoc o inconsistentes.
- Difuminando responsabilidades entre humano y agente, resultando en caminos de escalada poco claros.
- Sobrecargando a los humanos con aprobaciones para acciones de bajo riesgo, creando cuellos de botella y desincentivando el uso de agentes.
- Agentes que actúan sin límites claros de "no actúes", especialmente en escenarios de riesgo o de alto riesgo.
|
|
Instrucciones y comportamiento |
Las instrucciones definen:- El papel y responsabilidades del agente
- Cómo razona y responde
- Cuándo y cómo debería utilizar conocimientos, herramientas u otros agentes
- La secuencia de acciones que debe seguir
- Tono, límites y normas de seguridad
Instrucciones claras conectan conocimientos, herramientas y flujos en un sistema coherente y predecible.
Aprende más: Configura instrucciones de alta calidad para orquestación generativa y escribe instrucciones efectivas para agentes declarativos. |
- Función y alcance: "Eres el Agente de Soporte de Correo de TI responsable de leer los mensajes entrantes del buzón, extraer los números de tickets y responder con información validada de ServiceNow."
- Comportamiento secuenciado: "Paso 1: Revisa la base de conocimientos en busca de una política existente o un problema conocido. Paso 2: Si la información no se encuentra o está incompleta, llama a la herramienta ServiceNow para recuperar los detalles del ticket. Paso 3: Si aún faltan datos necesarios, responde usando un patrón de 'no lo sé' y escala la escalada."
- Reglas de uso de herramientas: "Validar siempre los IDs extraídos con una llamada a la herramienta antes de usarlos en las respuestas."
- Manejo de fallos: "Si falta conocimiento o falla una llamada a una herramienta, no adivines. Responde con una limitación clara y el siguiente paso."
|
- Las instrucciones son demasiado vagas. Por ejemplo, "Ayudar a usuarios con problemas de soporte" no especifica dominio, límites ni acciones permitidas.
- No hay claridad sobre cuándo usar el conocimiento, las herramientas frente a otros agentes, lo que lleva a comportamientos inconsistentes o ineficientes.
- Las instrucciones no definen la secuencia de acciones, lo que hace que el agente mezcle conocimientos y salidas de herramientas de formas impredecibles.
- Reglas de uso de herramientas no definidas explícitamente, lo que puede llevar a que las herramientas se llamen innecesariamente o no se utilicen en absoluto, o que el conocimiento y los resultados de herramientas se mezclen de formas inesperadas.
- Instrucciones contradictorias, como "siempre haz preguntas aclaratorias" y "responde solo con respuestas finales".
- No hay ninguna guía explícita de "no se debe hacer", como modificar datos sensibles, compartir identificadores internos o dar asesoramiento legal o de recursos humanos sin fuentes verificadas.
|
|
Arquitectura y composición del agente |
Utilizar múltiples agentes cuando:
- Los dominios son grandes o distintos
- La propiedad varía entre equipos
- El acceso o los permisos varían
- Se requiere razonamiento especializado
La delegación mejora la modularidad, claridad y mantenibilidad a largo plazo.
Más información: Explora patrones de orquestación multiagente. |
- Un agente principal delega la consulta de tickets a un agente de IT.
- Un agente de conocimiento se encarga del control de calidad de documentos.
- Un agente de rutas decide a qué agente experto llamar.
|
- La sobredelegación (demasiados agentes)—por ejemplo, crear un agente separado para cada pequeña tarea—puede provocar expansión arquitectónica y dificultar el mantenimiento, depuración, seguridad o actualización de los agentes.
- La subdelegación (un agente gigante)—por ejemplo, un solo agente que se espera que responda a preguntas de RRHH, consulte tickets de TI, gestione la resolución de problemas y genere órdenes de compra e incidentes—puede dar lugar a un agente monolítico y frágil que es imposible de mantener.
- Límites de delegación indefinidos. Por ejemplo, el agente principal no sabe cuándo ceder el control, los agentes secundarios no saben qué entradas deben esperar, o las responsabilidades se solapan (dos agentes verifican tickets de TI).
|
|
Gobernanza y gestión de riesgos |
Define cómo se goberna, protege y monitoriza el agente para garantizar que se comporta de manera responsable, segura y predecible a lo largo de su ciclo de vida.
Esta definición incluye control de acceso, permisos de acción, medidas de seguridad, responsabilidad y supervisión continua para gestionar tanto los riesgos operativos como los relacionados con la IA desde el primer día.
Más información: Recoger los requisitos de gobernanza y Aplicar los principios de la IA responsable. |
- Modelo de autenticación y acceso: El agente utiliza la identidad a nivel de usuario para recuperar solo los datos que el usuario puede ver, mientras que las identidades a nivel de sistema están restringidas a operaciones de servicio claramente definidas.
- Permisos de acción y barreras de seguridad: El agente puede actualizar notas de trabajo o redactar respuestas, pero no puede realizar acciones irreversibles (como cerrar tickets o enviar comunicaciones externas) sin aprobación.
- Seguridad y protecciones de contenido: La información sensible o regulada se detecta y se bloquea para ser compartida o actuada mediante protecciones de la plataforma (por ejemplo, prevención de pérdida de datos o filtros de seguridad).
- Registro, auditoría y trazabilidad: Todas las acciones de los agentes, consultas a herramientas, rechazos y escalaciones se registran y son auditables para cumplimiento y revisión.
- Propiedad operativa: El agente tiene un propietario, patrocinador y administrador operativo definidos, con permisos y comportamiento revisados de forma regular.
|
- Diseñar la gobernanza y los controles de riesgos demasiado tarde, lo que lleva a despliegues bloqueados o retrasos en la producción.
- Sobreautorizar a los agentes "por conveniencia", aumentando el riesgo de exposición de datos o acciones no intencionadas.
- Agentes que subautorizan los permisos, causando fallos en tiempo de ejecución cuando los sistemas o datos necesarios son inaccesibles.
- No integrar las preocupaciones de IA responsable en las decisiones de gobernanza centrales.
- Falta de gobernanza operativa eficaz, tal como la ausencia de un propietario claro, un plan de supervisión o un proceso definido para la respuesta a incidentes.
- No monitorizar el comportamiento del agente tras el despliegue, asumiendo que solo las barreras de seguridad son suficientes.
|
|
Evaluación y optimización |
Define pruebas que simulen escenarios reales para medir la precisión, relevancia y calidad de las respuestas de tus agentes. Proporciona una respuesta esperada y muestra cómo la respuesta del agente se relaciona con tu respuesta o con la respuesta más estándar.
Planifica cómo medir y mejorar el rendimiento:
- Precisión y relevancia
- Tiempo ahorrado o eficiencia
- Adopción y uso
- Señales de satisfacción y confianza
- Calidad de las citas
- Cumplimiento de permisos
- Detección de información incorrecta
- Aclaración del comportamiento de las preguntas
Define qué telemetría recopilar:
- Llamadas de herramientas
- Acciones del agente
- Fracasos y repeticiones
- Comentarios de usuario
Trata la evaluación como parte del diseño, no como una ocurrencia secundaria. Más información: Diseñar y operacionalizar la evaluación de agentes. |
- Valida que la búsqueda de tickets devuelva el estado correcto y no uno antiguo.
- Valida que los enlaces de citas apunten a contenido aprobado actual.
- Valida que el agente se niegue a proporcionar detalles sobre el ticket de otra persona.
- Comprueba si el agente inventa un número de ticket o un artículo de KB.
- Mide el número de correos electrónicos procesados por el agente autónomo por día y el porcentaje de usuarios que eligen al agente en lugar de canales manuales.
|
- Ejecutar evaluaciones demasiado tarde (después del despliegue).
- Sin línea base ni referencia.
- Evaluaciones no ligadas a escenarios reales.
- No detecta regresión.
- No se realiza evaluación en múltiples iteraciones.
- No hay evaluador para la calidad del uso de herramientas.
- Solo comprobando "escenarios felices".
- Lagunas en los datos de telemetría.
|
