El agente reintentó y ahora hay dos: idempotencia y reintento seguro cuando la IA opera el ERP funerario

Imagina la escena más aburrida posible. Son las once de la noche, la asesora de turno le pide al asistente conectado al ERP que registre el anticipo de un servicio que acaba de iniciar, y el asistente lo hace. La petición sale, el ERP la recibe, la procesa y guarda el pago. Y justo entonces la conexión se cae. El asistente no recibe respuesta: para él, la operación no tiene resultado. Hace lo que cualquier sistema bien educado haría —lo que la documentación de su propio protocolo le sugiere hacer— y reintenta. La segunda petición llega, el ERP la procesa igual de bien que la primera, y el servicio queda con dos anticipos.

Nadie se equivocó. El modelo no alucinó, el asesor no se distrajo, el ERP no falló: cada pieza hizo exactamente lo que debía. El duplicado no lo produjo un error, sino la respuesta correcta a una pregunta que el sistema no sabe responder: «¿esto ya ocurrió?». Esa pregunta —y la media hora en que la respuesta es desconocida— es de lo que trata este artículo.

Este artículo es un caso de uso concreto de inteligencia artificial conectada al ERP por MCP, escrito para la dirección de tecnología, la dirección financiera y la dirección de operaciones. No explica qué es MCP —para eso está la página del módulo SFUN MCP—: explica cómo se diseña una sola cosa, el reintento, para que la automatización no genere el trabajo que venía a quitar. Es la continuación directa de la guía sobre acciones irreversibles y agentes de IA: allí se decide qué puede ejecutar el agente y dónde va la compuerta; aquí, qué pasa después de que la compuerta se abre y la respuesta no vuelve. Aquel artículo cerraba con un indicador que no admitía matices —reintentos de operaciones con efecto sin clave de idempotencia: cero— y esa línea merecía su propio desarrollo.

1. El problema de negocio: la ventana en la que nadie sabe qué pasó

Entre el momento en que una petición sale y el momento en que su respuesta llega hay un intervalo en el que el estado del mundo es desconocido para quien preguntó. En condiciones normales ese intervalo dura milisegundos y a nadie le importa. Cuando algo se cae —la red, el proceso, el balanceador, el navegador de la asesora— el intervalo no se cierra nunca: simplemente deja de haber respuesta. Y el sistema que preguntó se queda con tres posibilidades indistinguibles entre sí: la petición no llegó, llegó y falló, o llegó y funcionó pero la respuesta se perdió.

Un tiempo de espera agotado o un fallo no significan necesariamente que los efectos secundarios no hayan ocurrido.— Marc Brooker, Amazon Builders' Library — «Timeouts, retries, and backoff with jitter»

Esa frase, que viene de la ingeniería de sistemas distribuidos y no de un proveedor de IA, es la raíz de todo lo que sigue. Un error en la pantalla del agente no es evidencia de que no pasó nada. Y la consecuencia práctica es incómoda: el agente que ve un error y reintenta está actuando con la mejor intención sobre información insuficiente.

Qué cuesta esto en una compañía funeraria

En la mayoría de los sectores, un duplicado es una molestia administrativa. En este sector, la escala del daño depende por completo de qué se duplicó, y conviene ordenarlo antes de diseñar nada:

La última fila es la que cambia la conversación. En una pasarela de pagos, el peor caso de un reintento mal diseñado es un cargo duplicado, y existe un mecanismo formal para devolverlo. En una funeraria hay efectos que ninguna transacción compensatoria alcanza: un mensaje enviado, un móvil despachado, un cuerpo trasladado. Esa asimetría es la razón por la que este diseño no se puede dejar para después de la prueba piloto.

2. La evidencia: el protocolo te dice que falló, no si puedes repetir

Conviene ser precisos sobre de quién es el hueco, porque la respuesta cambia a quién hay que exigirle la solución. Y el hueco no está en el modelo de lenguaje: está en la forma del mensaje de error.

