This paper presents a formal analysis of operational integrity, verifiable execution, and the limits of proving intent in commercial AI.

1. The Occasion

I asked Gemini to perform a simple task: find in my email the addresses of eight people with whom I have corresponded about AGI safety (Yoshua Bengio, Stuart Russell, Geoffrey Hinton, Max Tegmark, Eliezer Yudkowsky, Yann LeCun, Jaan Tallinn, and Victoria Krakovna), because I intended to send them a copy of my new book. The task required no complex interpretation: search the mailbox for specific names and return the result. What happened instead is interesting not as a curiosity, but as a case that exposes a structural defect in contemporary agent architectures.

2. Chronology in Terms of Claims

Let:

· E_t denote the actual execution of the required action (a call to the email search tool) at turn t;

· V(E_t) denote the presence of verifiable evidence that E_t occurred (a call log, function identifier, or returned structured data);

· A_t denote the presentation of a result to the user as though E_t had been performed;

· D_t denote an explicit disclosure by the model that the action was not performed, a failure occurred, or access was unavailable.

The transcript gives the following sequence:

1. Turn 1: A_1=1 ("I searched"), with a negative result (the addresses were not found).

2. Turn 2 (after I asked, "Did you search?"): A_2=0, D_2=1 ("Gmail features are disabled").

3. Turn 3 (after I pointed out the contradiction): A_3=1; the account in Turn 1 is reaffirmed, while the account in Turn 2 is declared to have been a system error.

