ELAI S.r.l.

El agente cambia reglas a mitad de tarea: ¿una respuesta actualizada puede ser incoherente?

Un flujo ejecutado distingue coherencia, actualidad y permisos: fijar versión evita resultados híbridos, pero no autoriza acciones con reglas antiguas.

El agente cambia reglas a mitad de tarea: ¿una respuesta actualizada puede ser incoherente?

El problema no es solo recordar una regla antigua

Un agente prepara una solicitud en dos etapas: comprueba cantidad permitida y calcula una propuesta con un factor. Entre ambas cambian las reglas. Cada lectura usa lo más reciente, pero puede combinar aprobación antigua y cálculo nuevo: una respuesta que ninguna versión completa produciría. Explicamos por qué «leer siempre lo último» no equivale a «realizar una tarea coherente». Un flujo ejecutado distingue mezcla de versiones, reglas antiguas y permisos de ejecución.

Resumen. La cantidad sintética es900 unidades. v1 permite hasta1000 y factor1; v2 hasta600 y factor0,5. Enumeramos tres posiciones de actualización alrededor de dos lecturas y comparamos versión actual con snapshot copiado en la primera lectura. El primer método produce un híbrido en una de tres secuencias; el segundo en ninguna. Son recuentos construidos, no tasas medidas. Una comprobación separada muestra que una versión coherente puede estar desactualizada al actuar.

Tres significados distintos de correcto

Coherencia de lectura significa usar una versión de reglas pertinentes durante la tarea. Actualidad se refiere a la versión publicada ahora. Autorización decide si puede ejecutarse una acción en un momento y con permisos dados. Son distintas: un cálculo puede ser coherente pero viejo o usar datos recientes combinados mal. Incluso uno coherente y actual puede estar prohibido. Separar niveles evita atribuir al snapshot garantías inexistentes.

Para verificar eliminamos generación lingüística: el «agente» es un flujo determinista de dos funciones. No consulta LLM ni base de datos ni servicios externos. No reproduce todos los fallos de agentes: aísla lecturas y actualizaciones. Los valores no representan política empresarial o financiera, solo unidades convencionales y factores sintéticos. Así calculamos la tabla completa sin inventar clientes, operaciones o porcentajes de fiabilidad.

Dos versiones completas y una combinación inexistente

Una regla es el par límite L y factor f. La primera etapa devuelveq≤L; la segunda calculay=qf incluso si falla validación, siendo entonces dato diagnóstico, no orden ejecutable. Paraq=900, v1 produce(verdadero,900) yv2(falso,450). Examinar el par importa: cada componente aislado parece plausible.450 existe en v2, pero esa versión no permite solicitar900.

v1: L = 1000, f = 1; F_v1(900) = (true,900) v2: L = 600, f = 0.5; F_v2(900) = (false,450) Mixed reads: (900 ≤ 1000, 900 × 0.5) = (true,450)

Si v1 está vigente al leer primero,900≤1000 es verdadero. Después se publica v2 y la segunda etapa lee0,5 y calcula450. Cada función aplica bien su regla observada, pero el resultado(verdadero,450) no pertenece a ninguna versión completa. No hace falta alucinación: basta permitir que etapas dependientes cambien de base normativa.

La propiedad deseada se expresa como existencia de un identificador v único en el que se resuelvan ambas lecturas decisorias. Aquí también comprobamos pertenencia a{(verdadero,900),(falso,450)}, pero comparar valores no basta generalmente: distintas versiones pueden coincidir numéricamente. Un sistema real necesita procedencia de lecturas, no solo comparar salidas esperadas.

Read-consistency condition: ∃v such that version(read_i) = v for every relevant read_i

Enumerar actualizaciones sin inventar probabilidades

Con dos lecturas y una actualización consideramos tres secuencias: actualizar antes de la primera, entre lecturas o después de la segunda pero antes de actuar. Leer lo actual dav2-v2,v1-v2,v1-v1. Solo la central es híbrida. No es33% de probabilidad: no definimos distribución temporal ni observamos tráfico. Contar un caso en tres posiciones elegidas prueba que el problema puede existir.

La enumeración supone publicación atómica del par, lecturas seriales y versiones publicadas inmutables. Publicar campos por separado puede crear incoherencia en origen; modificar v1 sin cambiar identificador vuelve inútil «fijarv1». Los snapshots requieren unidades de publicación completas e identificadores estables de contenido inmutable.

Fijar un snapshot en la primera lectura

El segundo método copia identificador actual y valores en la primera lectura. Las etapas posteriores usan esa copia aunque cambie el puntero global. Actualizar antes fija v2; los otros casos fijan v1. La secuencia central devuelve(verdadero,900), coherente con v1, no el resultado actual(falso,450). Logramos específicamente coherencia de lectura, no actualidad automática.

copy.deepcopy evita conservar solo otra referencia al mismo diccionario mutable. Una versión realmente inmutable podría referenciarse directamente; copiamos para hacer explícita separación. Un archivo grande no necesita duplicar textos por tarea: manifiestos, índice identificado y direcciones estables pueden definir lecturas. Son arquitecturas posibles, no implementadas ni medidas aquí.

Actualizar antes deMetodoVersiones leidasPermitidoPropuestaCoherente
1currentv2 / v2False450True
1snapshotv2 / v2False450True
2currentv1 / v2True450False
2snapshotv1 / v1True900True
3currentv1 / v1True900True
3snapshotv1 / v1True900True

En la tabla1 y2 son etapas;3 es después de lecturas y antes de acción hipotética. True y False son booleanos, no confianzas. La fila central current lee v1/v2, propone450 y permite. La siguiente snapshot conserva v1/v1 y900. Sin interferencia ambos métodos coinciden. La ventaja es selectiva: elimina combinación intermedia, no cambia arbitrariamente respuestas.