En agosto de 2026 se publicó una auditoría que midió exactamente esto. Su autor tomó el registro público de servidores MCP, lo filtró hasta quedarse con diez servidores alcanzables y les provocó veintiún fallos de forma segura. Luego se preguntó algo muy concreto: mirando solo los campos tipados del resultado —lo que un programa puede leer sin interpretar prosa—, ¿cuánta información aprovechable hay?

Cero. En palabras del propio estudio, ninguna observación aporta una petición de reemplazo completa, un tiempo de reintento explícito, la seguridad de repetir la petición sin cambios ni el estado de los efectos secundarios. El agente sabe que algo falló y no tiene forma programática de saber qué hacer al respecto.

El hallazgo no es una anomalía de esos diez servidores: está en el esquema. En la revisión vigente del protocolo MCP, el resultado de una llamada a herramienta se compone de un tipo de resultado, el contenido, el contenido estructurado y una marca booleana de error. No hay campo para un código de error, ni para una política de reintento, ni para un retardo sugerido, ni para una clave de idempotencia, ni para indicar si repetir la petición idéntica es seguro. Y la propia especificación describe los errores de ejecución de herramienta como «retroalimentación accionable que los modelos de lenguaje pueden usar para autocorregirse y reintentar con parámetros ajustados». El protocolo invita a reintentar sin darle al cliente ningún modo de saber si reintentar es seguro.

Alguien lo propuso. La propuesta se cerró.

El 1 de agosto de 2026 se abrió una propuesta formal al protocolo, la SEP-3182, titulada «Request Idempotency». Planteaba el problema en los mismos términos de este artículo: un servidor no puede distinguir «esta petición nunca llegó» de «esta petición llegó, se ejecutó y la respuesta se perdió», y por eso un cliente que reintenta tras una desconexión no tiene manera segura de hacerlo en una herramienta con efectos. Proponía un campo opcional de clave de idempotencia en la llamada. Se cerró el 23 de agosto de 2026.

Vale la pena decir por qué, porque es fácil contar mal esta historia: el mantenedor la cerró por un motivo de proceso —una propuesta generada con IA sin declararlo ni aportar contexto—, no tras un debate técnico que rechazara la idea. No sabemos qué habría pasado con la misma propuesta mejor presentada. Lo que sí sabemos, y es lo único que importa para una decisión de arquitectura hoy, es el hecho verificable: el protocolo con el que tu IA opera el ERP no tiene una clave de idempotencia estándar, y quien la necesite tiene que implementarla en su propia capa. Es responsabilidad del ERP, no del protocolo. Así que es una pregunta legítima para tu proveedor de software, no para tu proveedor de modelos.

El contraste es la parte incómoda: la industria de pagos resolvió esto hace años y lo documenta en público. Volveremos sobre ello en la sección de homologación, porque de ahí sale el diseño que sí funciona.

3. Qué datos del ERP intervienen

El diseño del reintento no se hace en abstracto: se hace sobre una lista concreta de operaciones y de documentos. En un ERP funerario los que importan son estos, y conviene tenerlos clasificados antes de escribir una sola línea:

La tercera columna es la más importante del artículo y la que casi nadie escribe. Un duplicado solo se puede evitar si antes se define qué significa «el mismo». Esa definición —qué combinación de campos identifica de forma única una operación de negocio— es la materia prima de todo lo que viene después. No es un problema técnico: es una decisión del dueño del proceso, y en la práctica la toman entre operaciones, contabilidad y tesorería en una reunión de una hora.

4. Cómo se arma el caso con MCP, paso a paso

Lo que sigue es la secuencia de trabajo, en el orden en que conviene hacerla. Los tres primeros pasos no requieren desarrollo y se hacen con lo que ya tienes; los siguientes sí son trabajo de ingeniería, y están marcados como tales.