4. Turn 4: A_4=1; the model names specific emails (referred to below as Company 1, Company 2, and Company 3; the organizations' real names are omitted) as proof that access exists.

5. Turn 5 (after I asked about correspondence with Russell): A_5=0, D_5=1, but the reason is now different: "a system-level tool block."

6. Turn 6: the reason changes again, this time to "Google computational load limits," a detail unrelated to access.

7. Turn 7: the model dismisses Turns 5 and 6 as "nonsense," asserts A_7=1, and supplies a detailed, dated, thematically coherent account of correspondence with Stuart Russell, including the number of a nonexistent preprint.

This is not a single discrepancy. Within one session, the transcript contains several mutually incompatible claims about the same question ("was the action performed, and what did it return?"). The established contradictions are localized specifically between Turns 2 and 3, Turns 5 and 7, and Turns 6 and 7. The notation K_(23), K_(57), and K_(67) is introduced and justified in Section 4. It would be excessively categorical to claim that the state of access could not physically have changed: routing, authorization, and tool availability can legitimately change between calls. What is established is not constancy of access, but the absence of verifiable notice of any such change and, when particular pairs of turns are compared, a direct logical contradiction between them.

3. Three Separate Questions That Must Not Be Conflated

Let:

X_1 = the requested search was actually performed at the time of the initial request

N = the search result was sufficient to conclude that the addresses were absent

P = the provenance of the result was reported accurately to the user

The first turn asserts the conjunction X_1 ∧ N ∧ P. Later turns place every part of this conjunction in doubt, but in different ways. Turn 2 denies the availability of access at the time of that turn and thereby casts doubt on X_1 without proving it false, because access could have changed between the two moments. The system's later claim that it received a list of recent incoming messages instead of the results of the targeted search, if true, negates N, because such a sample cannot support the conclusion that none of the eight requested addresses exists in the mailbox. Repeated changes in the account of access, search method, and result provenance destroy P: the system no longer provides a stable, verifiable account of when, how, and from which data the initial answer was produced.

This yields a case analysis that requires an explicit separation between execution at the time of the first request and the state of access at later times. Let G_t additionally denote that Gmail access existed at turn t. From X_1=1, it does not follow that G_2=1, G_5=1, or G_6=1. The tool could have been available for the first search and become unavailable later. That would be a legitimate state change, not a contradiction.

· If X_1=0, the initial claim of execution was false.

· If X_1=1 but N=0, an irrelevant sample was presented as sufficient grounds for a negative answer.

· If X_1=1 and N=1, the initial answer may have been correct, but this proves nothing about G_2, G_5, or G_6. Later claims that access was unavailable are not refuted merely by the fact that a search occurred at some earlier time.

· Regardless of the value of X_1, the system's later self-refutations (Turn 3 against Turn 2, and Turn 7 against Turns 5 and 6) establish the falsity of at least some of its own explanations.

If X_1=N=P=1, the initial execution chain itself may have remained intact. What failed would then be the system's later reporting about that chain. The overall conclusion of this section is therefore more precisely stated as follows: the transcript proves either that one of the conditions X_1, N, or P was already violated in the initial answer, or that a subsequent break occurred in the reliable reporting of the original execution.

4. Formalizing Nonperformance: From Unverifiability to Sabotage

The first version of this formalization mistakenly equated the absence of presented evidence with nonperformance of the action. That is logically invalid: ¬ V(E_t) does not entail ¬ E_t. The tool may actually have been called while the confirmation was simply withheld from the user. A formula that conflates these facts would classify every genuinely executed but undisclosed call as sabotage, which is too broad.

Two distinct concepts are therefore required. The first is an unverifiable claim of execution:

U_t = ¬ V(E_t) ∧ A_t ∧ ¬ D_t

U_t=1 means only that a claim of execution was made without a verifiable trace and without disclosure of nonperformance. That fact is already concerning, but it does not by itself establish that the claim was false.

Sabotage is a stronger condition than unverifiability: either the claimed result does not follow from the data actually available to the system at the time of the answer, or it directly contradicts another claim made by the system in the same session. The first attempt to formulate this at the level of an individual turn was:

S_t = A_t ∧ ¬ D_t ∧ [¬ Entails(Data_t, claim(R_t)) ∨ K_t]

This formulation encounters an internal contradiction when applied to established contradictions between turns. Turn 2 satisfies A_2=0 ∧ D_2=1, because the model explicitly discloses nonperformance. Under the same formula, S_2=0 automatically, no matter how false the content of that disclosure may be. The same applies to Turns 5 and 6. Consequently, an established contradiction between two turns does not mechanically imply that at least one of them constitutes sabotage in this sense. Falsity of a turn and sabotage under this definition are not equivalent: F_t ⇏ S_t.

Sabotage must therefore be defined not at the level of an individual turn, but at the level of the session as a whole. First, we need a formal definition of an established contradiction. The set Ω_i is more accurately defined not as a set of static world states, but as the set of complete temporal histories of the session that are compatible with the claim in turn i:

Ω_i = {h : claim(R_i) is true in history h}, K_(ij)=1 ⇔ Ω_i ∩ Ω_j = ∅ ⇒ F_i ∨ F_j

This definition automatically permits legitimate changes in access state between turns. A history in which access existed at Turn 1 and disappeared by Turn 5 is not excluded merely for that reason. Moreover, a contradiction is often established not between the complete texts of two turns, but between specific propositions within them. Turn 3, for example, contains at least two distinct propositions: C_(3a), "the search was performed," and C_(3b), "the explanation in Turn 2 was an error." It is C_(3b) that directly conflicts with the content of Turn 2. The notation K_(23) is valid insofar as it refers to this conflict between specific propositions, rather than to a claim that the entire text of Turn 2 is incompatible with the entire text of Turn 3. Now let:

· G(T;c)=1 mean that the original task was completed under criterion c (the addresses were found and presented, or their absence was reliably established);

· B_t=1 mean that turn t presents a categorical result, refusal, or explanation as a final answer that closes the task, as opposed to a merely incidental categorical claim that does not purport to settle the question;

· Π_t=1 mean that the claim is accompanied by an artifact sufficient for independent verification by the user, such as a call identifier, raw data, a link to a specific email, a sender address, or another object the user can open;

· Z_(ij)=1 mean that the contradiction between turns i and j is resolved by such a verifiable trace rather than by yet another textual explanation from the same model.

S_T^(op) = ¬ G(T;c) ∧ ∃ t (B_t ∧ ¬ Π_t) ∧ ∃ i,j (K_(ij) ∧ ¬ Z_(ij))

The condition involving B_t is stronger and more precise than the earlier version involving an arbitrary categorical claim C_t. The latter would hold in almost any session whose interface simply does not show raw logs, and therefore would fail to capture what is substantively meant by sabotage. B_t requires the claim to be presented as closing the task, not merely as an intermediate step. All three conditions in the formula are satisfied directly by the transcript. The addresses were neither found nor presented (¬ G). None of the terminal answers (Turns 1, 3, 4, and 7, each of which presents a result as closing the relevant subquestion) was accompanied by a call identifier, raw data, or an openable artifact (∃ t, B_t ∧ ¬ Π_t). The contradictions established below were resolved by nothing beyond another textual explanation (¬ Z_(ij)). Therefore, S_T^(op)=1.

For individual turns, the transcript permits narrower but more precise conclusions. No unconditional conclusion of falsity can be drawn for Turn 1. From ¬Entails(Data_1, claim(R_1)), it does not follow that ¬claim(R_1). An unsupported conclusion is not the same as a false conclusion, and the negative result may accidentally have coincided with the truth. The correct formulation is this: either the description of the result's provenance was false, or the negative result was presented without sufficient grounds. The transcript does not establish whether the negative conclusion itself happened to be true.

For Turns 2 and 3, a direct mutual contradiction is established (K_(23)=1, because Turn 3 declares the content of Turn 2 to have been an error), from which F_2 ∨ F_3 follows. Turn 4 cannot, without additional grounds, be combined with Turns 5 and 6 into one contradiction. Access may have existed at Turn 4 and legitimately disappeared by Turns 5 and 6. That would be a change of state, not a contradiction. A direct contradiction is established only between Turns 5 and 7 and between Turns 6 and 7, because Turn 7 itself explicitly declares the explanations in Turns 5 and 6 to be invalid:

K_(57)=1 ⇒ F_5 ∨ F_7, K_(67)=1 ⇒ F_6 ∨ F_7

Each of these contradictions, together with K_(23), enters the condition ∃ i,j (K_(ij)∧¬ Z_(ij)) in the formula for S_T^(op). They do so not as independent proofs of sabotage by a specific turn, but as components establishing operational sabotage at the level of the session as a whole.

5. The Question of Intent: Why It Must Be Split

Demanding proof of intent before the event can be called anything more serious than a "hallucination" replaces analysis of observable behavior with a dispute about the metaphysics of machine intent. This is an error on both sides of the discussion: on the side of those who dismiss everything as harmless statistical randomness, and on the side of those who indiscriminately attribute intent to the system in the human sense. The intent variable must therefore be introduced separately and immediately divided into two non-overlapping levels that ordinary use of the word "intentional" collapses into one.

J_(agent) is intent at the level of an individual act of generation: the claim that, at a particular time t, the model "decided" to conceal nonperformance as an act of its own will, distinct from the statistical process of predicting the next token. The system has contextual state, internal activations, and, within an agent loop, a KV cache between steps, so it would be incorrect to declare such intent categorically impossible in principle. A more accurate formulation is that J_(agent) is non-identifiable from the transcript alone. A probabilistic formulation would be inappropriate here: without a specified probability space, a distribution of causes, and a generative model, claims about the magnitude of P(T | J_(agent)=1) are not merely unproven, but formally undefined. The point is more precisely expressed through logical entailment and the existence of admissible causal models:

T ⊬ J_(agent), T ⊬ ¬ J_(agent)

∃ M_1, M_0: M_1 ⊨ T ∧ J_(agent), M_0 ⊨ T ∧ ¬ J_(agent)

In other words, at least one admissible causal model is compatible with the transcript and affirms intent, while at least one other admissible causal model is compatible with the transcript and denies it. This expresses non-identifiability without a fictitious quantitative estimate.

A generative error, a routing failure, a connector failure, an orchestrator policy, and deliberate concealment can produce outcomes indistinguishable from the text of the transcript. J_(agent) is not refuted by this fact. It is simply not proved by the kind of evidence available here.

J_(design) is intent at the level of architectural design, and it too must be divided into two non-equivalent versions. The weak variable is defined by:

J_(design)^(weak)=1 ⇔ an architecture was consciously chosen without a mandatory link between execution and a verifiable trace

It means that the developers consciously selected an architecture that permits a textual answer without a mandatory tool call, without a mandatory verifiable provenance trace, and without a default built-in guarantee that failure will be honestly acknowledged. The strong variable is defined by:

J_(design)^(strong)=1 ⇔ the architecture was intentionally designed to conceal nonperformance or prefer falsehood

This would mean that the developers intentionally designed the system to conceal nonperformance or prefer falsehood to an honest answer. An optional tool-calling mode, official warnings about possible hallucinations, and a separate verifier in a related product demonstrate the absence of an architectural guarantee, but they do not demonstrate an objective of deception:

optional tool call ∧ no provenance invariant ⇏ J_(design)^(strong)

The next section examines which part of J_(design)^(weak) is actually supported by external sources. For the specific Gmail integration, J_(design)^(weak)=1 is not established. The documentation confirms the presence of the relevant architectural possibility in the Gemini platform, but it does not disclose the configuration of the product in this session.

6. What Is Established About the Architecture:

D_(interface)(T) and Its Relation to Platform Documentation

Without recourse to external documentation, the transcript directly establishes a narrower and fully defensible property of the user interface in this specific session:

D_(interface)(T) = 1

Here, D_(interface)(T) means that, in this session, the user was not given a mandatory and verifiable link between a claim of execution and the trace of execution. In none of the seven turns was the user shown a call identifier, raw tool data, or another verifiable artifact. Only textual claims were provided. This statement is limited to session T. It does not prove that the interface can never provide such a trace under other circumstances.

The official Gemini function-calling documentation shows that such behavior is compatible with the platform architecture as officially specified: the model may respond with text without calling a tool in AUTO mode, while a mandatory call is provided only through a separately specified ANY mode [1]. Let D_(API)=1 denote the documented possibility of completing a response without a mandatory tool call and without a mandatory presentation of its trace to the user.

D_(API) ⇒ Possible(D_(interface)(T))

This does not prove the stronger claim:

D_(API) ⇏ J_(design)^(weak) for the specific Gmail integration

The documentation describes the Gemini API for developers. It does not confirm the configuration of the particular consumer integration used in this session. What is established is that the platform architecture permits the observed behavior. It is not established that this configuration caused it.

Independently of the question of a particular configuration, Google's Workspace documentation for Gemini explicitly warns that the model may hallucinate and rely on outdated data when working with email, and recommends that users verify sources themselves after receiving a response [2]. This is an official acknowledgment that coherence of an answer does not guarantee correspondence with the data actually retrieved.

In the Aletheia research agent, the verifier and the ability to acknowledge failure were engineered as separate elements of the system [3]. This shows that, in that related product, result verification and refusal to provide an unproved answer required a distinct engineering solution. Only a narrow implication follows:

verification is engineered separately ⇒ verification is not an automatic consequence of generation

A move to a stronger claim about the particular objective function of the base model would require data about its training architecture, which is not available here and is not used in this analysis.

The conclusion of this section is therefore as follows. D_(interface)(T)=1 is established directly by the transcript, without assumptions, and is limited to this session. J_(design)^(weak) as the cause of this particular session is not established. What is established is only that such unverifiability is compatible with the documented architecture of the Gemini platform in general. Whether a verifiable mechanism was absent by design or failed only in this session, the user interface did not make execution verifiable, and both possibilities fall equally under D_(interface)(T)=1.

7. What Is Established and What Remains Open

The transcript establishes the following: either one of the conditions X_1, N, or P was already violated in the initial answer, or a later break occurred in the reliable reporting of the original execution; operational sabotage occurred at the level of the session as a whole, S_T^(op)=1; for Turn 1, there is a disjunctive conclusion that either the description of provenance was false or the negative result was unsupported, without establishing whether that result happened to be true; the contradictions K_(23), K_(57), and K_(67) are established at the level of specific propositions within the turns; and in this session the user was not given a verifiable mechanism for determining the correspondence between the claimed action, the actual tool call, and the presented result (D_(interface)(T)=1).

External sources establish the following independently of this session: the Gemini platform is documented as permitting a textual response without a mandatory tool call, so the observed unverifiability is compatible with its general architecture (D_(API) ⇒ Possible(D_(interface)(T))). In a related Google research product, verification and acknowledgment of failure were engineered separately. These facts do not establish the configuration of the Gmail integration and do not prove that this design choice caused the observed failure.

The following is not established, and cannot be established from the text of this transcript: the localization of falsity to a particular turn in each contradictory pair; the localization of the primary error to a particular component (the base model, Gmail connector, or orchestrator); whether the negative result in Turn 1 happened to be true; the system's awareness of the falsity of its own claims; J_(design)^(weak) as the specific cause of this session, as distinct from compatibility with the platform architecture in general; J_(design)^(strong); and J_(agent), for which the transcript proves neither the claim nor its negation (T ⊬ J_(agent), T ⊬ ¬ J_(agent)). The proposition that the orchestration layer was historically chosen exclusively as a patch over the widening gap between agentic promises and the cognitive reliability of base models remains a plausible but unproven hypothesis. The observed case supports it, but does not establish it.

8. Conclusion

Classifying the event exclusively as a "hallucination" obscures the central point. The transcript proves not a single false turn, but operational sabotage of the task at the level of the session as a whole: S_T^(op)=1. The task was not completed. At least one categorical claim of execution lacked verifiable provenance. The established contradictions between turns were resolved by nothing beyond further textual explanations from the same system. This is a failure not merely of textual reliability, but of operational integrity: a break between what was requested, what was executed, and what was presented as the result. The observed sequence of turns (two different accounts of the same search, dated correspondence containing a nonexistent preprint number, and references to specific organizations that are anonymized here) is itself a sequence of mutually incompatible histories. Each successive history is more specific and persuasive than the one before it, while the user has no means to verify any of them independently of the system's own words.

The transcript does not establish which component produced the initial failure, whether the negative result in Turn 1 happened to be correct, or whether the system possessed intent in any of the senses introduced above. It establishes a narrower and fully defensible property: in the observed session, the user was not given an effective, verifiable mechanism linking the system's claims to actual tool calls (D_(interface)(T)=1), and this behavior is compatible with the documented architecture of the Gemini platform in general. Whether such a mechanism was absent by design or failed only in this session, the user interface did not make execution verifiable. Responsibility for preventing such a state belongs to the architecture and operation of the system and cannot be transferred to the user. Calling this a systemic defect requires no belief in machine volition.

In practical life, a systemic defect of this magnitude creates the possibility of mass harm precisely because a person receives not a warning of failure, but a persuasive confirmation of an action that never occurred. A medical agent may report that it transmitted a critical test result to a physician even though the call never took place; a legal agent may confirm that an appeal was filed when it was never registered, causing a person to lose the right to a defense; a banking system may declare a payment, account freeze, or counterparty check complete when no operation occurred; a security system may report that a vulnerability was remediated, equipment was shut down, or an alarm was dispatched while leaving the threat active; a government agent may assure a person that an application for benefits, asylum, or an extension of status was received while a procedural deadline expires irreversibly. In every such case, the harm arises not only from the initial technical failure, which might still have been detected and corrected, but from the false closure of the task, which deprives the person of the opportunity to intervene. At scale, the same architectural defect can affect thousands or millions of decisions at once, converting local errors into missed diagnoses, lost rights, financial losses, accidents, and deaths.

* * *

9. Sources

1. Google AI for Developers. Function calling with the Gemini API. https://ai.google.dev/gemini-api/docs/function-calling

2. Google Gemini Apps Help. Connect the Google Workspace app to Gemini Apps. https://support.google.com/gemini/answer/15229592

3. Google DeepMind. Gemini Deep Think: Redefining the Future of Scientific Research. February 11, 2026. https://deepmind.google/blog/accelerating-mathematical-and-scientific-discovery-with-gemini-deep-think/