Anomaly Detection Agent.
Los drops del 20% en signups dejan de descubrirse el lunes en el dashboard. El agente avisa con hipótesis a los pocos minutos.
Agente custom de Agentforce que detecta anomalías en KPIs baseline (signups, conversions, churn, ARPU, transaction volumes) sobre CIs y DMOs. Aprende patrones de seasonality por canal, región y vertical. Alerta con root cause hypothesis basada en eventos correlacionados (deployments, campañas, calendar) y sugiere drill-downs. Diferencia con Steward OOTB (DQ-focused) y CI Recommender (CI design): este detecta cambios en métricas business.
¿Qué hace el Anomaly Detection Agent?
Es un agente custom desarrollado sobre Agentforce que opera como analista de guardia sobre los KPIs business de la compañía. Construye perfiles temporales de cada métrica crítica (signups, conversions, churn, ARPU, transaction volumes) sobre CIs y DMOs de Data Cloud, modela la seasonality por canal, región y vertical, y detecta outliers con severity scoring. Cuando algo se sale del rango esperado, cruza el evento con deployments recientes, campañas activas y el calendario de negocio para proponer una hipótesis de root cause y sugerir el drill-down más probable.
Cómo funciona paso a paso
Del profiling de la métrica a la alerta con contexto. 5 pasos diseñados para reducir el MTTD de anomalías de horas a minutos.
Profile metric
El agente construye un perfil temporal de cada KPI baseline sobre CIs ya calculados o sobre agregaciones on-the-fly de DMOs. Modela la seasonality por canal, región y vertical y mantiene el baseline esperado actualizado.
Detect outlier
Outlier Detector compara el valor observado contra el rango esperado para esa hora del día, ese día de la semana y ese contexto de calendario. Filtra ruido transitorio antes de generar una alerta.
Score severity
Cada anomalía recibe un severity scoring que combina la magnitud del desvío, la criticidad de la métrica y el momento (campaña activa, día de cobro, lanzamiento). La priorización guía el routing de la alerta.
Hypothesize root cause
Root Cause Hypothesizer cruza el evento con deployments recientes, campañas activas y el calendario de negocio. Si encuentra correlación temporal y causal plausible, propone una hipótesis con evidencia explícita.
Alert con context
Alert Composer publica la alerta en el canal del owner (Slack vía MCP, Teams, Tableau Pulse, email o Lightning) con la hipótesis, los drill-downs sugeridos y el botón para etiquetar la alerta como true positive, false positive o expected event.
Ejemplo de interacción
[09:30 — Slack canal #product-growth, mensaje del agente]
[Acciones disponibles en el mensaje]
Arquitectura del agente
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory.
Topics
Dominios de razonamiento
- Time-Series Profiler
- Outlier Detector
- Seasonality Modeler
- Cohort Comparer
- Root Cause Hypothesizer
- Alert Composer
Actions y Channels
Lo que ejecuta y dónde comunica
- profileMetric · detectAnomaly
- scoreSeverity · hypothesizeRootCause
- drillDown · alertStakeholder · snoozeAlert
- Slack vía MCP · Microsoft Teams
- Tableau Pulse · Email
- Lightning
Hydrators y DMOs
Fuentes de contexto
- CIs time-series
- DMOs aggregations
- Prior anomalies
- Business calendar
- Marketing calendar
- Deployment events
Effectors, Trust Layer y Memory
Escrituras, guardrails y aprendizaje
- Post Slack y Teams
- Write incident report
- Update dashboards
- Audit trail completo
- Memory de anomaly patterns y false positives
- Memory de seasonality por canal, región y vertical
Implementación en 5 fases
El driver crítico es la calidad del catálogo de métricas críticas y la profundidad del histórico para entrenar la seasonality. Timing típico: 8 a 12 semanas.
Discovery y catálogo de métricas
Inventariamos los KPIs business candidatos (signups, conversions, churn, ARPU, transaction volumes), priorizamos las que tienen baseline estable y validamos con los owners de cada métrica el rango aceptable y el on-call adecuado.
Modelado de seasonality y eventos
Cargamos el calendario de eventos LATAM (Hot Sale, Buen Fin, CyberDay, Black Friday) y los calendarios internos de campañas y deployments. Entrenamos los baselines con un mínimo de 90 días de histórico por métrica.
Agent build e integración con canales
Construimos Topics y Actions en Agent Builder, conectamos Slack vía MCP, Microsoft Teams, Tableau Pulse y email transaccional, y armamos los templates de alerta con drill-down sugerido por canal.
Shadow mode y calibración
El agente opera en shadow: detecta anomalías sin enviar alertas reales. Comparamos su salida contra los hallazgos del equipo de analytics y ajustamos thresholds y modelos para minimizar falsos positivos antes del go-live.
Go-live y mejora continua
Cutover. Monitoreamos MTTD de anomalías, tasa de falsos positivos, % de hipótesis correctas según feedback humano y cobertura del catálogo de métricas. La memoria del agente se enriquece con cada alerta etiquetada.
Equipo típico de implementación
Requisitos para arrancar
Lo que conviene tener listo antes del go-live.
Datos mínimos
- Catálogo de métricas críticas versionado
- Baselines estables con mínimo 90 días de histórico
- Business calendar y marketing calendar accesibles
- Deployment tracking integrado (deploys con timestamp)
Licencias
- Salesforce Data Cloud
- Agentforce Platform
- Tableau o Tableau Pulse según el stack BI
- Microsoft Teams o Slack según los canales del equipo
Integraciones
- Slack vía MCP y Microsoft Teams
- Tableau Pulse para insights compartidos
- Email transaccional para alertas formales
- Sistema de deployment tracking (CI/CD events)
Org readiness
- Ownership matrix por métrica
- On-call rotation por dominio (Product, Growth, CS, Ops)
- Política de feedback en cada alerta
- Gobernanza para incorporar nuevas métricas al catálogo
Qué se busca optimizar
Lo que el agente busca mejorar — los rangos exactos dependen del baseline de cada compañía.
No prometemos cifras atribuidas a casos. Detallamos las dimensiones que el Anomaly Detection Agent ataca y la dirección esperada del cambio.
MTTD de anomalías críticas
Detección que pasa de horas o días a segundos o minutos en métricas business cubiertas por monitoreo continuo y baselines calibrados.
Tasa de falsos positivos
Calibrada para que cada alerta sea accionable. El feedback humano de true positive y false positive ajusta thresholds por métrica y por canal.
% de root cause hypotheses correctas
Medido por feedback humano sobre cada alerta. La memoria del agente sobre eventos correlacionados mejora la calidad de las hipótesis a lo largo del tiempo.
Revenue lost prevented
Por detección temprana de drops en signups, conversions o transaction volumes que sin el agente se descubrirían con días de demora.
Cobertura del critical metrics catalog
% de KPIs business críticos bajo monitoreo automático, con el objetivo de tender a la totalidad del catálogo aprobado por los owners.
Calidad del seasonality modeling
Validada sobre eventos LATAM (Hot Sale, Buen Fin, CyberDay, Black Friday): el agente no debe alertar spikes esperados, pero sí debe alertar cuando un spike esperado no ocurre.
Qué considerar al implementar
Cinco prácticas que aceleran el time-to-value y sostienen la confianza del equipo.
Critical metrics catalog estable
Empezar con un catálogo acotado de KPIs business con baseline estable y owner claro. Expandir en oleadas controladas a medida que se gana confianza en la calidad de las alertas.
Business calendar y marketing calendar compartidos
El modelador de seasonality necesita el calendario de eventos comerciales, lanzamientos y campañas. Mantener estos calendarios en una fuente única evita falsos positivos en fechas esperadas como Hot Sale o Buen Fin.
Deployment events trackeados
Para que el Root Cause Hypothesizer pueda correlacionar drops con releases, hace falta un stream de deployment events con timestamp, autor y scope. Conectar el CI/CD desde el inicio acelera la calidad de las hipótesis.
Ownership por métrica para alert routing
Cada KPI necesita un owner business y un canal de destino. El agente abre la alerta en el canal del owner para que la respuesta sea inmediata y no quede flotando en una bandeja general.
Priority filtering para evitar alert fatigue
Configurar reglas por canal (Slack solo critical, Teams todo, email solo daily digest) y permitir snooze por métrica y ventana. La memoria del agente sobre false positives ajusta thresholds para que el ruido baje con el tiempo.
Preguntas frecuentes
Sí. El calendar de eventos LATAM está cargado y el modelador de seasonality los reconoce. El agente no marca como anomalía un spike esperado de Hot Sale, pero sí marca cuando el spike es 30% menor de lo previsto para esa fecha.
Cada alerta tiene action de "true positive", "false positive" o "expected event". Esa decisión queda en la memoria del agente y ajusta thresholds y modelos para esa métrica y ese canal.
Con ambos. Para CIs ya calculados es directo. Para DMOs el agente puede construir agregaciones temporales on-the-fly o solicitar al data team un CI explícito si la query es costosa.
Tres mecanismos: priority filtering por canal (Slack solo critical, Teams todo), supresión de anomalías en eventos esperados (cargados en el calendar) y agregación de anomalías relacionadas en una alerta única.
Sí. Tras la alerta, cualquier stakeholder puede preguntarle al agente por canal, browser, país, cohorte o producto. El agente devuelve el desglose con la dimensión que más explique la anomalía.
Sí. Las alertas y el drill-down conversacional se localizan según el canal. La lógica de detección es la misma; el wrapping lingüístico se adapta al equipo que recibe la alerta.
Tus métricas ya cuentan una historia. Solo falta un agente que la escuche en tiempo real.
Hablá con un Data Architect de Solu. Mapeamos tu catálogo de métricas críticas, calibramos baselines y proyectamos el lift en MTTD y en calidad de hipótesis para tu operación.