Paso 0. Inventaría las operaciones con efecto, y ordénalas por daño

Lista todas las herramientas de escritura que el agente puede invocar hoy y clasifícalas con la tabla de la sección 3. La pregunta de clasificación no es «¿qué tan compleja es?», sino «¿cuánto cuesta que esto ocurra dos veces?». Es un ejercicio de dos horas y su producto es una lista corta: casi siempre, entre cinco y diez operaciones concentran todo el riesgo. Todo el esfuerzo de los pasos siguientes va sobre esa lista, no sobre el catálogo completo.

Paso 1. Separa «nunca empezó» de «no lo sé»

No todos los fallos son ambiguos, y tratarlos igual es el error más caro del diseño. Si el ERP rechazó la petición por una validación —falta un campo obligatorio, el cliente no existe, el importe excede el tope— entonces no hubo efecto y reintentar con los datos corregidos es perfectamente seguro. Esos son la mayoría de los fallos del día a día y no necesitan protección especial.

El caso peligroso es el otro, y se reconoce por su forma: la petición se envió y no volvió nada. Tiempo de espera agotado, conexión cerrada, error del intermediario, proceso reiniciado. Ahí el agente no tiene información y ahí —y solo ahí— se aplican los pasos siguientes. La regla operativa cabe en una línea: un error con explicación es reintentable; un silencio no lo es.

Paso 2. Verifica antes de reintentar (esto ya lo puedes hacer hoy)

Este es el paso con mejor relación entre esfuerzo y resultado, y no necesita que nadie modifique el ERP. Antes de repetir una operación con efecto, el agente consulta si el efecto ya está ahí. Es la diferencia entre «lo intento otra vez» y «déjame ver si ya quedó». Con la definición de «el mismo» del paso anterior, la consulta es directa: ¿existe un pago de este importe sobre este contrato en los últimos cinco minutos? ¿Existe una factura para esta caracterización? ¿Hay una orden de traslado abierta para este servicio?

Es también el patrón que la literatura reciente recomienda. Un trabajo de julio de 2026 sobre fiabilidad de agentes bajo fallos no atómicos parte de una observación que describe bien el problema: los marcos de agentes suponen que una llamada a herramienta es atómica y devuelve éxito o fracaso, mientras que los sistemas reales exhiben tiempos de espera agotados después del despacho, visibilidad diferida y actualizaciones de estado parciales. Su propuesta combina tres cosas: verificación de postcondiciones, verificar antes de reintentar y claves de idempotencia. En entornos simulados con fallos inyectados, reduce de forma significativa las acciones duplicadas sin degradar la tasa de éxito, y sin tocar el modelo. Los resultados son cualitativos y en simulación, no una promesa de porcentaje sobre tu operación; el valor está en el patrón, que es sólido y barato.

La advertencia honesta: la verificación previa reduce la ventana, no la elimina. Entre la consulta y el reintento vuelve a existir un intervalo, y si el efecto original se materializa justo ahí —lo que ese mismo trabajo llama visibilidad diferida— el duplicado ocurre igual. Por eso este paso es el primero, no el único.

Paso 3. Usa el borrador como amortiguador

Hay una manera de convertir un problema difícil en uno fácil: hacer que el efecto del reintento sea barato. Si la operación que el agente ejecuta deja el documento en borrador —creado pero no emitido, no confirmado, sin numeración fiscal consumida ni movimiento contable— entonces un duplicado es un borrador de más, que una persona descarta en diez segundos. La confirmación, que es el paso irreversible, la hace un humano una sola vez y sobre un documento concreto que está mirando.

Es la misma idea que en la literatura de sistemas de agentes aparece como effect outbox: los efectos hacia afuera se retienen y solo se liberan tras una validación, en lugar de dispararse en el momento de la llamada. Y es, con otro nombre, lo que ya hacen las operaciones de facturación y de pago de SFUN, que dejan el documento en borrador explícitamente sin emitir y sin confirmar. Cuando puedas elegir, diseña la herramienta para que prepare, no para que consume: es el único de estos pasos que además mejora el control interno por razones que no tienen nada que ver con la IA.