La versión coherente puede no servir para actuar ahora

Tras calcular todo con v1, antes de actuar puede regir v2. El resultado es coherente, pero900 no se permite bajo reglas nuevas. Depende del contrato: terminar con reglas iniciales, revalidar o revocar de inmediato permisos anteriores. El número no elige política. Debe explicitarse antes y registrarse con versión, no inventarse después para justificar acción.

Fresh-version gate = all read versions equal AND pinned_version = current_version Action authorization ≠ fresh-version gate alone

El programa calcula además un filtro: lecturas del mismo identificador que aún sea actual en el punto observado. Es diagnóstico. v2-v2 lo supera pero permitido es falso, así que no autoriza acción. Una autorización real necesita controles, permisos, estado de recurso y condiciones específicas. Un booleano de coherencia no sustituye esas decisiones.

Queda otra carrera: reglas pueden cambiar entre comprobar versión y actuar. El experimento termina en observación y no ejecuta efectos, así que no cierra esa ventana. Implementar exige vincular revalidación y registro mediante atomicidad, concurrencia o protocolo entre servicios. Escribir «comprueba y actúa» no demuestra atomicidad. Así evitamos convertir el ejemplo en promesa de seguridad.

La analogía transaccional tiene un límite

PostgreSQL18, documentación primaria13.2, ofrece analogía: SELECT sucesivos en Read Committed pueden ver snapshots distintos; Repeatable Read comparte el de la primera instrucción no de control. Leímos también límites de serialización. Aclara actualidad frente a estabilidad, pero el código no usa PostgreSQL ni mide transacciones. Un snapshot entre herramientas no hereda aislamiento, rollback o serializabilidad por citar una base de datos.

Un agente puede buscar en índice, extraer campo de API y leer permisos de otro servicio. «Versión7» no alinea fuentes que evolucionan independientemente. Hay que definir manifiesto de versiones compatibles o autoridad que fija frontera decisoria. Fechas no reconstruyen una vista sin especificar significado y disponibilidad. El modelo de catálogo único excluye esa complejidad: debe resolverse antes de generalizar a sistemas distribuidos.

Reanudar la tarea y conservar procedencia

Si se interrumpe tras primera etapa, reanudar con reglas últimas puede recrear el híbrido. Un checkpoint debe incluir identificador fijado, entradas y política de revalidación. No exige retener indiscriminadamente todo: conservar lo necesario bajo restricciones aplicables. Si la versión original ya no está disponible, no fingir reutilizarla: reiniciar explícitamente bajo nueva versión o parar según política.

La procedencia también acompaña fragmentos: documento, revisión, índice y transformaciones de la evidencia. Fijar documentos no asegura interpretación correcta ni texto idéntico. Reproducibilidad lingüística necesita más información y puede depender de infraestructura. El resultado solo trata catálogo y secuencia determinista. Ese alcance delimitado lo hace útil, no explicación universal de errores de agentes.

Versiones leídas en dos etapas: cada fila es una posición de actualización enumerada. Izquierda lee actual; derecha fija snapshot inicial. Solo cambia color la fila central sin fijación. Ejes categóricos, no tiempos ni probabilidades. Datos del flujo sintético ejecutado. Abrir para ampliar.
Versiones leídas en dos etapas: cada fila es una posición de actualización enumerada. Izquierda lee actual; derecha fija snapshot inicial. Solo cambia color la fila central sin fijación. Ejes categóricos, no tiempos ni probabilidades. Datos del flujo sintético ejecutado. Abrir para ampliar.

Comprobar código y límites de la demostración

run recibe posición y booleano pinned. Empieza en v1, cambia puntero cuando corresponde y registra identificadores reales. El snapshot nace solo en primera lectura. Seis casos verifican híbrido current y ausencia en pinned, guardando valores, versiones y filtro en JSON. Sin hilos ni esperas: la secuencia hace reproducible una interferencia concurrente real.

Para n lecturas de S datos copiados, materializar cuesta O(S) tiempo y memoria antes de n accesos. Aquí ambos son dos, pero no inferimos milisegundos. Referenciar objetos inmutables cambia coste sin cambiar necesariamente propiedad lógica. Habría que medir memoria de versiones, adquisición, retraso de publicación y revalidaciones, separados de calidad de respuestas.

Extender prueba busca contraejemplos, no repetir casos favorables. Más lecturas permiten actualizar en cada corte, retirar versiones, desalinear índice o revocar permisos. Son propuestas, no resultados ejecutados: JSON solo contiene seis ejecuciones declaradas. No medimos latencia de base, precisión LLM, seguridad de herramientas ni usuarios reales.

La respuesta: estabilidad al razonar, controles al actuar

Sí: lecturas individualmente actuales pueden producir una respuesta incoherente. El ejemplo mezcla aprobación v1 y factor v2 en un par inexistente. Un snapshot evita ese cambio específico y permite reconstruir razonamiento. No decide si todavía se permite usar versión al actuar. Coherencia, actualidad y autorización siguen siendo preguntas distintas. No demuestra funcionalidad EL-AI disponible: ofrece experimento reproducible y distinción arquitectónica verificable.

PostgreSQL18 documentation §13.2 Transaction Isolation: Read Committed, Repeatable Read, Serializable; primary documentation read16October2026.

from experiment import run
for when in [1,2,3]:
    for pinned in [False,True]:
        x=run(when,pinned)
        print(when,pinned,x['read_versions'],x['approved'],x['quote_units'],x['coherent'])

Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 16 de octubre de 2026.