An agent changes rules mid-task: can an up-to-date answer be inconsistent?

The problem is not merely remembering an old rule

An agent prepares a request in two stages: first checking whether a quantity is permitted, then calculating a proposal using a factor. Rules change between stages. Every read uses the latest available version, yet the result can combine old approval with a new calculation—an answer no complete rule version would produce. We explain why “always read the latest” differs from “complete a consistent task”. An executed workflow separates this issue from stale rules and execution permissions.

Abstract. A synthetic quantity is900 units. Versionv1 allows up to1000 with factor1; v2 allows up to600 with factor0.5. We enumerate three update placements around two reads, comparing current-version access with a snapshot copied on the first read. The first method produces a hybrid in one of three schedules; the second in none. These count constructed schedules, not measured error rates. A separate check shows a consistent version may still be outdated when an action occurs.

Three different meanings of correct

Read consistency means using one version of relevant rules throughout a task. Freshness concerns the currently published version. Authorization determines whether a particular action may occur at a time with given permissions. These differ: a calculation can be consistent but old, or use recent data yet combine it badly. Even a consistent, fresh result can be forbidden for other reasons. Separating these levels avoids assigning snapshots guarantees they do not provide.

To make the example verifiable, we remove language generation: our “agent” is a deterministic two-function workflow. It queries no LLM or database and calls no external service. This does not reproduce every agent failure; it isolates reads interacting with updates. Values represent no business or financial policy, only conventional units and synthetic factors. We can therefore calculate the entire outcome table without inventing customers, operations or reliability percentages.

Two complete versions and a nonexistent combination

A rule is a pair: limit L and factor f. Stage one returns whetherq≤L; stage two computes proposaly=qf even when validation is false, in which case it is diagnostic intermediate data, not an executable order. Forq=900, v1 yields(true,900), v2(false,450). Inspecting the complete pair matters because each component alone looks plausible.450 exists under v2, but that version does not permit a900-unit request.

Suppose v1 is current at the first read:900≤1000 is true. Then v2 is published; stage two reads factor0.5 and computes450. Each function correctly applied its observed rule, yet combined result(true,450) belongs to neither complete version. No model hallucination is needed: a read policy allowing dependent stages to switch rule bases suffices.

Desired behavior is clearer as existence of one version identifier v on which both decision reads resolve. Our example also tests whether output belongs to{(true,900),(false,450)}, but value membership is insufficient generally: different versions may coincidentally yield the same number. Real systems need read provenance, not just output comparison with expected values.

Enumerating updates without inventing probabilities

For two reads and one update, consider three serialized schedules: update before the first read, between reads, or after the second but before a possible action. Reading current versions yieldsv2-v2,v1-v2,v1-v1. Only the middle schedule is hybrid. This is not a33% error probability: no timing distribution or real traffic was observed. Counting one of three chosen update positions proves the problem can exist.

The enumeration assumes atomic publication of the limit-factor pair, serialized reads and immutable contents of published versions. Publishing fields separately could create inconsistency at the source. Editing v1 without changing its identifier makes “pinv1” meaningless. Task snapshots therefore require complete publication units and identifiers stably referring to immutable content.

Pinning a snapshot on the first read

On the first read, the second method copies the current identifier and both values. Later stages of the same task use that copy even if the global pointer changes. An update before first read pinsv2; the other schedules pinv1. The middle schedule now returns(true,900), consistent withv1, not the current result(false,450). We achieved read consistency specifically, not freshness automatically.

copy.deepcopy prevents merely retaining another reference to a mutable dictionary. Truly immutable versions could be referenced directly; copying here makes separation explicit. A large document store need not duplicate every text per task: a version manifest, identified index and stable content addresses may define the read set. These are possible architectures, not implementations or measurements in our experiment.

In the table,1 and2 identify stages;3 is after both reads before the hypothetical action. True and False are program booleans, not confidence levels. The middle current row readsv1/v2 and proposes450 while allowed is true. The next snapshot row retainsv1/v1 and900. Without interference the methods agree. The snapshot’s benefit is selective: it removes the hybrid, not arbitrarily changing every answer.

The consistent version may be wrong for acting now