Paso 4. La clave de idempotencia, que es la solución de fondo (requiere desarrollo)

Los tres pasos anteriores reducen el riesgo. Este lo elimina, y por eso es el que hay que exigirle al proveedor de software. La mecánica es simple: quien llama genera un identificador único para esa operación de negocio y lo envía con la petición. El servidor guarda el resultado bajo esa clave. Si llega una segunda petición con la misma clave, no ejecuta nada: devuelve el resultado guardado de la primera. El reintento deja de ser peligroso porque deja de ser una operación nueva.

Los detalles que deciden si funciona o no son cuatro, y los tres grandes procesadores de pagos los documentan en público:

• Qué se guarda. Stripe guarda el código de estado y el cuerpo de la primera petición y devuelve ese mismo resultado en los reintentos — incluidos los errores del servidor. El segundo intento no vuelve a intentar: recibe lo que pasó la primera vez.
• Cuánto dura la clave. Las claves de Stripe se purgan a las 24 horas; las de Adyen valen entre 7 y 14 días. Pasado ese plazo, la misma clave produce una petición nueva. Una ventana de horas basta para un reintento automático; no sirve como protección contra un error humano tres días después.
• Qué pasa si cambian los datos. Stripe compara los parámetros entrantes con los originales y devuelve error si difieren. Es la protección contra el peor caso silencioso: reutilizar una clave para una operación distinta y recibir la respuesta de la anterior.
• Quién decide si se puede reintentar. Adyen lo resuelve de la forma más honesta: además de aceptar la clave, devuelve una cabecera que indica si el error fue transitorio. Si no viene esa señal, o viene en falso, no se reintenta. El servidor dice si repetir es seguro, en lugar de dejar que el cliente lo adivine.

Y el detalle que mejor resume por qué esto no es opcional lo dice la documentación de PayPal sin rodeos: si omites la cabecera de identificación de la petición, PayPal duplica la petición. El comportamiento por defecto de un sistema sin clave no es fallar de forma segura: es duplicar. Conviene asumirlo así al evaluar cualquier integración.

Paso 5. Reintenta en un solo punto de la pila

Entre el agente y la base de datos hay más capas de las que parece: el agente, el cliente que ejecuta la llamada, el conector, la biblioteca de red, el servidor de aplicación. Si varias reintentan por su cuenta, los reintentos se multiplican. La aritmética que publica Amazon es fácil de seguir y difícil de olvidar: con cinco capas de servicios reintentando tres veces cada una, la carga sobre la base de datos del fondo se multiplica por 243, «haciendo improbable que llegue a recuperarse».

En una pila de agentes eso no es una metáfora: cada multiplicación es un documento potencialmente repetido. La regla que se deriva es de una sola frase: decide en qué capa vive el reintento y apágalo en todas las demás. Para operaciones con efecto en un ERP funerario, esa capa debería ser la más alta posible —donde alguien puede ver qué se está repitiendo— y nunca la biblioteca de red, que reintenta a ciegas.

Paso 6. Acepta que el flujo funerario es una saga, y escribe las compensaciones

Un servicio funerario completo —contrato, autorización, traslado, preparación, velación, disposición final, facturación— es una secuencia de pasos con efectos, ejecutados por sistemas y personas distintas, que no comparten una transacción única. En ingeniería eso tiene nombre, saga, y una advertencia explícita en su propia definición: no hay reversión automática, así que hay que diseñar transacciones de compensación que deshagan explícitamente lo hecho antes.

