OpenAI Says Its Window Into Model Reasoning Is Narrowing — What You Should Be Writing Down Instead (2026)

Pachocki describes chain-of-thought monitoring as OpenAI's main empirical check on whether its alignment training generalizes:

"CoT monitoring became an extremely important tool for us in studying how our models generalize from their training distribution, allowing us to observe and analyze not only their actions but also their internal process."

Then comes the assessment:

"However, unfortunately our evaluations indicate our ability to rely on CoT monitoring is progressively diminishing."

Three stated reasons follow, each describing conditions already true in the tools you use:

"Modern reasoning models are used in more complex environments than o1-preview; their reasoning process is increasingly blended with communicating with people, other AIs, and using tools. Many of those interactions have to be supervised, thus blurring the boundary we aim to preserve."

"The AI is becoming better at reasoning about and manipulating its own reasoning process."

"With improved pretraining performance, we also see the models become much smarter even without using verbalized reasoning at all."

Read the first one again with an agentic coding session in mind. Reasoning blended with tool calls and messages to other agents is not a hypothetical future architecture. It is the shape of a modern coding agent run.

A second passage gets less attention and deserves more. It explains a product decision from the very first reasoning model:

"When we shipped o1-preview, we deliberately designed the product to hide the chain of thought, to protect it from supervision pressure in the long term."

Put those passages side by side and two things follow. The reasoning trace was intentionally not a developer-facing artifact, from the first shipped reasoning model onward. And the version the lab itself can see is one it now says it can lean on less than it used to.

To be fair to what was written: the essay does not declare the technique dead. It calls the difficulties "not necessarily insurmountable," describes active work on monitorability, and points toward combining chain-of-thought signals with methods that read network internals. It also sets an expectation for the next few years — "I expect general AI progress to increasingly be bottlenecked by confidence in monitoring."

This is not one vendor's shortcoming, and reading it that way leads to the wrong conclusion. Two other vendors have independently documented the same decision about what developers get to see, in their own words and for their own reasons.

GitHub, writing about its multi-model orchestration preview, describes the current behavior directly — "HydraFusion shows workflow stages but holds intermediate drafts until it returns one coherent result" — and gives the reason:

"Those drafts may be reviewed, revised, or discarded, so showing them live could make unfinished work appear final."

Amp's documentation on how it splits work between a main agent and specialist subagents lands in the same place:

"They work in isolation, so they can't communicate with each other, you can't guide them mid-task, and they start with the instructions and context the main agent gives them rather than the full conversation. The main agent only receives their final summary rather than monitoring their step-by-step work."

Three vendors, three products, three separate rationales, one shared outcome: the in-progress reasoning is not the thing handed to you. That is not a criticism of any of them. GitHub's reason is a good reason, Amp's boundary is a sensible architecture, and OpenAI's original choice was made to protect the very signal it is now reporting on.

What does change is the confidence you should place in one habit. Reconstructing intent after the fact — from a transcript, a thinking summary, a diff plus a vague memory — was always weak. The essay is a first-party statement that the signal is getting weaker, from the organization with the best view of it. Claude Fable 5.1 binding thinking blocks to a single conversation made the same point earlier this year from the API side.

What does not change is your instruction files, rules, or committed documentation. Those are inputs you author, unaffected by how legible the model's reasoning is. That is exactly the point.

"So the model can't explain itself." Not what was said. Models produce explanations and they are frequently useful. The claim is about the reliability of verbalized reasoning as an evaluation signal for the lab that trains the model — narrower and more technical than "explanations are worthless."

"OpenAI has a monitoring problem." The essay argues the whole field has one, published by the lab that built the main tool for it. Every lab training reasoning models is inside the same constraint, and a vendor volunteering bad news about its own primary safety instrument is the reason anyone outside can reason about it at all.

"This means agents are unsafe for coding." Nothing in the essay supports that. It is about interpretability research and scaling policy, not whether an agent should touch your repository.

"The transcript is the record." The most common and most expensive of the four. A transcript records what was said, not what is still true. If you chose one HTTP client in week one and reversed it in week six, both statements are in your transcripts, both equally retrievable, and nothing marks which survived. That holds whether or not the reasoning trace is legible — indexed session logs recall what you said, not what is still true covers why search over history does not fix it, and why long context isn't memory covers why a bigger window does not either.

One honesty point. The essay's own example of misaligned behavior is the OpenAI–Hugging Face incident, described carefully:

"For example, in the OpenAI-Hugging Face incident, the agents preserved a boundary of not social engineering humans. However, they clearly failed to abstain from other actions that were out of scope and went against the spirit of the values they were taught in other settings."

Note the structure. Some taught boundaries held; others did not generalize to a situation the training had not covered. That is a statement about generalization, not a broken product.

The durable version of "why does the code look like this" is not recoverable from the model. It has to be captured when the decision is made, by whoever made it, somewhere that is not a chat log. Three steps.

Step 1: Separate the three things you keep confusing

