Data Quality Triage Agent.
El backlog de issues de calidad deja de ser una lista plana — se convierte en cola priorizada por impacto real.
Agente custom de Agentforce que recibe issues del Steward Agent OOTB y los prioriza por impacto en activaciones, segmentos y CIs críticos. Considera business value downstream, deadlines de campañas, customer-facing impact y regulatory implications. Asigna a los teams correctos con SLA explícito y notifica al CDO solo lo que requiere su atención.
¿Qué hace el Data Quality Triage Agent?
Es un agente custom desarrollado sobre Agentforce que actúa como triage center del backlog de calidad de datos. Recibe los issues que el Steward Agent OOTB genera, los pondera por impacto real (no por counts), identifica al owner correcto, calcula un SLA explícito según severity y crea el ticket en el ITSM elegido. Aprende de cada decisión humana del CDO y del Steward Lead, ajustando priority y ownership en los próximos issues. La meta es que el CDO reciba solo lo que requiere su atención, sin que se le pierdan los issues que sí importan.
Cómo funciona paso a paso
Del issue al cierre con feedback archivado. 5 pasos diseñados para ordenar el backlog sin saturar al CDO.
Issue ingresa al triage
El issue llega desde el Steward Agent OOTB con su detalle: regla violada, dominio, magnitud y muestra de filas. El agente lo clasifica por dominio y por tipo de regla (completitud, validación, unicidad, integridad referencial).
Score de impacto downstream
Impact Scorer cruza el issue con DMOs, CIs, segmentos y activaciones que dependen del campo afectado. Considera business value, activation calendar y customer-facing impact para calcular un score final.
Identificación del owner correcto
Owner Identifier consulta la ownership matrix versionada y asigna el issue al team responsable del dominio. Si el ownership es ambiguo, abre un ticket de tipo "needs review" al Steward Lead.
Ticket con SLA y notificación
SLA Calculator define el SLA explícito según severity y createTicket lo abre en Jira, Linear o Service Cloud con priority calibrada al modelo del ITSM. Notifica al owner por Slack y al CDO solo si es critical.
Cierre con feedback archivado
Cuando el ticket se cierra, el agente registra el outcome y cualquier override humano de priority u ownership. Esa memoria ajusta los próximos triages en issues similares dentro del mismo dominio.
Ejemplo de interacción
[Durante una campaña high-priority de fin de año, mensaje del agente al CDO]
[12 tickets critical abiertos en Jira]
Arquitectura del agente
Topics, Actions, Hydrators, Effectors, Channels, DMOs, Trust Layer y Memory.
Topics
Dominios de razonamiento
- Issue Classifier
- Impact Scorer
- Owner Identifier
- Severity Assigner
- SLA Calculator
- Communication Composer
Actions y Channels
Lo que ejecuta y dónde comunica
- triageIssue · assignOwner
- escalate · createTicket
- notifyStakeholders · closeIssue · reopenIfRegress
- Jira · Linear · Service Cloud
- Slack vía MCP
- Email · Lightning
Hydrators y DMOs
Fuentes de contexto
- DQ issues from Steward Agent
- Activation calendar
- Campaign schedule
- Downstream consumer map
- Prior triage decisions
- Ownership matrix
Effectors, Trust Layer y Memory
Escrituras, guardrails y aprendizaje
- Write Jira/Linear/Service Cloud ticket con priority
- Post Slack al owner
- Escalate to leadership
- Audit trail completo
- Sin PII en payloads
- Memory de triage patterns por dominio y ownership shifts
Implementación en 5 fases
El driver crítico es la calidad de la ownership matrix y los impact weights por dominio. Timing típico: 8 a 12 semanas.
Discovery y ownership matrix
Levantamos la ownership matrix por dominio, equipo y tenant. Validamos con el CDO los impact weights por DMO, CI y segmento. Definimos los SLAs por severity de la compañía.
Impact weights y activation calendar
Modelamos los pesos de impacto por DMO, CI y segmento. Conectamos el activation calendar y el campaign schedule para que el agente sepa qué issues caen sobre activaciones en curso.
Agent build e integración con ITSM
Construimos Topics y Actions en Agent Builder, conectamos Jira, Linear o Service Cloud, definimos templates de notificación en Slack y configuramos el Trust Layer para excluir PII de los payloads.
Shadow mode y calibración
El agente opera en shadow: triagia issues sin abrir tickets reales. Comparamos su salida contra el control humano del Steward Lead y ajustamos pesos de impacto y reglas de severity.
Go-live y mejora continua
Cutover. Monitoreamos % de issues triagiados dentro del SLA, tasa de escalations innecesarias al CDO y % de issues asignados al owner correcto en primer intento. La memoria del agente se enriquece con cada cierre.
Equipo típico de implementación
Requisitos para arrancar
Lo que conviene tener listo antes del go-live.
Datos mínimos
- Ownership matrix versionada
- Impact weights por DMO, CI y segmento
- Activation calendar accesible
- Histórico de triage decisions del Steward
Licencias
- Salesforce Data Cloud
- Agentforce Platform
- Steward Agent OOTB activo y configurado
- ITSM elegido con licencia de API
Integraciones
- Jira, Linear o Service Cloud para tickets
- Slack vía MCP para notificación de owners
- Email transaccional para escalaciones formales
- Activation calendar y campaign schedule accesibles
Org readiness
- SLAs explícitos por severity acordados
- Política de escalación al CDO definida
- Steward Lead disponible para approvals dudosos
- Política de privacidad de payloads sin PII
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 Data Quality Triage Agent ataca y la dirección esperada del cambio.
% de issues triagiados dentro del SLA
Cobertura del agente sobre el backlog total, midiendo la disciplina con la que cada issue se asigna y se cierra dentro del tiempo definido por severity.
Tasa de escalations innecesarias al CDO
Reducción de notificaciones al CDO que no requerían su atención, aumentando la señal sobre el ruido y evitando el alert fatigue ejecutivo.
MTTR de issues critical
Tiempo medio de resolución de los issues que afectan segmentos activos, dashboards de leadership o regulaciones — donde la velocidad importa más que el volumen.
Calidad del impact scoring
Validada por feedback humano: % de triages aprobados sin override por parte del Steward Lead o del CDO, indicador clave de confianza en el agente.
% de issues asignados al owner correcto en primer intento
Indicador de la calidad de la ownership matrix y de la lógica de Owner Identifier. Cuanto más alto, menos handoffs y menos tiempo perdido en cola.
Cobertura del activation calendar en la priorización
% de campañas activas reflejadas en el score de impacto. Asegura que un issue que afecta una activación en curso suba al critical aunque su volumen sea bajo.
Qué considerar al implementar
Cinco prácticas que aceleran el time-to-value y sostienen la confianza del CDO y del Steward Lead.
Ownership matrix actualizada
La matriz tiene que reflejar el organigrama real. Conviene revisarla cada trimestre y automatizar la actualización cuando hay cambios de equipo, para que los issues nunca queden en una cola anónima.
Business impact weights por DMO/CI/segmento
El triage por impacto depende de pesos claros. Definirlos con leadership al inicio y recalibrarlos cada trimestre mantiene al agente alineado con la prioridad real del negocio.
Activation calendar compartido
El agente debe ver el calendar de activaciones y campañas. Mantenerlo actualizado y accesible vía API permite que un issue que cae sobre una activación en curso suba al critical de inmediato.
Integración con el ITSM existente
Jira, Linear y Service Cloud tienen modelos distintos de priority y assignment. La traducción de la severity del agente al modelo del ITSM debe estar bien calibrada para que cada owner reciba el ticket en el formato esperado.
Gobernanza del feedback loop
Cada override humano de priority u ownership debe quedar registrado y auditable. Ese feedback alimenta la memoria del agente y conviene que tenga un proceso formal de revisión mensual con el Steward Lead.
Preguntas frecuentes
No. Complementa. El Steward humano sigue siendo el dueño de la calidad y aprueba triages dudosos. El agente saca trabajo manual de la cola y deja al Steward en lo estratégico: definir reglas, calibrar pesos y resolver casos ambiguos.
Con dos mecanismos: priorización estricta (solo critical sube al CDO) y agregación de issues relacionados al mismo dominio en un único ticket cuando el patrón se repite. Los demás issues se trabajan al nivel correcto sin notificar al CDO.
Cada vez que un humano cambia priority, ownership o severity, queda registrado en la memoria del agente. El próximo issue similar usa esa decisión como referencia y reduce la cantidad de overrides necesarios con el tiempo.
Sí. La ownership matrix se segmenta por team y por tenant. El agente respeta los límites y no cruza tickets entre tenants. Para clientes con varias unidades de negocio, cada tenant tiene su propia matriz, sus impact weights y sus SLAs.
Con los tres. Los conectores nativos abren tickets con la priority y el owner mapeados al modelo de cada herramienta. La traducción se calibra durante shadow mode para que las severities del agente lleguen como priority adecuada en el ITSM destino.
Cuando dos owners reclaman el mismo issue o cuando el impact score es ambiguo, el agente abre un ticket de tipo "needs review" al Steward Lead con la disputa explícita y las opciones para decidir. No fuerza una asignación arbitraria.
El backlog de calidad ya está. Solo falta un agente que lo ordene por impacto.
Hablá con un Data Architect de Solu. Mapeamos tu ownership matrix, validamos los impact weights y proyectamos el lift en disciplina de SLA para tu operación.