After calculating entirely underv1, current rules may bev2 before action. The result is consistent, yet900 would not be permitted under the new rules. Correct behavior depends on the operational contract: finish under starting rules, revalidate, or immediately revoke prior permissions. Numeric output alone cannot choose this policy. It must be explicit beforehand and recorded alongside version, not invented afterward to justify action.

The program also calculates a version check: all reads share one identifier and that identifier remains current at the observed point. It is diagnostic only. For example,v2-v2 passes this gate but allowed is false, so action is not authorized. Real authorization additionally needs validation outcomes, permissions, resource state and operation-specific conditions. A consistency boolean cannot replace those decisions.

A second race remains: rules can change after a current-version check but before action. Our experiment stops at an observation point and executes no effects, so it does not close that window. Implementation must bind revalidation and action recording with suitable atomicity/concurrency control or a cross-service protocol. Writing “check, then act” does not demonstrate atomicity. This prevents turning a small example into a safety promise.

The transaction analogy has a boundary

PostgreSQL18 primary documentation section13.2 provides an analogy: successive Read Committed SELECTs can see different snapshots, whereas Repeatable Read shares the snapshot from the transaction’s first non-control statement. We also read serialization limitations. This clarifies fresh versus stable reads, but our code uses no PostgreSQL or transaction benchmark. An application snapshot across tools does not inherit isolation, rollback or serializability from a cited database.

An agent may retrieve indexed documents, extract an API field and read permissions from another service. One label “version7” does not align independently evolving sources. Define a manifest of compatible versions or the authority establishing the decision boundary. Timestamps alone do not reconstruct a view unless their meaning and availability are specified. Our single-catalog model excludes this complexity; address it before generalizing to distributed systems.

Task resumption and evidence provenance

If a task stops after stage one, resuming with latest rules can recreate the hybrid. A checkpoint should include pinned identifier, relevant inputs and revalidation policy. This does not mean retaining all data indiscriminately; choose what reconstructs the decision within applicable constraints. If the original version is unavailable, do not pretend to reuse it: explicitly restart under a new version or stop according to policy.

Provenance should also accompany generator chunks: which document, revision, index and transformations produced the evidence? Pinning documents does not ensure correct interpretation or identical language output. Linguistic reproducibility needs further information and can depend on infrastructure. Our result concerns only the rule catalog and deterministic two-stage sequence. Its bounded scope makes it useful, not a universal explanation of agent errors.

Checking code and the proof’s limits

run takes update placement and boolean pinned. It always starts atv1, changes the pointer when scheduled and records actual read identifiers. The snapshot is created only at first read. Six cases assert the current-read hybrid and no pinned hybrids, saving values, versions, action-point state and version checks in JSON. No threads or timed waits are used: sequencing makes a real-world concurrent interference reproducible.

For n reads over S copied data, a materialized snapshot takes O(S) time and memory before n accesses. Here S and n are two, but we do not translate that into milliseconds. Referencing immutable objects changes copy cost without necessarily changing logical consistency. Real evaluation should measure retained-version memory, view acquisition, publication lag and revalidation costs separately from answer quality.

Extending the proof means seeking counterexamples, not repeating favorable cases. More reads permit updates at each cut; tests could remove versions, mismatch an index or revoke permission mid-preparation. These are proposed tests, not executed results. JSON contains only the six declared executions. No database latency, LLM accuracy, tool security or user behavior was measured.

The answer: stable reasoning, separate action checks

Yes: individually current reads can yield an inconsistent answer. Our example combinesv1 approval andv2 factor into a nonexistent pair. A task snapshot prevents that specific basis change and makes reasoning reconstructible. It does not decide whether using that version remains permissible at action time. Consistency, freshness and authorization must remain separate questions. This demonstrates no existing EL-AI feature, but a reproducible experiment and architectural distinction to test in concrete systems.

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'])

Code, data, and instructions · JSON. Educational calculations executed with Python 3.14.0; figures with Matplotlib 3.11.2. AI-assisted analysis, without claiming peer review or human review. Original illustrative ImageGen cover: it does not document EL-AI people, premises, or installations. Sources accessed 16 October 2026.