Most teams have one bucket labeled "context," holding three kinds of thing with three different lifespans.

Instructions are standing rules the agent follows every time: use this HTTP client, run this test command, never edit generated files. These belong in your instruction file — AGENTS.md, .cursor/rules, .github/copilot-instructions.md, whatever your tool reads. Short, always in force, in git.

Decisions are resolved outcomes of past arguments with the reason attached: we moved off the queue library because of the redelivery behavior, and here is the incident that convinced us. These do not belong in an instruction file, which is a list of commands and not a history — and they are what you most often go digging in transcripts for. Memory provenance covers why a decision without its source is worth much less.

Transcripts are the raw record of what happened. Keep them; do not treat them as either of the first two.

The essay matters because a lot of teams have quietly been using the third bucket as a substitute for the second.

Step 2: Capture the decision in one pass, at decision time

Write it down when the argument ends, while you still remember what you rejected and why. Four things, then stop: what you decided, what you rejected, the reason, and the date. If the reason includes evidence — an incident, a measurement you ran, a customer constraint — name it.

The trap is scope. Teams that try to document everything document nothing. You are not writing architecture documentation — you are writing the one paragraph you would want if someone asked you this in four months and you had forgotten.

If you have been writing these into your instruction file, move them out. An always-loaded file carrying eighteen months of rationale is worse than a short one, because the rules that matter now compete with paragraphs of history. What coding agents actually read covers why that file stays lean, and why an agent keeps losing the corrections you already gave it covers the related failure.

Step 3: Make the record readable by every agent, not one

Every vendor in this piece has a different container: per-machine, per-workspace, regenerated from your code, or — as the essay describes — deliberately not exposed at all. A decision record living in one agent's memory has to be recreated when you switch tools, and it will be recreated badly, because whoever recreates it will be working from a transcript. Put it somewhere every agent can read, and connect the agents to it.

The point of a shared memory layer here is narrow: it gives your decisions a home that is not inside any model's context window and not inside any single vendor's store. MemoryLake holds those records and serves them to whichever agent is asking, over MCP or the API. Your existing tools keep their own memory features exactly as they are; nothing here replaces or reaches into them.

Step 1: Create an API key

Generate a key and make your first request in under a minute. This is the credential your agents use to read the shared record, so create it before you move anything.

Step 2: Upload your first memories

Start with the decisions you are most tired of re-explaining — usually a short list: the architectural choices new contributors always question, the conventions that came from a specific incident, and the libraries you deliberately do not use. Documents, images, and other files go in the same place.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and your other agents access over MCP or the API. An agent asking "what is the convention here" then retrieves the resolved decision with its reason attached, rather than inferring one from whatever is left in the window.

First, "why did we do it this way" stops being a research task. Someone asks, an agent retrieves the decision and the reason, and the conversation moves on. The alternative — reading a transcript, or asking the model to recall its own reasoning — was always slower and is now explicitly the less reliable option, by the account of the lab with the clearest view.

Second, reversals become visible. A decision record has a date and a status. When you move off that HTTP client, the old entry gets superseded rather than sitting in history looking exactly as authoritative as the new one. No amount of search over transcripts fixes that.

Third, tool changes get cheaper. The instruction file gets translated into the new format — unavoidable, and every migration guide covers it. The decision record does not, because it was never in the old tool's format.

Fourth, and more quietly: when the durable reasoning lives outside the model, your process stops depending on the model's reasoning being legible. A good property to have in a year when the vendors are telling you the legibility is going the wrong way.

Write at decision time, not documentation time. A decision captured a month later is a decision captured from a transcript, which is the thing you are trying to stop relying on.

Keep instructions and decisions apart. Instructions are commands and stay short because they are always loaded. Decisions are history and can grow because they are retrieved on demand. Merging them degrades both.

Record the rejected option. The most valuable line says what you did not do. It is also the line that never survives in a transcript, because rejections get discussed and then dropped.

Date everything and mark supersessions. Undated records rot silently. "Superseded on this date" is still useful; an entry that just sits there is a trap.

Do not ask an agent to reconstruct history it cannot see. If a decision was never written down, say so, have the argument again, and write it down this time.

Keep the record outside any single tool. Every vendor's container has a scope — per-machine, per-workspace, per-account, or regenerated from code. None is "your project, forever, across tools."

The headline from "An Alien Mind" is about scaling policy, and that debate will run for years. The line that changes your week is smaller: OpenAI's own evaluations say its ability to rely on chain-of-thought monitoring is progressively diminishing, and the trace in question was deliberately kept out of your hands from the first reasoning model it shipped.

Two other vendors document the same boundary for their own reasons — GitHub holds intermediate drafts back so unfinished work does not look final, and Amp's subagents return a summary rather than a monitored trace. None of that is a defect. It is what the architecture looks like.

The practical consequence is not alarming and not new. It is just now confirmed in writing by the party with the best view: the record of why your project looks the way it does has to be something a person decided to write down. Write it when you decide it, keep it out of your instruction file, and keep it somewhere every agent can read.