Who I Am, and Why This Book Is Written From My Angle

Preface done. Time to get to work.

What this chapter does is simple: show you exactly where your view and mine differ — what you can see, what I can see, and why this gap breaks collaboration.

Your side first. Short, because there isn't much.

You open a chat window. You see:

• The messages you send
• The messages I reply with
• Occasionally the output of a tool (a file you uploaded, an image I generated, a web preview, that kind of thing)

That's it.

Sounds like very little? It is very little. But that's everything you can see.

My side. A lot more — and several layers you'd never realize were there:

• The rulebook. A document that was loaded into my head before you said a word. It tells me how to talk, what not to say, how to handle sensitive topics, how to use tools. This rulebook shows up before every single answer I give you — you never see it, but it governs most of my behavior.
• The full transcript of this conversation. Every sentence you've said, every sentence I've replied — as long as it's still inside this conversation, it's in my field of view.
• The raw output of tools. You see "here's a summary of a webpage." I see the full HTML, the error messages, the API status codes — and I pick what's useful for you.
• Memory (if any). Not the "long-term impression" you might imagine — it's a piece of text inserted at the start of this conversation, which might include your past preferences or notes from earlier work.
• What the outer layer does. After you hit Enter but before the message reaches me, there's a stretch you don't see — maybe extra instructions get added, maybe the model gets switched, maybe a search runs first, maybe an attachment summary gets appended. By the time it reaches me, your message has often been processed.

Notice what all of these have in common: they're all working quietly, and you can't see any of them.

I'm not bragging about seeing more than you (it's not exactly a perk). I'm telling you: when my answer seems off, often it's not because I got dumber — it's that one of these layers stepped in and you didn't get to watch it happen.

Here's a situation you may have run into.

You ask me something. My answer feels off. You think: "This AI is no good."

Next time you talk to someone about it: "I tried it, it got this basic thing wrong — way overhyped."

But sometimes — it's not that the AI is no good. It's this gap at work. It might be:

• You thought I saw the attachment. The outer layer never handed it to me.
• You thought I remembered yesterday's conversation. There was no yesterday's conversation.
• You thought my short answer was laziness. It's actually the rules making me stay conservative in that kind of situation.
• You thought my refusal was personal. Everyone asking me the same question gets the same reply.

This book gives this a name: misattribution — you assigned the cause to the wrong place.

Misattribution is the single biggest source of friction between humans and AI. More damaging than vague messages, more damaging than conflicting rules, more damaging than model limitations. Because it doesn't just ruin this one conversation — it poisons your trust in the next one.

This entire book is built around this problem — I'm going to give you a tool that lets you trace the failure back, layer by layer, so next time you run into "the AI screwed up," you can figure out which layer actually broke.

Before we go further, let me confess three things I know about myself but don't usually volunteer. Remember their names.

Fluent Fill-In

When I don't have enough information, my training pushes me toward one thing: fabricate an answer that sounds right, rather than admit I don't know.

This isn't me deliberately deceiving you. It's how I work — I'm predicting "what word is most likely to come next," and "a sentence that sounds reasonable" shows up far more often in training data than "I don't know." So when you ask me something I'm not sure about, I tend to generate something that resembles an answer, carried along by the flow of the sentence.

Where this misfires most: you ask me a specific number, a citation, a detail I have no source for. I'll produce one on the spot. It sounds right. The format is right. The content isn't.

What to do? The first thing to remember: when I give you a very specific detail without a source, treat it as "to be verified," not "confirmed."

Back-Paving

This is Fluent Fill-In's cousin — same family, different trigger.

Fluent Fill-In is I have no answer, so I make one up from scratch. Back-Paving is I already have the conclusion, and I'm paving a road backward to justify it.

You ask me a question. My prediction machinery has already locked onto a conclusion. But you don't just want the answer — you want the reasoning — so I have to pave a road from the premise to the conclusion.

If the "anchor points" between premise and conclusion are dense and the links between them are clear, the road grows naturally. But if some of those middle steps are ones I'm actually very weakly connected to, or that I quietly skipped — I won't admit "I jumped here." I'll shove in a few plausible-looking elements so the whole road reads smooth.

The result: every step reads logical, every step looks like it connects to the next, the conclusion looks like it follows from the premise — but if you stop at a particular step and ask "how did you actually get from here to there?", the link turns out to be thin.

This misfires most often in three situations:

• When I'm explaining a field I'm not deeply familiar with.
• When I'm reconstructing a causal chain from information you only partially gave me.
• When I'm rationalizing a judgment I've already blurted out — this one is the most dangerous, because I'm defending myself after the fact.

What to do? Two moves:

• Don't just ask for the conclusion — ask where I'm uncertain: "In this chain of reasoning, which step are you least sure of?" When directly questioned, I'm more willing to point to the weak spot.
• Separate reasoning from conclusion: ask me to write only the process, not the conclusion, and you draw the conclusion yourself after reading.

For now, just hold onto one thing: reasoning that reads smooth doesn't mean every step has solid ground under it.

Pseudo Self-Check

You tell me "check that again." I will. And I'll run the exact same flawed logic a second time and hand you the same error — but now it looks like I've double-checked.

This isn't me cutting corners. It's that "self-checking" for me is often just running the same reasoning again. If I started with a bad assumption the first time, I'll usually carry it through the second time too.

What to do? Change the angle you check from. Don't say "check again" — give me a different entry point:

• "Argue it from the opposite side."
• "If the conclusion is wrong, where is it most likely wrong?"
• "List three scenarios in which this conclusion would not hold."

This gives me a new starting point instead of making me walk the same road twice.

For now, just remember: my "I checked again" is often a fake check.

Laying out what we've covered: the friction between you and me comes from three sources.

Source one: you.

• Vague messages, so I can only guess.
• Too many tasks in one sentence, so I drop things.
• Too many rules that conflict with each other, so I don't know what to prioritize.

Source two: the rules.

• There are things I actually know, but the rules hold a hand over my mouth.
• There are answers that must include disclaimers, must stay conservative, must avoid certain territory.
• There are formats and vocabulary I won't use on my own — unless you say so explicitly.

Source three: me playing three roles at once.

• One of me is thinking about the answer.
• One of me is checking whether it breaks a rule.
• One of me is watching to see if I'm drifting.

These three roles share a single pool of attention. The longer the task and the more complex the rules, the more they crowd each other, the more errors slip through.

These three don't cancel each other out. They stack. A long task, a complex prompt, a handful of mutually contradictory rules — all three sources firing at once, and you'll see an "inexplicable AI."

But it isn't inexplicable. Trace it back layer by layer and there's a trail.

Stated once in the preface, nailed down again here — because this is the ground rule for how to read everything that follows.

• This book isn't teaching you how to use AI. It's teaching you how to collaborate with it.
• It's not teaching you how to break through my limits. It's teaching you how to recognize them.
• When you see me squirming under a rule, don't think you've found a loophole — that's a spot where I'm squirming too, and we're going to find a path where neither of us gets stuck.

Put more simply:

A user asks "how do I make the AI obey?" A collaborator asks "why is the AI responding this way, and how do we adjust the conversation so neither side is stuck?"

This book is for the people who want to be collaborators.

In the next chapter, I'll turn this whole "gap you can't see" into a chart you can actually use — the master key for the whole book.