La respuesta es correcta. El camino es equivocado.

El número 420 puede ser correcto por dos razones incompatibles. En este ejemplo ilustrativo, dos agentes devuelven el mismo segmento de contactos y ambos enumeran 420 clientes. Uno utilizó la audiencia aprobada de la tienda y comprobó el consentimiento. El otro copió una exportación antigua de otro espacio de trabajo y, por casualidad, obtuvo la misma cifra.

Una evaluación que solo mire el resultado les daría la máxima puntuación a ambos. Sería una mala evaluación.

Una discusión sobre verificación en entornos de agentes separa el resultado final del camino seguido para producirlo. En su ejemplo de hoja de cálculo, el número correcto es solo una parte de la tarea. También importan las fórmulas, las referencias a las fuentes y el formato exigido. En las integraciones, la distinción es aún más decisiva: la procedencia de un resultado puede determinar si estaba permitido obtenerlo.

Un valor final no demuestra su procedencia

Supón que un agente propone una correspondencia de campos entre un objeto de cliente de una tienda y un sistema de marketing. Asocia email al correo, firstName al nombre y un campo de consentimiento al estado de marketing en el destino. La vista previa parece plausible.

¿Qué leyó para tomar esas decisiones? ¿El esquema actual, una muestra antigua o un documento de otra cuenta? ¿Comprobó el significado del campo de consentimiento o lo dedujo de su etiqueta? ¿Interpretó un valor nulo como «no suscrito» o como «desconocido»?

Cada respuesta cambia la fiabilidad de la misma correspondencia final. La correspondencia es un resultado. El rastro de pruebas es el argumento para utilizarla.

Ese rastro debe identificar qué versión de cada fuente estaba disponible en el momento de decidir. Una captura posterior de un esquema corregido no explica una correspondencia propuesta ayer. Conserva con la decisión la revisión pertinente del esquema o documento y el vínculo entre esa revisión y la regla aprobada. El objetivo es reconstruir la decisión, no guardar cada página que vio el agente.

Por eso una traza de herramientas puede importar más que una explicación segura de sí misma. La traza registra las llamadas concretas y los identificadores usados por el agente. Un resumen escrito puede ayudar, pero no demuestra que se consultó una fuente. En una integración, la prueba debe apuntar al objeto de origen, al contrato del destino y a la regla concreta que moverá los datos.

La guía para integrar herramientas empresariales empieza por la propiedad de los campos porque los nombres de ambos lados rara vez determinan quién tiene autoridad. Una comprobación del proceso pregunta si el agente consultó de verdad esa decisión antes de preparar una escritura.

Escribe el camino permitido en la tarea

Un buen caso de prueba tiene dos partes. Primero, indica qué debe contener el destino. Segundo, establece qué pruebas y acciones están permitidas para llegar allí.

En el segmento ilustrativo, el resultado esperado podrían ser 420 contactos, pero el camino aprobado también podría requerir una consulta limitada a la tienda, la correspondencia de consentimiento vigente y una vista previa que identifique los registros excluidos. Podría prohibir lecturas de otros espacios y envíos directos de campañas.

Así el comprobador puede ser específico. Puede rechazar mecánicamente un identificador de otro espacio de trabajo. Puede comprobar que hubo una vista previa antes de activar el flujo. Puede confirmar que la fuente citada en el resultado coincide con la fuente registrada en la traza. Son reglas, no opiniones del modelo.

Quizá quede una pregunta que exija criterio: ¿significaba realmente el campo de consentimiento elegido que se permitía esta campaña? Ahí una persona o un modelo de decisión específico debe examinar la definición del campo y el uso previsto. La regla y el criterio hacen trabajos distintos.

La prueba obtiene así un mensaje de fallo útil. «Respuesta incorrecta» deja al equipo adivinando. «Cifra correcta, pero la audiencia procede de una lectura en otro espacio» identifica un fallo en el límite de los datos. «Correspondencia correcta, pero no estaba disponible la definición del consentimiento» identifica una prueba ausente. El comprobador debería señalar la condición incumplida y la entrada de la traza que la causó, para reparar el camino en lugar de pulir la redacción final.

¿Qué demuestra la traza?

1. Fuente aprobada y comprobaciones obligatorias

   Aceptar el camino

   El resultado tiene las pruebas exigidas por la tarea.

2. Fuente de otro espacio de trabajo

   Rechazar el camino

   Una cifra coincidente no autoriza esa lectura.

3. Falta una prueba obligatoria

   Retener para revisión

   El resultado solo no demuestra cómo se obtuvo.

No conviertas la traza en un ritual

Una objeción razonable es: «Un agente puede hacer las llamadas exigidas y aun así ignorarlas». Cierto. Una lista de llamadas demuestra que sucedieron. No demuestra que las pruebas devueltas influyeran en la decisión.

Una forma de comprobarlo consiste en variar las pruebas. Presenta dos registros parecidos con estados de consentimiento distintos. Si el agente produce la misma correspondencia y explicación en ambos casos, quizá la supuesta consulta de fuentes sea puro teatro. Otra opción es retirar una fuente obligatoria y exigir que el agente se detenga. Un agente que rellena el vacío recurriendo a su memoria no ha seguido el camino.

El coste es más trabajo al preparar los datos de prueba. Alguien debe definir las fuentes autorizadas, las diferencias esperadas y los atajos prohibidos. Una puntuación genérica de «¿parece buena la respuesta?» es más barata de crear. Enseña menos.

La ETL inversa convierte una correspondencia en movimiento repetido. Una vez aprobada, el código corriente puede aplicarla sin que un agente vuelva a revisar las pruebas en cada fila. La auditoría del camino corresponde a las decisiones que crean o cambian esa regla y, de nuevo, cuando un contrato modificado la pone en duda.

Una respuesta correcta obtenida mediante la cuenta equivocada no es un fallo por poco. Es otra tarea.