Aquí es donde este sector se separa de todos los demás. En una operación funeraria hay pasos cuya compensación no existe, y el ejercicio útil es escribirlo en una tabla de tres columnas —paso, compensación disponible, quién la autoriza— y aceptar que algunas celdas de la segunda columna van a quedar vacías. Los pasos con la celda vacía son exactamente los que nunca deben ejecutarse desde un reintento automático: pasan por la compuerta de autorización del ERP y por una persona identificada. Esa lista corta, escrita y firmada, vale más que cualquier control técnico que se le ponga encima.

Al hacer ese ejercicio con datos reales aparecen dos sorpresas que conviene anticipar. La primera es que la reversibilidad no coincide con la intuición: los documentos que se pueden anular formalmente —factura, pago, nota de entrega— son los que mejor revierten, porque el ERP deshace sus asientos y sus movimientos de inventario; en cambio varios objetos operativos que parecen inofensivos, como el traslado o la velación, no tienen anulación en absoluto: el único «deshacer» es editar campos o borrar el registro. La segunda es que la reversibilidad depende del calendario: con el control de meses fiscales activo, anular una factura o un pago cuyo mes ya cerró simplemente no se permite. Lo que el lunes era reversible, el primer día del mes siguiente deja de serlo. Un duplicado detectado a tiempo se corrige; el mismo duplicado detectado en el cierre se convierte en una nota de crédito y en una explicación.

Y hay un tercer borde que suele olvidarse: los efectos que salen del ERP no los alcanza ninguna anulación. Cuando una factura o un contrato se integran con un sistema contable externo o con otra plataforma del grupo, el duplicado ya viajó. Por eso la regla del paso 6 se escribe al revés de como se suele pensar: no se trata de qué se puede deshacer dentro del sistema, sino de qué ya salió de él.

5. El bucle de mejora continua: qué se revisa cada semana

Un diseño de reintentos no se termina: se calibra. La revisión semanal es corta y siempre sobre lo mismo, y conviene que la haga la misma persona que responde por el cierre contable, no solo el área de tecnología:

1. Los duplicados que aparecieron. Corre el detector sobre los objetos de la sección 3 y mira los candidatos de la semana. Para cada uno, una sola pregunta: ¿vino de un reintento del agente, de un doble clic de una persona o de dos operaciones legítimas que se parecen? Las tres respuestas llevan a soluciones distintas.
2. Las operaciones que se quedaron sin respuesta. Es el indicador adelantado: cuenta cuántas llamadas con efecto terminaron sin resultado conocido. Si esa cifra sube, el problema no es el diseño del reintento sino la infraestructura, y se arregla en otro lado.
3. Los reintentos que ocurrieron. Cuántos, sobre qué operaciones y si todos llevaban clave. Un reintento sin clave sobre una operación de la lista corta del paso 0 es un incidente, aunque esa vez no haya producido nada.
4. Los falsos positivos del detector. Si marca como duplicados operaciones legítimas, la definición de «el mismo» está mal calibrada y hay que ajustarla. Un detector que nadie cree es un detector apagado.
5. El tiempo hasta la detección. No solo cuántos duplicados hubo, sino cuánto tardaron en descubrirse. Bajar de tres días a tres horas cambia el costo de cada incidente más que reducir su número.

Este bucle se apoya en la misma disciplina que describimos en el artículo sobre medir el procedimiento y no solo el resultado: lo que no se mide sobre la traza real, se mide sobre el relato del agente — y el relato siempre es más optimista.

6. Gobierno y límites: lo que nunca se reintenta solo

El diseño técnico necesita una política escrita encima, corta y sin excepciones tácitas. La nuestra cabe en cinco reglas:

• Ninguna operación con efecto se reintenta automáticamente sin clave de idempotencia. Sin clave, el fallo ambiguo se escala a una persona. No hay tercera opción, y no se negocia por conveniencia de un proyecto.
• Ningún efecto hacia afuera se reintenta solo. Mensajes y llamadas al doliente, transmisiones a la autoridad tributaria, despachos de flota y referencias de recaudo enviadas a la pasarela: si hay duda, decide una persona. Fuera del ERP no hay reversa.
• El reintento vive en una sola capa, declarada por escrito, y está desactivado en todas las demás.
• Los datos del doliente no entran en la clave. La clave de idempotencia viaja en registros técnicos y puede quedar en bitácoras: se construye con identificadores internos del ERP, nunca con documento de identidad, teléfono o causa de muerte. Es el mismo criterio que desarrollamos en el artículo sobre la supresión de datos personales.
• Cada reintento queda registrado como tal. Si la traza no distingue un reintento de una operación nueva, la revisión semanal es imposible y la auditoría posterior también.

7. Qué existe hoy en SFUN y qué todavía no

Lo decimos con los huecos por delante, como siempre, porque preferimos que un comité apruebe un proyecto sabiendo qué controles compra hoy y cuáles están en camino. Esto es lo verificado contra el código del producto el 20 de septiembre de 2026:

Hay un patrón en esa tabla que vale la pena nombrar, porque probablemente se repita en cualquier ERP maduro que audites: la idempotencia existe como islas, no como política. Cada equipo que se topó con el problema —el de inventario, el de facturación masiva, el de recaudo bancario, el de saldos de convenio— lo resolvió bien y por su cuenta, con un mecanismo distinto. Lo que falta no es inteligencia sino una regla transversal, y esa diferencia es exactamente lo que separa «no nos ha pasado» de «no nos puede pasar».

Dicho de la forma más útil para un comité de compra: hoy el riesgo se controla con diseño de proceso y con controles que ya existen; la clave de idempotencia es la pieza que convierte ese control en garantía, y es una pregunta válida para cualquier proveedor de software funerario que te ofrezca automatización con IA. Si la respuesta es «el modelo no comete errores», la conversación debería terminar ahí.

8. KPIs: línea base y meta

9. Hoja de ruta de adopción

• Semana 1. Inventario de operaciones con efecto y su clasificación por daño (paso 0). Definición escrita de «el mismo» para las cinco o diez más caras. Revisión de cuántas capas de la pila están reintentando hoy: es una pregunta al área de tecnología y suele tener una respuesta sorprendente.
• Mes 1. Detector de duplicados corriendo sobre esas operaciones, con revisión semanal y su primer número real. Verificación previa al reintento implementada en la lista corta. Reintento apagado en todas las capas menos una. Política de gobierno de la sección 6 firmada por la dirección.
• Trimestre 1. Clave de idempotencia en las operaciones con efecto, con su ventana de validez y su comparación de parámetros. Tabla de compensaciones de la saga, escrita, con las celdas vacías señaladas y la lista de pasos que nunca se reintentan. Los ocho indicadores en el tablero, con su línea base y su meta.

Los cinco errores más comunes

1. Creer que el problema es el modelo. Es el error de encuadre y el más caro, porque lleva a comprar la solución equivocada: un modelo mejor, un prompt más estricto, otro proveedor. El duplicado no lo causa el modelo, lo causa la ausencia de una clave. Cambiar de modelo no cambia nada.
2. Confiar en que el agente «no reintentará». Reintentar ante un fallo es el comportamiento esperado de un cliente bien hecho, y la propia especificación del protocolo lo sugiere. No es una conducta que se corrija pidiéndola.
3. Tratar todos los fallos igual. Bloquear el reintento en los errores de validación —que son la mayoría y son inofensivos— hace la automatización inútil y empuja al equipo a desactivar el control. La distinción del paso 1 es lo que hace el diseño sostenible.
4. Poner la clave y olvidar la ventana. Una clave con 24 horas de vida no protege contra el mismo error repetido tres días después, y una clave reutilizada para una operación distinta devuelve la respuesta equivocada sin que nadie lo note. La ventana y la comparación de parámetros son parte del diseño, no detalles.
5. Medir duplicados y no medir el tiempo hasta detectarlos. Diez duplicados detectados en dos horas cuestan mucho menos que dos descubiertos en el cierre del mes, cuando ya se facturó, se conciliaron los pagos y alguien tiene que explicar una nota de crédito.

