# Ayuda — los problemas más comunes y cómo arreglarlos > Agentes y Automatizaciones · Ayuda > Fuente: https://magoallegri.com/cursos/agentes/ayuda/troubleshooting --- Los atascos clásicos de la automatización, con su salida. El meta-protocolo del lab aplica a casi todo: contener (botón rojo si hace daño) → diagnosticar (el error completo + "¿qué cambió?") → reparar y probar → documentar en la ficha. ## ⚙️ Flujos y automatizaciones ### "El flujo no dispara" El diagnóstico en orden: (1) ¿el trigger está ACTIVO (no en borrador/pausado — el clásico absoluto)? (2) ¿el evento de prueba cumple las condiciones EXACTAS del trigger (el form correcto, el campo esperado)? (3) ¿la plataforma muestra el intento en su historial de corridas (ahí está el error real)? El 90% es uno de esos tres. ### "El flujo corre pero hace algo distinto a lo esperado" Faltan reglas: cada decisión que el flujo tomó "raro" es una condición que no escribiste. Y verificá la transformación — el formato de los datos (el teléfono con/sin código, la fecha en otro orden) es la fuente silenciosa de la mitad de los comportamientos raros. ### "Funcionaba y dejó de funcionar" La pregunta de oro: **¿qué cambió?** El form editado, la columna renombrada, el permiso vencido, la plataforma actualizada. Las roturas espontáneas casi no existen; los cambios en las puntas, sí. Revisá el historial de corridas para fechar la rotura y cruzala con qué se tocó ese día. ### "Mi automatización se siente frágil, vivo esperando que se rompa" Señal de que faltan las tres capas de resiliencia: ¿tiene heartbeat (sabrías si dejó de correr)? ¿reintentos activos? ¿plan B manual escrito? Con las tres, la fragilidad se vuelve mantenimiento programado — y el miedo, supervisión con método. ## 🤖 Agentes ### "El agente clasifica/responde cualquier cosa" Su briefing tiene huecos — el diagnóstico: ¿los criterios tienen EJEMPLOS (3 casos bien resueltos enseñan más que diez reglas)? ¿el manejo de lo ambiguo está explícito (lo dudoso se marca, no se adivina)? Y corré el loop de entrenamiento: cada corrección tuya es una línea nueva del briefing — el agente que no mejora es un agente al que no le están enseñando. ### "El agente inventó información" La alucinación — el riesgo estructural del bocado de criterio. Las defensas: (1) el briefing con la regla dura "solo datos de las fuentes que leés; lo que no esté, se marca como faltante"; (2) el nivel de autonomía correcto (por eso todo lo que toca personas nace en nivel 2: tu revisión ESTÁ en el diseño); (3) en el QA de salida, la verificación de datos contra fuente. La alucinación no se elimina con fe — se contiene con arquitectura. ### "Apruebo tantas cosas que la automatización no me ahorra nada" El cuello clásico del nivel 2 — y tiene tres salidas según el caso: (1) ¿hay piezas que ya GANARON su ascenso (corridas limpias acumuladas) y siguen pidiendo OK por inercia? Ascendelas según su plan; (2) ¿la cola agrupa (el lote de OKs en un momento del día) o gotea interrupciones? El diseño de cola es la mitad del alivio; (3) ¿el agente preparador está priorizando bien? Su briefing matutino debería hacer que los OKs tomen segundos por ítem, no minutos. ## 🔔 Alertas y reporting ### "Recibo tantas alertas que las ignoro" El canal sagrado está quemado. La reconstrucción: la poda completa (¿cada alerta AHORA te hizo actuar la última semana? la que no, baja de nivel), el resumen diario agrupando los HOY, y los tres candados en los desvíos (piso de volumen, ventana honesta, persistencia). Un canal AHORA sano suena pocas veces por semana — y cuando suena, corrés. ### "El reporte generado dice cosas que no son" ¿La fuente estaba fresca (la planilla de eventos llenándose sola — verificá la instrumentación) o leyó datos viejos? ¿La atribución respeta la regla de evidencia (lo que no puede atribuir, lo admite)? El reporte se corrige en su briefing, no editando cada salida — la edición repetida del mismo error es el briefing pidiendo una regla. ## 🔌 Integraciones ### "Las herramientas del cliente no están en ningún catálogo" La isla del rubro — y la escalera completa antes de rendirse: ¿integración nativa apagada? ¿webhooks (la mayoría de los software de gestión modernos los tienen escondidos en configuración)? ¿API documentada (Claude la conecta)? ¿Y el último recurso digno: el export automático periódico (el CSV diario también es un puente)? "No se puede" casi siempre significa "no estaba en el primer catálogo que miré". ### "El cliente no me pasa los accesos y el proyecto está frenado" Por eso la lista de accesos es PRE-requisito del kickoff en tu scope (si no lo fue, lección aprendida — y scope corregido para el próximo). Con el proyecto ya frenado: la frase del camino, adaptada: "sin [ACCESOS] no puedo avanzar con [FASE]; sigo con [OTRA PARTE] mientras — ¿los conseguimos juntos en una llamada de 10 minutos?" La llamada compartida destrabamás que diez recordatorios. ## 💼 El servicio ### "El cliente tiene miedo de que 'un robot' maneje su negocio" El miedo es razonable y tu arquitectura es la respuesta — mostrala, no la declames: la matriz de autonomía (qué corre solo, qué espera OK, qué jamás), el handoff (el robot nunca vende: prepara y te pasa), los botones rojos, el protocolo de incidentes. El cliente no compra "confianza en la IA": compra TU sistema de control sobre ella. ### "Vendí la implementación pero el scope se me está yendo de las manos" ¿Hubo fase 0 (las incógnitas despejadas antes del precio)? ¿Las cláusulas del territorio están firmadas (accesos, datos sucios, el no-incluye)? Si no: el scope retroactivo HOY (la lección del camino) y la conversación honesta de fases. Si sí: aplicá las cláusulas con la frase amable — para eso se escribieron. --- ¿Tu atasco no está acá? El protocolo general: contener → "¿qué cambió?" → el error completo a Claude → reparar → probar → a la ficha. Y si el atasco es de diseño (no de rotura): volvé al briefing de la pieza — los sistemas se corrigen en sus contratos.