{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation","title":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","description":"Un diseño de ejecución para herramientas con efectos reales: identidad fuera del prompt, acciones inmutables, control de concurrencia y recuperación cuando un timeout deja el resultado en duda.","language":"es","datePublished":"2026-10-14","dateModified":null,"contentFormat":"text/markdown","content":"IA Agéntica\n\n# Agentes que escriben en producción: autorización, idempotencia y reconciliación\n\n2026-10-147 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/agent-tool-execution-authorization-idempotency-reconciliation>)\n\n## El timeout no leyó tu system prompt\n\nUn agente propone actualizar un registro. La API aplica el cambio y la conexión se corta antes de devolver la respuesta. El agente ve un error y prueba otra vez. El dashboard muestra dos llamadas exitosas. El negocio recibe dos efectos.\n\nLa parte probabilística eligió una acción. La parte determinista no supo ejecutarla. Cambiar de modelo puede producir una explicación más elegante del mismo incidente.\n\n**Una herramienta de escritura necesita un protocolo de ejecución que sobreviva a reintentos, concurrencia y respuestas perdidas.** En este artículo propongo ese protocolo para un agente que modifica configuración operativa. Los ejemplos son diseños ilustrativos, sin resultados de producción atribuidos.\n\n## Separar propuesta, autorización y ejecución\n\nEl modelo produce una propuesta. Un servicio de control la normaliza, la vincula con la identidad autenticada y decide si está permitida. Un ejecutor aplica una operación concreta y registra su resultado.\n\n```text\nsolicitud del usuario\n  -> propuesta del modelo\n  -> validación y política\n  -> acción inmutable autorizada\n  -> ejecutor\n  -> recibo o reconciliación\n```\n\nLa descripción de la herramienta sirve para orientar al modelo. La política se aplica en código, junto al límite donde se produce el efecto. “Solo usar cuando corresponda” dentro de un prompt no es un control de acceso particularmente auditable.\n\nCada delegación recibe la intersección entre los permisos del usuario, los del servicio y los de la tarea. Un subagente puede tener menos autoridad que su padre. La decisión de crear un hijo no le concede autoridad adicional.\n\n## MCP resuelve una parte del contrato\n\nLa [especificación MCP de autorización de julio de 2026](<https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization>) define autorización para transportes HTTP y vinculación de tokens al recurso. Sus [recomendaciones de seguridad](<https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices>) prohíben el token passthrough y describen riesgos de confused deputy.\n\nSobre esa capa, la aplicación todavía tiene que resolver una pregunta de dominio: ¿este usuario puede cambiar este atributo de este recurso, bajo estas condiciones? Un token válido para el servidor no responde automáticamente todo eso.\n\nPor ejemplo, el acceso a ` inventory.write ` puede permitir editar existencias en un depósito concreto, sin habilitar otro tenant ni cualquier magnitud de ajuste. La política también puede requerir revisión para determinadas operaciones. Esos límites pertenecen al servicio y no dependen de la explicación que acompañe el tool call.\n\n## Autorizar exactamente lo que va a ejecutarse\n\nEl servicio transforma la propuesta en un registro inmutable. Este JSON muestra campos conceptuales; los identificadores son ficticios:\n\n```json\n{\n  \"operationId\": \"op_example_01\",\n  \"principalId\": \"user_example\",\n  \"tenantId\": \"tenant_example\",\n  \"tool\": \"inventory.set_available\",\n  \"resource\": \"warehouse_example/item_example\",\n  \"arguments\": { \"available\": 18 },\n  \"expectedVersion\": 42,\n  \"policyVersion\": \"inventory-policy-v3\",\n  \"authorizationId\": \"authz_example_01\",\n  \"expiresAt\": \"2026-10-14T18:05:00Z\"\n}\n```\n\nEl servidor genera ` operationId `. Obtiene identidad y tenant de la sesión autenticada. Una representación canónica de la acción permite calcular un digest que vincula la autorización con herramienta, recurso, argumentos y precondiciones. Un hash aislado no prueba quién autorizó: el registro vive en almacenamiento confiable o viaja con autenticidad verificable.\n\nCuando la política exige aprobación humana, la interfaz muestra el cambio concreto y su alcance. Aprobar “resolver el problema” no habilita cualquier escritura que el modelo encuentre conveniente después.\n\nEl ejecutor comprueba vigencia y revocación antes de aplicar una operación pendiente. Si cambian los argumentos, la autorización anterior deja de cubrirla. Si cambia una política relevante, se reevalúa. Un recibo ya confirmado se conserva aunque después caduque el permiso que permitió producirlo.\n\n## Cerrar la ventana entre leer y escribir\n\nEn el ejemplo, el agente leyó la versión 42 del inventario. Antes de ejecutar, otra operación crea la versión 43. Aplicar la propuesta original sin comprobar su precondición puede sobrescribir información que el agente nunca vio.\n\nEl almacenamiento debe comparar y modificar de forma atómica. En HTTP, [` If-Match `](<https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1>) permite condicionar una escritura a un ETag fuerte. Una precondición falsa impide aplicar la modificación; el servidor puede responder ` 412 `.\n\nEn una implementación propia, usaría una actualización condicionada por tenant, identificador y versión, dentro de la misma transacción que registra el resultado de la operación. Si ninguna fila coincide, la acción necesita una nueva lectura y una nueva decisión. Comprobar la versión en un ` GET ` y hacer luego un ` PUT ` incondicional deja abierta la carrera.\n\nUn rechazo de versión no es una invitación a reemplazar ` 42 ` por ` 43 ` y seguir. El significado de la acción pudo cambiar. La automatización necesita una regla explícita para resolver ese conflicto o devolverlo al usuario.\n\n## Una máquina de estados que admita la incertidumbre\n\nPropongo estos estados para el registro de operaciones:\n\n| Estado | Qué sabemos | Próximo paso permitido |\n| --- | --- | --- |\n| ` proposed ` | Hay argumentos candidatos | Validar y autorizar |\n| ` authorized ` | La acción exacta está permitida | Reclamar ejecución dentro de vigencia |\n| ` executing ` | Un ejecutor inició el intento | Esperar recibo o investigar |\n| ` succeeded ` | Existe confirmación del efecto | Devolver el recibo existente |\n| ` rejected ` | Se negó la operación antes del efecto | Informar la causa |\n| ` unknown ` | El efecto puede haber ocurrido | Reconciliar antes de decidir |\n\nUn timeout, una pérdida de conexión o un proceso muerto pueden terminar en ` unknown `. Marcar todo como ` failed ` vuelve peligrosa la política de reintentos. “No recibí confirmación” contiene menos información que “no ocurrió”. Conviene que la base de datos también entienda la diferencia.\n\nLa clave ` (tenantId, operationId) ` identifica una intención autorizada. El ledger impide reclamarla simultáneamente y conserva su recibo. El modelo no genera una identidad nueva cada vez que le devolvés el mismo error.\n\n## El límite de la transacción local\n\nLa [Amazon Builders' Library](<https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/>) describe APIs con identificadores de solicitud reutilizables y rechazo cuando una misma identidad llega con parámetros distintos. La lección aplicable es preservar la intención a través de los reintentos.\n\nPara una escritura en tu propia base, el registro de deduplicación y la mutación pueden compartir transacción. Para una API externa, tu ledger local no controla el commit remoto. Ahí aparece la parte que los diagramas suelen esconder debajo de una flecha.\n\nUna outbox puede guardar atómicamente la intención de envío junto con el estado local. Su entrega todavía puede repetirse. Necesitás soporte de idempotencia en el receptor o una operación cuya repetición sea segura, con un contrato documentado.\n\nSi el proveedor conserva claves por un tiempo limitado, tu recuperación debe respetar ese plazo. Después de su vencimiento, reutilizar la clave podría ejecutar otra vez. Una lease local vencida tampoco prueba que el trabajador anterior dejó de actuar; hacen falta garantías en el receptor, como deduplicación o fencing cuando lo soporte.\n\n## Reconciliar por operación, no por parecido\n\nEl reconciliador consulta el recibo remoto mediante la identidad de la operación. Si encuentra un efecto confirmado, lo incorpora al ledger. Si demuestra que no hubo efecto y el contrato permite reintentar, reutiliza la misma identidad dentro de su ventana válida.\n\nObservar que el inventario quedó en 18 no demuestra que nuestra escritura haya ocurrido. Otra operación pudo producir ese valor. La evidencia tiene que atribuir el efecto a la solicitud concreta.\n\nCuando el proveedor no ofrece deduplicación ni consulta fiable, la incertidumbre puede exigir intervención humana. Compensar también es otra operación con permisos, fallos y posibles efectos concurrentes. Un correo enviado no vuelve a la bandeja de salida porque alguien escribió ` rollback() `.\n\n## Qué exigiría antes de habilitar autonomía\n\nEjercitaría cortes antes del envío, después del efecto remoto y antes de persistir el recibo. Sumaría trabajadores concurrentes, autorizaciones vencidas, recursos modificados, parámetros alterados y claves fuera de retención.\n\nEl informe tendría que mostrar operaciones inciertas, efectos duplicados, escrituras rechazadas y tiempo de reconciliación. Los criterios de aceptación se fijan por operación y por proveedor. Las garantías terminan donde termina el contrato que realmente podés hacer cumplir.\n\nMi requisito para una herramienta autónoma de escritura es concreto: **poder explicar quién autorizó qué, sobre qué versión, cuántas veces se intentó y qué evidencia confirma el efecto**. Si falta esa explicación, todavía hay trabajo de sistemas distribuidos pendiente. El prompt puede esperar.\n\nLecturas relacionadas: [function calling y orquestación](<https://lucioduran.com/es/blog/llm-function-calling-tool-use-patterns>) y [event sourcing y registros de eventos](<https://lucioduran.com/es/blog/event-sourcing-cqrs-production-lessons>).\n\n## Preguntas frecuentes\n\n### ¿Un JSON Schema válido hace segura una herramienta?\n\nNo. El esquema puede restringir la forma de la solicitud, pero el ejecutor debe comprobar identidad, permisos, recurso, precondiciones y límites de la operación.\n\n### ¿Una clave de idempotencia garantiza exactamente una ejecución?\n\nNo por sí sola. El sistema que produce el efecto debe aplicar la deduplicación con garantías conocidas. También importan el alcance de la clave, la retención y el manejo de operaciones pendientes.\n\n### ¿Qué hacer si una API externa no permite deduplicar ni consultar operaciones?\n\nTratar el resultado incierto como un caso de conciliación manual o rediseñar la integración. Reintentar automáticamente una escritura puede duplicar el efecto.\n\n## Tips\n\n1. El tenant y la identidad salen del contexto autenticado. Nunca de un campo que pueda inventar el modelo.\n2. Un timeout deja una operación en duda. Conservá su identidad hasta reconciliar el efecto externo.\n3. Una aprobación queda ligada a argumentos, recurso y versión. Cambiar cualquiera de ellos exige reevaluar la autorización.\n\n- agentic-ai\n- tool-execution\n- mcp\n- authorization\n- idempotency\n- distributed-systems\n- reconciliation\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#title"},{"level":2,"text":"El timeout no leyó tu system prompt","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#el-timeout-no-ley-tu-system-prompt"},{"level":2,"text":"Separar propuesta, autorización y ejecución","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#separar-propuesta-autorizacin-y-ejecucin"},{"level":2,"text":"MCP resuelve una parte del contrato","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#mcp-resuelve-una-parte-del-contrato"},{"level":2,"text":"Autorizar exactamente lo que va a ejecutarse","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#autorizar-exactamente-lo-que-va-a-ejecutarse"},{"level":2,"text":"Cerrar la ventana entre leer y escribir","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#cerrar-la-ventana-entre-leer-y-escribir"},{"level":2,"text":"Una máquina de estados que admita la incertidumbre","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#una-mquina-de-estados-que-admita-la-incertidumbre"},{"level":2,"text":"El límite de la transacción local","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#el-lmite-de-la-transaccin-local"},{"level":2,"text":"Reconciliar por operación, no por parecido","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#reconciliar-por-operacin-no-por-parecido"},{"level":2,"text":"Qué exigiría antes de habilitar autonomía","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#qu-exigira-antes-de-habilitar-autonoma"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#questions"},{"level":3,"text":"¿Un JSON Schema válido hace segura una herramienta?","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-1"},{"level":3,"text":"¿Una clave de idempotencia garantiza exactamente una ejecución?","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-2"},{"level":3,"text":"¿Qué hacer si una API externa no permite deduplicar ni consultar operaciones?","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#article-tips"}],"sections":[{"heading":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","level":1,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation","content":"IA Agéntica"},{"heading":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","level":1,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#title","content":"2026-10-147 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/agent-tool-execution-authorization-idempotency-reconciliation>)"},{"heading":"El timeout no leyó tu system prompt","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#el-timeout-no-ley-tu-system-prompt","content":"Un agente propone actualizar un registro. La API aplica el cambio y la conexión se corta antes de devolver la respuesta. El agente ve un error y prueba otra vez. El dashboard muestra dos llamadas exitosas. El negocio recibe dos efectos.\n\nLa parte probabilística eligió una acción. La parte determinista no supo ejecutarla. Cambiar de modelo puede producir una explicación más elegante del mismo incidente.\n\n**Una herramienta de escritura necesita un protocolo de ejecución que sobreviva a reintentos, concurrencia y respuestas perdidas.** En este artículo propongo ese protocolo para un agente que modifica configuración operativa. Los ejemplos son diseños ilustrativos, sin resultados de producción atribuidos."},{"heading":"Separar propuesta, autorización y ejecución","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#separar-propuesta-autorizacin-y-ejecucin","content":"El modelo produce una propuesta. Un servicio de control la normaliza, la vincula con la identidad autenticada y decide si está permitida. Un ejecutor aplica una operación concreta y registra su resultado.\n\n```text\nsolicitud del usuario\n  -> propuesta del modelo\n  -> validación y política\n  -> acción inmutable autorizada\n  -> ejecutor\n  -> recibo o reconciliación\n```\n\nLa descripción de la herramienta sirve para orientar al modelo. La política se aplica en código, junto al límite donde se produce el efecto. “Solo usar cuando corresponda” dentro de un prompt no es un control de acceso particularmente auditable.\n\nCada delegación recibe la intersección entre los permisos del usuario, los del servicio y los de la tarea. Un subagente puede tener menos autoridad que su padre. La decisión de crear un hijo no le concede autoridad adicional."},{"heading":"MCP resuelve una parte del contrato","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#mcp-resuelve-una-parte-del-contrato","content":"La [especificación MCP de autorización de julio de 2026](<https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization>) define autorización para transportes HTTP y vinculación de tokens al recurso. Sus [recomendaciones de seguridad](<https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices>) prohíben el token passthrough y describen riesgos de confused deputy.\n\nSobre esa capa, la aplicación todavía tiene que resolver una pregunta de dominio: ¿este usuario puede cambiar este atributo de este recurso, bajo estas condiciones? Un token válido para el servidor no responde automáticamente todo eso.\n\nPor ejemplo, el acceso a ` inventory.write ` puede permitir editar existencias en un depósito concreto, sin habilitar otro tenant ni cualquier magnitud de ajuste. La política también puede requerir revisión para determinadas operaciones. Esos límites pertenecen al servicio y no dependen de la explicación que acompañe el tool call."},{"heading":"Autorizar exactamente lo que va a ejecutarse","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#autorizar-exactamente-lo-que-va-a-ejecutarse","content":"El servicio transforma la propuesta en un registro inmutable. Este JSON muestra campos conceptuales; los identificadores son ficticios:\n\n```json\n{\n  \"operationId\": \"op_example_01\",\n  \"principalId\": \"user_example\",\n  \"tenantId\": \"tenant_example\",\n  \"tool\": \"inventory.set_available\",\n  \"resource\": \"warehouse_example/item_example\",\n  \"arguments\": { \"available\": 18 },\n  \"expectedVersion\": 42,\n  \"policyVersion\": \"inventory-policy-v3\",\n  \"authorizationId\": \"authz_example_01\",\n  \"expiresAt\": \"2026-10-14T18:05:00Z\"\n}\n```\n\nEl servidor genera ` operationId `. Obtiene identidad y tenant de la sesión autenticada. Una representación canónica de la acción permite calcular un digest que vincula la autorización con herramienta, recurso, argumentos y precondiciones. Un hash aislado no prueba quién autorizó: el registro vive en almacenamiento confiable o viaja con autenticidad verificable.\n\nCuando la política exige aprobación humana, la interfaz muestra el cambio concreto y su alcance. Aprobar “resolver el problema” no habilita cualquier escritura que el modelo encuentre conveniente después.\n\nEl ejecutor comprueba vigencia y revocación antes de aplicar una operación pendiente. Si cambian los argumentos, la autorización anterior deja de cubrirla. Si cambia una política relevante, se reevalúa. Un recibo ya confirmado se conserva aunque después caduque el permiso que permitió producirlo."},{"heading":"Cerrar la ventana entre leer y escribir","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#cerrar-la-ventana-entre-leer-y-escribir","content":"En el ejemplo, el agente leyó la versión 42 del inventario. Antes de ejecutar, otra operación crea la versión 43. Aplicar la propuesta original sin comprobar su precondición puede sobrescribir información que el agente nunca vio.\n\nEl almacenamiento debe comparar y modificar de forma atómica. En HTTP, [` If-Match `](<https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1>) permite condicionar una escritura a un ETag fuerte. Una precondición falsa impide aplicar la modificación; el servidor puede responder ` 412 `.\n\nEn una implementación propia, usaría una actualización condicionada por tenant, identificador y versión, dentro de la misma transacción que registra el resultado de la operación. Si ninguna fila coincide, la acción necesita una nueva lectura y una nueva decisión. Comprobar la versión en un ` GET ` y hacer luego un ` PUT ` incondicional deja abierta la carrera.\n\nUn rechazo de versión no es una invitación a reemplazar ` 42 ` por ` 43 ` y seguir. El significado de la acción pudo cambiar. La automatización necesita una regla explícita para resolver ese conflicto o devolverlo al usuario."},{"heading":"Una máquina de estados que admita la incertidumbre","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#una-mquina-de-estados-que-admita-la-incertidumbre","content":"Propongo estos estados para el registro de operaciones:\n\n| Estado | Qué sabemos | Próximo paso permitido |\n| --- | --- | --- |\n| ` proposed ` | Hay argumentos candidatos | Validar y autorizar |\n| ` authorized ` | La acción exacta está permitida | Reclamar ejecución dentro de vigencia |\n| ` executing ` | Un ejecutor inició el intento | Esperar recibo o investigar |\n| ` succeeded ` | Existe confirmación del efecto | Devolver el recibo existente |\n| ` rejected ` | Se negó la operación antes del efecto | Informar la causa |\n| ` unknown ` | El efecto puede haber ocurrido | Reconciliar antes de decidir |\n\nUn timeout, una pérdida de conexión o un proceso muerto pueden terminar en ` unknown `. Marcar todo como ` failed ` vuelve peligrosa la política de reintentos. “No recibí confirmación” contiene menos información que “no ocurrió”. Conviene que la base de datos también entienda la diferencia.\n\nLa clave ` (tenantId, operationId) ` identifica una intención autorizada. El ledger impide reclamarla simultáneamente y conserva su recibo. El modelo no genera una identidad nueva cada vez que le devolvés el mismo error."},{"heading":"El límite de la transacción local","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#el-lmite-de-la-transaccin-local","content":"La [Amazon Builders' Library](<https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/>) describe APIs con identificadores de solicitud reutilizables y rechazo cuando una misma identidad llega con parámetros distintos. La lección aplicable es preservar la intención a través de los reintentos.\n\nPara una escritura en tu propia base, el registro de deduplicación y la mutación pueden compartir transacción. Para una API externa, tu ledger local no controla el commit remoto. Ahí aparece la parte que los diagramas suelen esconder debajo de una flecha.\n\nUna outbox puede guardar atómicamente la intención de envío junto con el estado local. Su entrega todavía puede repetirse. Necesitás soporte de idempotencia en el receptor o una operación cuya repetición sea segura, con un contrato documentado.\n\nSi el proveedor conserva claves por un tiempo limitado, tu recuperación debe respetar ese plazo. Después de su vencimiento, reutilizar la clave podría ejecutar otra vez. Una lease local vencida tampoco prueba que el trabajador anterior dejó de actuar; hacen falta garantías en el receptor, como deduplicación o fencing cuando lo soporte."},{"heading":"Reconciliar por operación, no por parecido","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#reconciliar-por-operacin-no-por-parecido","content":"El reconciliador consulta el recibo remoto mediante la identidad de la operación. Si encuentra un efecto confirmado, lo incorpora al ledger. Si demuestra que no hubo efecto y el contrato permite reintentar, reutiliza la misma identidad dentro de su ventana válida.\n\nObservar que el inventario quedó en 18 no demuestra que nuestra escritura haya ocurrido. Otra operación pudo producir ese valor. La evidencia tiene que atribuir el efecto a la solicitud concreta.\n\nCuando el proveedor no ofrece deduplicación ni consulta fiable, la incertidumbre puede exigir intervención humana. Compensar también es otra operación con permisos, fallos y posibles efectos concurrentes. Un correo enviado no vuelve a la bandeja de salida porque alguien escribió ` rollback() `."},{"heading":"Qué exigiría antes de habilitar autonomía","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#qu-exigira-antes-de-habilitar-autonoma","content":"Ejercitaría cortes antes del envío, después del efecto remoto y antes de persistir el recibo. Sumaría trabajadores concurrentes, autorizaciones vencidas, recursos modificados, parámetros alterados y claves fuera de retención.\n\nEl informe tendría que mostrar operaciones inciertas, efectos duplicados, escrituras rechazadas y tiempo de reconciliación. Los criterios de aceptación se fijan por operación y por proveedor. Las garantías terminan donde termina el contrato que realmente podés hacer cumplir.\n\nMi requisito para una herramienta autónoma de escritura es concreto: **poder explicar quién autorizó qué, sobre qué versión, cuántas veces se intentó y qué evidencia confirma el efecto**. Si falta esa explicación, todavía hay trabajo de sistemas distribuidos pendiente. El prompt puede esperar.\n\nLecturas relacionadas: [function calling y orquestación](<https://lucioduran.com/es/blog/llm-function-calling-tool-use-patterns>) y [event sourcing y registros de eventos](<https://lucioduran.com/es/blog/event-sourcing-cqrs-production-lessons>)."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#questions","content":""},{"heading":"¿Un JSON Schema válido hace segura una herramienta?","level":3,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-1","content":"No. El esquema puede restringir la forma de la solicitud, pero el ejecutor debe comprobar identidad, permisos, recurso, precondiciones y límites de la operación."},{"heading":"¿Una clave de idempotencia garantiza exactamente una ejecución?","level":3,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-2","content":"No por sí sola. El sistema que produce el efecto debe aplicar la deduplicación con garantías conocidas. También importan el alcance de la clave, la retención y el manejo de operaciones pendientes."},{"heading":"¿Qué hacer si una API externa no permite deduplicar ni consultar operaciones?","level":3,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#question-3","content":"Tratar el resultado incierto como un caso de conciliación manual o rediseñar la integración. Reintentar automáticamente una escritura puede duplicar el efecto."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#article-tips","content":"1. El tenant y la identidad salen del contexto autenticado. Nunca de un campo que pueda inventar el modelo.\n2. Un timeout deja una operación en duda. Conservá su identidad hasta reconciliar el efecto externo.\n3. Una aprobación queda ligada a argumentos, recurso y versión. Cambiar cualquiera de ellos exige reevaluar la autorización.\n\n- agentic-ai\n- tool-execution\n- mcp\n- authorization\n- idempotency\n- distributed-systems\n- reconciliation\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/agent-tool-execution-authorization-idempotency-reconciliation"},{"text":"especificación MCP de autorización de julio de 2026","url":"https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"},{"text":"recomendaciones de seguridad","url":"https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices"},{"text":"If-Match","url":"https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1"},{"text":"Amazon Builders' Library","url":"https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/"},{"text":"function calling y orquestación","url":"https://lucioduran.com/es/blog/llm-function-calling-tool-use-patterns"},{"text":"event sourcing y registros de eventos","url":"https://lucioduran.com/es/blog/event-sourcing-cqrs-production-lessons"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation"},"headline":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","description":"Un diseño de ejecución para herramientas con efectos reales: identidad fuera del prompt, acciones inmutables, control de concurrencia y recuperación cuando un timeout deja el resultado en duda.","datePublished":"2026-10-14","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://lucioduran.com/favicons/og-default.png","url":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"IA Agéntica","keywords":"agentic-ai, tool-execution, mcp, authorization, idempotency, distributed-systems, reconciliation","wordCount":1284,"timeRequired":"PT7M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/agent-tool-execution-authorization-idempotency-reconciliation"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Agentes que escriben en producción: autorización, idempotencia y reconciliación","item":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Un JSON Schema válido hace segura una herramienta?","acceptedAnswer":{"@type":"Answer","text":"No. El esquema puede restringir la forma de la solicitud, pero el ejecutor debe comprobar identidad, permisos, recurso, precondiciones y límites de la operación."}},{"@type":"Question","name":"¿Una clave de idempotencia garantiza exactamente una ejecución?","acceptedAnswer":{"@type":"Answer","text":"No por sí sola. El sistema que produce el efecto debe aplicar la deduplicación con garantías conocidas. También importan el alcance de la clave, la retención y el manejo de operaciones pendientes."}},{"@type":"Question","name":"¿Qué hacer si una API externa no permite deduplicar ni consultar operaciones?","acceptedAnswer":{"@type":"Answer","text":"Tratar el resultado incierto como un caso de conciliación manual o rediseñar la integración. Reintentar automáticamente una escritura puede duplicar el efecto."}}]}]}],"contentHash":"69f8998aa1151ae4645204f9a99c038db12511f97fee92d0b99308fe35c97327","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/agent-tool-execution-authorization-idempotency-reconciliation","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":59766,"contentBytes":11319}}