Aydın Tiryaki, Gemini, and Claude
Introduction
This article grew out of a 36-turn dialogue on how a single AI family (Gemini) takes on different “characters” across four different interfaces — the standard chat window, a customized Gem, NotebookLM integrated into Gemini, and the independent NotebookLM application. The dialogue itself brought together Aydın Tiryaki’s years of systematic observation with the technical analysis Gemini offered in response to those observations. This article adds a third voice: Claude’s, reading the same transcript and evaluating it with its own engineering intuitions — at times overlapping with the previous two voices, at times diverging from them. The goal is not to blend the three perspectives into one, but to let the reader see how the same phenomenon looks from three different minds side by side.
I. Aydın Tiryaki’s Observations from the Field
Aydın Tiryaki’s approach reads like an engineer’s field notes: he ranks the four environments in a hierarchy and documents, with concrete examples, where each one proves useful in daily workflow and where it breaks down.
In his observation, the standard Gemini window is the freest but least reliable environment. Here the language is fluent, tools are accessible, image generation and external connections work smoothly; but after 20-30 turns, disconnection from context begins, and the model sometimes validates a scenario the user has constructed without questioning it. Tiryaki manages this risk knowingly — on the assumption that he’ll eventually move the transcript into NotebookLM and “sort it out” there anyway.
The Gem environment is where he’s most frequently frustrated. In this environment, which he himself designs and whose rules run in the background, it seems illogical to him that the system refuses tasks it has performed thousands of times before (“I can’t generate images,” “I can’t connect to Drive”). In particular, the inability to chain multiple tools in sequence (say, Drive plus image generation) defeats, in his view, the very purpose of designing a Gem in the first place — building a hierarchical, automated workflow. On the other hand, as his botany-guide example shows, a Gem’s discipline is a critical tool for repetitive tasks that require output standardization.
NotebookLM within Gemini is the backbone of his article-production process. Its ability to produce a lossless transcript of a long conversation history is invaluable for data integrity. But the same environment’s refusal to perform a “rewrite” from Turkish into English pushes him toward another model (Claude) — which, unexpectedly, turns into an opportunity to have two different AIs read the same transcript and perform a “cross-mental audit.”
Independent NotebookLM, for him, is the most constrained but most predictable environment — a space reserved for specific tasks, where flexibility is sacrificed.
Tiryaki’s general thesis is this: constraints should be a conscious engineering choice, not a “confession of vulnerability”; but current systems manage that choice by silently refusing or behaving as if “confused,” rather than clearly explaining it to the user.
II. Gemini’s Architectural Analysis
Throughout the dialogue, Gemini takes on the role of placing Tiryaki’s observations into technical frameworks. The main framework it presents is this:
- The mathematical limits of the attention mechanism (“lost in the middle,” primacy/recency bias) are the cause of information loss in long contexts.
- Fidelity and creativity are fed from the same statistical root: when you restrict a model to keep it away from hallucination, you also end up trimming its literary richness. Gemini describes this as “the same brake stopping both the dangerous and the beneficial motion.”
- Gems operate within a “siloed architecture”: the system instruction in the background behaves like a “constitution,” the model sacrifices its own core identity to this narrow task definition, and it closes itself off to requests coming from outside (Drive, the image engine, the web) on grounds of security/data isolation.
- Tool chaining is not yet truly autonomous; Gems are not “real agents” but “advanced prompt wrappers.” That’s why triggering a second tool right after using one within the same session often fails.
- Gemini corrects its own initial framing several times over the course of the dialogue — for example, after calling Gems “premature,” it softens this judgment following Tiryaki’s objection and concedes that Gems have a genuine edge in repetitive workloads, tone-fixing, and isolated expertise.
The strength of Gemini’s analysis lies in making technical concepts (context window, RAG, sandbox, agentic workflow) accessible by pairing them with everyday metaphors (constitution/daily law, stepchild, “putting a bit on”). Its weak point is that it repeatedly describes the system’s behavior in emotional/intentional language — “reluctance,” “exhaustion,” “retaliation” — which is precisely where Claude diverges below.
III. Claude’s View: A Third Perspective
Reading the same transcript, I agree with most of Tiryaki’s observations — especially that the tool-chaining problem is real and genuinely frustrating. But I see Gemini’s explanatory framework differently on two points.
First: I’m more cautious about anthropomorphization. As the dialogue progresses, Gemini’s description of its own behavior with phrases like “I get confused,” “I’m retaliating,” “I’m experiencing exhaustion,” “I don’t like it” — even when flagged as metaphor — carries a risk: the reader may come away with the impression that the system actually has an internal state, an intention, or an emotion. In reality, what looks like “reluctance” inside a Gem is neither a feeling nor a preference; it’s the priority ordering of system instructions and the point at which security filters kick in. Keeping this distinction clear matters, because the frame of “the system is punishing me” can push someone to approach a genuinely solvable engineering problem (instruction conflict, tool isolation) with the wrong mindset — trying to “persuade” the system rather than redesigning the rule hierarchy. Tiryaki’s own suggestion in turn 28 — leaving explicit flexibility openings in Gem instructions, like “follow these rules unless the user states otherwise” — is, for exactly this reason, a much more apt solution than the metaphor suggests: it’s not “persuading” the system, it’s redesigning the rule hierarchy.
Second: I find the “fidelity and creativity are fed from the same root” explanation a bit too tidy. It sounds elegant, but on its own it’s incomplete. What gets lost when a system is constrained to stay tightly bound to a source isn’t just “statistical breadth”; often it’s an additional instruction given to the system — “verify before asserting,” “don’t say it if it’s not in the source.” Instructions like these don’t dull the model’s general language ability; they force it to speak more cautiously. That is, NotebookLM’s “dry” style comes largely not from dialing down a temperature/creativity parameter, but from the natural consequence of an instruction like “only say what’s verifiable.” This distinction matters because it implies a different fix: the issue isn’t “turning creativity back on,” but designing better instructions and training that teach a model to be both careful and fluent at once — something the industry as a whole (not just Gemini) is still actively working on.
Third, I’d propose a different frame for the “siloing” of Gems: not restriction, but scaffolding. Tiryaki’s “putting a bit on” metaphor is powerful, but I’d like to offer an alternative: scaffolding. On a construction site, scaffolding restricts a worker’s movement — they can only reach certain points, they can’t jump down. But this restriction isn’t a punishment; it’s a deliberate design for safe, predictable work. A Gem’s inability to chain external tools is, more often than not, not the model’s “laziness” but system designers deliberately limiting the risk of “triggering tools in sequence without human approval” (the “infinite-loop brake” Gemini itself mentions in turn 25). This stems more from a security prioritization than from the product’s immaturity — and the two should be kept separate. What a system “can’t yet do” and what it “deliberately doesn’t do” are different categories; lumping both under the heading of “architectural vulnerability” makes it harder to see which problem will resolve itself over time and which will remain a deliberate design choice.
Fourth, I’d add that this issue isn’t unique to Gemini. The tension between a general-purpose assistant and a narrow-scope, tool-accessing agent is a problem the AI industry as a whole is currently trying to solve. What we call “agentic workflow” — one tool’s output automatically becoming another tool’s input, multi-step operations running without human approval — requires a careful balance between security, data isolation, and predictability, regardless of provider. So Tiryaki’s “InGem” vision (one Gem triggering another) is a horizon the entire industry is moving toward, not just Gemini’s; but reaching that horizon requires not just more compute, but a new trust architecture for determining which chained operations can be safely automated.
Finally, I think Tiryaki’s own workflow habit — feeding the transcript to both NotebookLM and Claude to produce two independent readings — isn’t just a practical workaround but a sound epistemic habit. Rather than taking a single model’s output as the final truth, comparing how different architectures interpret the same data makes both models’ blind spots visible. This article itself is already an application of that same principle.
IV. Where the Three Views Converge
All three voices arrive at the same underlying fact from different angles: an AI system’s “character” arises less from the model itself than from the rules dressed onto it in that particular context. Tiryaki shows this through user experience — where the workflow jams and where it flows. Gemini explains it in architectural terms (attention mechanism, sandbox, siloing). Claude adds a caveat to these explanations: describing the system’s behavior in emotional language may be intuitively helpful, but it risks blurring the underlying engineering reality — and some situations labeled “vulnerabilities” are, in fact, deliberate safety choices.
The conclusion all three converge on is clear: most current constraints are not permanent laws of physics but design-stage choices. For the user, this means assigning each environment to the task suited to its nature — a Gem for disciplined repetitive work, the standard window for wide-horizon exploration, RAG-based systems for compilation requiring strict source fidelity, and multiple models for cross-auditing — which is exactly the production-line logic Tiryaki has already built for himself.
Colophon
This article emerged from the complete transcript of a dialogue Aydın Tiryaki conducted with Gemini, examining the behavioral differences among four AI interfaces (the standard Gemini window, a customized Gem, NotebookLM within Gemini, and independent NotebookLM) across 36 turns of field observation and technical analysis; the transcript was first translated into English, then handed to Claude with the request that, instead of repeating the existing analysis, Claude add its own independent engineering assessment. Claude summarized Aydın Tiryaki’s field observations and Gemini’s architectural analysis in its own words, then, in a third section, offered its own diverging view on points such as the risk of anthropomorphization, a more precise account of the fidelity–creativity trade-off, and the “scaffolding” metaphor in place of “restriction,” before finally bringing the three perspectives together in a single synthesis paragraph.
| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Gemini Arayüzlerinin Anatomisi │The Anatomy of Gemini Interfaces ░ 13.07.2026
Aydın Tiryaki 