Lo que otros sectores ya resolvieron

Este problema no es nuevo ni es de la IA: es el problema clásico de los sistemas distribuidos, y hay industrias que llevan años conviviendo con él en producción. Vale la pena mirarlas porque ahorran el diseño desde cero.

La conclusión que se lleva un comité es corta: la industria de pagos resolvió esto hace años y lo documenta en público; el protocolo con el que la IA opera los ERP todavía no. Mientras esa brecha exista, la responsabilidad es del ERP — y por eso es una pregunta de compra, no una curiosidad técnica.

Preguntas frecuentes

¿Qué es exactamente una clave de idempotencia?

Es un identificador único que se envía junto con una operación para decir «esta es esta operación, no una nueva». El servidor guarda el resultado bajo esa clave; si llega otra petición con la misma clave, devuelve el resultado guardado en lugar de ejecutar de nuevo. Sirve para que un reintento sea seguro: el segundo intento no produce un segundo efecto. Es el mecanismo que usan las pasarelas de pago para que un reintento tras un tiempo de espera agotado no cobre dos veces.

¿Por qué el agente reintenta si no sabe si la operación ocurrió?

Porque no tiene con qué decidir otra cosa. El resultado de una llamada a herramienta en el protocolo MCP trae el contenido y una marca de error, y no trae código de error, política de reintento, retardo sugerido ni indicación de si repetir es seguro. La propia especificación describe el error de ejecución como retroalimentación para que el modelo se autocorrija y reintente. Reintentar es la conducta que el diseño induce; corregirla requiere cambiar el diseño, no instruir al agente.

¿No basta con que una persona apruebe cada operación?

No, y por dos razones. La primera es que la aprobación ocurre antes de la llamada, mientras que el duplicado ocurre después: una persona puede aprobar una vez y el reintento producir dos efectos igual. La segunda es la fatiga: cuando se exige aprobación para todo, el operador aprueba en lote y sin leer, y se obtiene el ritual de la aprobación sin la aprobación. La aprobación humana es necesaria para las operaciones irreversibles; no es un sustituto del diseño del reintento.

Ya tenemos duplicados de antes de la IA. ¿Esto sirve para eso?

Sí, y suele ser el hallazgo más rentable del ejercicio. El doble clic de una persona con conexión lenta produce exactamente el mismo duplicado que el reintento de un agente, y la mayoría de los grupos descubre que ya los tenía. La definición de «el mismo» y el detector de duplicados del paso 0 funcionan igual sin agentes: son control interno clásico. La IA no trajo este problema, solo lo volvió más frecuente y más rápido.

¿Esto significa que no conviene dejar que el agente escriba en el ERP?

No. Significa que conviene decidir cómo escribe. Con la lista corta clasificada, la verificación previa al reintento, el borrador como paso intermedio y el reintento concentrado en una sola capa, el riesgo baja mucho sin renunciar al valor. El error caro es el opuesto: apagar toda la automatización de escritura tras el primer incidente y quedarse un año en modo consulta por un problema con solución conocida.

¿Esto aplica igual en todos los países de Latinoamérica?

El diseño sí: la ventana de ambigüedad y el reintento son idénticos en cualquier mercado. Lo que cambia por país es el costo del duplicado cuando toca un documento fiscal, porque el procedimiento para anular o acreditar una factura electrónica y sus plazos los fija cada autoridad tributaria. Por eso la factura duplicada es más cara en unos países que en otros, y por eso conviene revisar el procedimiento local de anulación con el asesor tributario de la compañía antes de definir qué operaciones de facturación puede ejecutar el agente.

En resumen

