En esta página
Considera una tarea ilustrativa en un navegador con cien pasos. Supón que cada uno sale bien el 99 % de las veces, de forma independiente. La probabilidad de que funcionen todos es 0.99^100, alrededor del 36,6 %.
El noventa y nueve por ciento suena excelente. El treinta y seis, no tanto.
La fuente que trata las tareas transaccionales en el navegador usa este cálculo para plantear una idea concreta: quien pidió el trabajo obtiene valor cuando la tarea termina, mientras el coste y el riesgo de fallo se acumulan en cada paso. Es aritmética bajo un supuesto, no una tasa de éxito publicada para ningún agente de navegador ni para una sincronización de Tajo. Los errores reales pueden depender unos de otros. Una sesión caducada puede romper varias acciones posteriores.
La pregunta útil, por tanto, no es «¿Qué precisión tuvo el último clic del modelo?». Es «¿Apareció el estado que pidió la persona?».
La transacción es la unidad que importa
Imagina que un agente abre un portal de seguros, encuentra un documento, lo descarga y confirma que pertenece a la cuenta correcta. Puede navegar correctamente por 99 pantallas y descargar el archivo equivocado en la número cien. Un registro lleno de clics exitosos no arregla el resultado.
La misma distinción vale para una integración. Un agente puede descubrir una API, proponer una correspondencia de campos y guardar un borrador. Nada de eso significa que un contacto de destino tenga ya el estado de consentimiento previsto. El trabajo termina cuando se ejecuta la operación aprobada y se comprueba la condición final pertinente.
Hay una diferencia entre actividad y finalización. La actividad es fácil de contar. La finalización necesita una definición.
Para una descarga, podría ser un archivo cuyo número de cuenta coincide con la solicitud. Para una sincronización de contactos, podría ser un registro de destino con el identificador, los campos y el permiso para recibir mensajes correctos. La comprobación debe examinar lo que le importaba a quien hizo la solicitud. Una respuesta positiva de la llamada anterior demuestra que esa llamada respondió. Puede que no demuestre que el destino cambió como se esperaba.
La guía de Tajo para conectar herramientas empresariales empieza por el flujo y la fuente de verdad de cada objeto de datos. Esas decisiones dan sentido a la comprobación final. Si dos sistemas se atribuyen la propiedad de un campo, incluso una escritura perfectamente ejecutada puede generar un estado incorrecto a largo plazo.
El coste de otra decisión
Bajo el mismo supuesto hipotético del 99 %, diez decisiones independientes dan aproximadamente un 90,4 % de éxito para toda la cadena. Cincuenta dan cerca del 60,5 %. Cien, alrededor del 36,6 %.
Probabilidad de éxito de toda la cadena (%)
Número de pasos independientes
- Éxito supuesto del 99 % por paso
Consultar los valores calculados
| Pasos | Éxito de toda la cadena (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
La curva cae rápido porque la multiplicación no perdona una buena media. Cada decisión adicional debe justificar su lugar.
Eso no significa que haya que convertir todas las llamadas a una API en una sola operación gigantesca. Algunas llamadas son deterministas: obtener una página con un cursor conocido, comparar un identificador o escribir un campo conforme a una correspondencia aprobada. No hace falta que el modelo vuelva a decidirlo para cada registro. Otras llamadas sí contienen una ambigüedad real: un nuevo campo del proveedor, un mensaje de error que cambió o una solicitud sin responsable claro. Esas pueden requerir criterio.
La división práctica consiste en usar el criterio para diseñar o reparar una regla y dejar que el código corriente aplique la regla estable. La ETL inversa ilustra el movimiento repetido de datos: el pipeline, no una conversación, debe procesar cada fila rutinaria. Un agente todavía puede ayudar a decidir qué debería hacer ese pipeline.
Es un límite operativo, no un lema. Si un proveedor cambia el significado de un campo, una regla determinista puede repetir perfectamente la acción equivocada. El sistema necesita detectar que cambiaron sus supuestos y devolver el caso a revisión.
Por qué una sola herramienta enorme no resuelve el problema
Hay una objeción razonable: «Si las cadenas largas fallan, pongamos toda la tarea detrás de una sola llamada a herramienta». Ayuda cuando esa herramienta es una transacción bien definida con un resultado comprobable. Falla cuando solo oculta un proceso largo e incierto.
Supón que syncCustomer() devuelve success: true tras enviar una actualización. Si el destino procesa las actualizaciones más tarde, la llamada todavía no puede probar el estado final del contacto. La herramienta redujo los pasos visibles. No redujo la incertidumbre.
Una interfaz mejor muestra los estados que importan: aceptado, aplicado, verificado o fallido. Esas palabras deben corresponder a pruebas. Una escritura aceptada puede bastar para una vista previa de bajo riesgo. Una audiencia de campaña o un cambio de consentimiento merecen una comprobación en el destino antes de llamarlos completos.
En esta vista propuesta de Tajo, una solicitud aceptada y una actualización aplicada se distinguen de un estado de destino verificado. La comprobación final sigue pendiente. Esa distinción da sentido al siguiente paso: inspeccionar lo que guardó el destino. Contar otra llamada correcta dejaría sin respuesta la pregunta original.
Una escritura terminada aún necesita pruebas
¿Terminó la sincronización del cliente?
Escritura aplicada. Verificación pendiente.
Todavía no se ha comprobado el estado del destino.
Actividad de sincronización
- Solicitud aceptada
- Actualización aplicada
- Comprobación del destino pendiente
Ejecución de ejemplo · 14:32 UTC
Lo que sabemos
- Respuesta del proveedor
- Aceptada
- Resultado de la escritura
- Aplicada
- Lectura del destino
- Pendiente
Una llamada correcta no demuestra el estado final.
Diseño propuesto inspirado en el registro de actividad de Tajo. Esta ilustración añade un estado de verificación; no afirma que ya exista la lectura del destino.
Esto también cambia qué conviene medir. Registra el número de intentos si ayuda a diagnosticar el coste. Registra los errores intermedios si señalan un paso roto. Pero evalúa el flujo por las transacciones completadas y verificadas, con el método de verificación junto a la cifra. Un equipo que informa de que «el 99 % de las llamadas tuvo éxito» no ha respondido si las personas obtuvieron el resultado que buscaban.
La explicación de los servidores MCP muestra cómo las herramientas permiten a un asistente llamar a otro sistema. El acceso a herramientas es solo el comienzo. El contrato es el estado que dejan.
Cien buenos clics aún pueden no dejar nada. Cuenta el resultado.
Preguntas frecuentes
¿Por qué falla un flujo largo si sus pasos casi siempre salen bien?
Si cada paso tiene una probabilidad independiente p de acertar, una cadena de n pasos acierta con probabilidad p elevada a n. Suponiendo un 99 % por paso, cien pasos se completan aproximadamente el 36,6 % de las veces. Los fallos reales pueden estar correlacionados; el cálculo ilustra un mecanismo, no mide la fiabilidad de un agente.
¿Reducir las llamadas a herramientas garantiza la fiabilidad?
No. Menos llamadas ayudan solo si la operación combinada conserva las comprobaciones y los puntos de recuperación necesarios. Una llamada opaca puede ocultar una escritura fallida igual que una cadena larga puede perder el hilo.
¿Qué debería medir un equipo en un flujo con agentes?
Mide la finalización verificada de la transacción solicitada, no solo las llamadas exitosas al modelo. Define el artefacto o estado de destino que demuestra que terminó el trabajo y registra con qué frecuencia aparece tras el flujo completo.