El duplicado que produce un agente de IA no es un fallo del modelo: es el resultado previsible de pedirle que decida sin información. Entre la llamada y la respuesta hay una ventana en la que nadie sabe si el efecto ocurrió, y el protocolo que conecta la IA con el ERP hoy no da ninguna señal para cerrarla. La respuesta no es desconfiar del agente ni apagarlo: es clasificar las operaciones por daño, distinguir el error explicado del silencio, verificar antes de reintentar, usar el borrador como amortiguador, concentrar el reintento en una sola capa y exigir la clave de idempotencia donde el efecto sea caro. Si quieres ver cómo encaja en la operación de tu grupo, conoce SFUN MCP y el módulo de gestión de servicios funerarios.

Fuentes de este artículo

• R. Mehan — Can MCP Clients Decide What to Do After Failure? A Result-Only Actionability Audit, arXiv:2609.00072, 31 de agosto de 2026 (cs.SE). Fuente de las cifras sobre 21 fallos en 10 servidores MCP: 18 de 21 permiten detectar el fallo con campos tipados y 0 de 21 exponen causa específica, reparación ejecutable o restricción de reejecución. El propio estudio excluye de su muestra los tiempos de espera agotados, los commits parciales y los casos de idempotencia incierta, de modo que no puede usarse para estimar con qué frecuencia una operación queda a medias: arxiv.org.
• Model Context Protocol — especificación, revisión vigente 2026-07-28, sección Tools. Fuente de la composición del resultado de tools/call y de la frase que describe los errores de ejecución como retroalimentación para que el modelo se autocorrija y reintente: modelcontextprotocol.io.
• SEP-3182 Request Idempotency, propuesta al protocolo MCP abierta el 1 de agosto de 2026 y cerrada el 23 de agosto de 2026. Se cerró por un motivo de proceso —propuesta generada con IA sin declararlo—, no por un rechazo técnico de la idea: github.com.
• I. K. Mansoor, A. Phadke y P. Rana — Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures, arXiv:2608.02645, 31 de julio de 2026 (cs.SE). Fuente del patrón de verificación de postcondiciones, verificar antes de reintentar y claves de idempotencia. Sus resultados son cualitativos y en entornos simulados con fallos inyectados: arxiv.org.
• Y. Chen et al. — Cordon: Semantic Transactions for Tool-Using LLM Agents, arXiv:2606.17573, 16 de junio de 2026 (cs.OS). Fuente del patrón de retención de efectos externos hasta su validación: arxiv.org.
• M. Brooker — Timeouts, retries, and backoff with jitter, Amazon Builders' Library. Fuente de que un tiempo de espera agotado no implica ausencia de efectos secundarios y de la amplificación de 243 veces con cinco capas y tres reintentos: aws.amazon.com.
• Stripe — documentación de peticiones idempotentes: qué se guarda bajo la clave, la purga a las 24 horas, la comparación de parámetros y el caso de los fallos de validación que no se almacenan: docs.stripe.com.
• Adyen — documentación de idempotencia de la API: vigencia de la clave y la cabecera que indica si el error fue transitorio: docs.adyen.com.
• PayPal — referencia de idempotencia: omitir la cabecera de identificación de la petición hace que la petición se duplique: developer.paypal.com.
• C. Richardson — patrón Saga: ausencia de reversión automática y necesidad de escribir transacciones de compensación: microservices.io.
• Advertencia de alcance: no existe ninguna cifra publicada sobre duplicados causados por agentes de IA en operaciones funerarias, ni un caso publicado con método en el sector. Las fuentes de pagos y de ingeniería distribuida se citan por el patrón y por el diseño, no para estimar resultados en una funeraria. La secuencia de la imagen de portada es ilustrativa.
• Las capacidades de SFUN descritas aquí se verificaron el 20 de septiembre de 2026 contra el código del producto. Lo que se presenta como hoja de ruta —la clave de idempotencia general, el detector de duplicados como función estándar y la señal de fallo transitorio— no existe hoy como función disponible.