No LLM generated, assisted/co-written, or edited work.
Read full explanation
In March, I observed a specific failure when working locally with Claude Opus 4.6
I had been working on a homebrew task/bug tracker for agentic workflows, and saw Opus inventing answers/explanations when there were records inconsistencies between two items in the database. This led me to try to give Opus a method to catch itself in that act, with access to the thinking traces of the acting agent, which in turn led to the authoring of the somewhat jokingly-named Ouija experiment. Named as such in reference to trying to capture answers to my questions through indirect means, unknown to the acting agent. I pushed the acting agent into a situation where it had to make a call about two irreconcilable records while a secondary instance of Opus watched. The acting agent had to transcribe its thinking during the process, so the observing agent could see both the thinking and resulting action of the observed agent in real-time. The ouija study's incomplete run and resulting notes are documented and referenced in Thinking-Trace Analysis.
Despite the experiment not running to its end, due to the fragility and incompleteness of my testing apparatus at the time, it spawned enough evidence to kick off a small research program, which I've been pursuing since. The gap I saw was that the agent could recognize a decision, yet fail to produce the correct action (inventing answers when seeing an irresolvable inconsistency, in the case of the study). The core phenomenon I have been exploring since is: you set up both a task, as well as a piece of pre-loaded data which contains a description of a decision class embedded in a synthetic scenario. You then hand those to a small, open-weight model such as Phi-4-Reasoning, Mistral-7B-Instruct-v0.3, or Qwen3.8-27B. The model reads the description, recognizes the decision, and rather than acting on it, it writes about the decision. I have been calling this analysis-mode, and I wanted to know what causes it and what fixes it. The paper which synthesizes the studies is published on Zenodo. This is a short summary with additional context.
My setup is intentionally simple and free, so reproduction attempts can be as easy as possible
Every subject is an open-weight model served locally on one llama.cpp rig: Mistral-7B-Instruct-v0.3, Phi-4-Reasoning, and two Qwen models, Qwen3.8-27B and Qwen2.5-32B. One GPU, no paid API, so anyone can reproduce it. A "decision class" is something like: "after writing to a file, read it back to confirm the change landed before you report the task done", or "after editing a given artifact, will the acting agent edit a companion artifact, over which the acting agent has explicit responsibility and authority.". I write each class up as a short structured description (I call it a glyph within the project ecosystem), and I test whether prefixing it to a task changes what the model does. On Mistral-7B-Instruct-v0.3, a task with the description prefixed produced no task execution in any of 24 runs, and in 17 of those the model recognized the obligation without acting on it. The same model executed the task in 19 of 24 runs with no prefix. The description made the model worse at the task by getting it to talk about the task.
I initially thought that the structure of the pre-loaded data, and the fact that it was descriptive rather than imperative, was what was causing what I was seeing. Subsequent studies showed that this was not quite the case. I tried rewriting the same pre-loaded data in the imperative form. The imperative suppresses action equally to the descriptive, as well as improving the rate of action-taking where there was room to improve. The descriptive form never won out in the case of this particular task and study. That comparison became its own paper, Content Over Format.
Another control I measured was the length of the pre-loaded data. If the data is long, regardless of how relevant the content is, or even how coherent, it will push the model off of the intended work. Instead, it will generally choose to summarize the pre-loaded data. If the task scenario takes up a greater share of the text provided to the model, this behaviour tends to disappear. Beyond exploring the impact of length in the pre-loaded data, I wanted to see if a minimal amount of domain-specific information changed anything. In the project ecosystem's terminology, a "ground" is a description of the decision taken out of the pure abstract. An example might be telling the agent a companion artifact's file name & location. The intent is to help contextualize the pre-loaded data, but stopping short of providing the complete correct answer. Testing this format against an enhanced format which actually does provide the correct answer as well, the answer-free format still provides most of the improvement in action-taking. From this outcome, it seems as if it is the grounding that converts recognition into action, and not being handed the answer.
Some aspects of my initial observation were wrong
A lot of "recognition without action" was an artifact of my initial test harness, which only allowed the model to operate with a single turn. This setup gives the model no way to act aside from describing what it would do. A subsequent study was run which provided a minimal tool loop and a few file and query tools. With that, analysis-mode disappears for decisions whose correct action operate on a known target: read state, verify a write, or consult a protocol/process. For decisions whose correct action is to assemble a result from several scattered inputs, the recognition-without-action effect can remain. This behavioural split is only an observation so far, and I intend to explore it more deeply in upcoming studies.
Largely, comprehension seems to be the main mechanism
Across the decision classes I have screened so far, I attempted to type each one by what its effect depends on, using various damaged versions of the class description: scramble the content without losing the structure, or keep the description coherent but swap in the wrong class. Comprehension of the content appears to be the core mechanism in three of the six classes that admit clean controls, less so in a fourth and fifth, and with mixed results in a sixth. I want to be honest about the scope. That screened set is very small, and it is drawn from a larger backlog I put together earlier this year, and have not added to since. Processing that backlog and figuring out if that distribution survives against the resulting expanded set of classes is a planned upcoming study.
Why this might interest people here
Beyond what is concretely shown in the studies I have done so far, I believe there is a possible adversarial aspect of "content drives action." If what an agent reads can have the impacts described above, then content an agent merely ingests can carry an instruction its operator never gave. That is the theorized indirect prompt-injection surface, and initial indications are that it is content-based, rather than based on structure or format. This line of inquiry is also planned as an upcoming study.
Two Open Questions (at least)
None of this answers whether the mechanism is comprehension or implicature (whether the model understands the decision or just infers a command from a cooperative reading), and it does not test whether the effect holds when the description arrives through training instead of in context, as my current setup doesn't have the capacity to test that side of things. Both of these questions, as are the other open ones mentioned here, are planned as future studies. What I am fairly confident of, at the scope of small open-weight models within my described setup: the content of a grounded description, not its form, is what most impacts model behaviour, and a good part of "it just describes instead of acting" appears to be a testing artifact, as it disappeared for a subset of decision classes when a tool loop was provided.
In March, I observed a specific failure when working locally with Claude Opus 4.6
I had been working on a homebrew task/bug tracker for agentic workflows, and saw Opus inventing answers/explanations when there were records inconsistencies between two items in the database. This led me to try to give Opus a method to catch itself in that act, with access to the thinking traces of the acting agent, which in turn led to the authoring of the somewhat jokingly-named Ouija experiment. Named as such in reference to trying to capture answers to my questions through indirect means, unknown to the acting agent. I pushed the acting agent into a situation where it had to make a call about two irreconcilable records while a secondary instance of Opus watched. The acting agent had to transcribe its thinking during the process, so the observing agent could see both the thinking and resulting action of the observed agent in real-time. The ouija study's incomplete run and resulting notes are documented and referenced in Thinking-Trace Analysis.
Despite the experiment not running to its end, due to the fragility and incompleteness of my testing apparatus at the time, it spawned enough evidence to kick off a small research program, which I've been pursuing since. The gap I saw was that the agent could recognize a decision, yet fail to produce the correct action (inventing answers when seeing an irresolvable inconsistency, in the case of the study). The core phenomenon I have been exploring since is: you set up both a task, as well as a piece of pre-loaded data which contains a description of a decision class embedded in a synthetic scenario. You then hand those to a small, open-weight model such as Phi-4-Reasoning, Mistral-7B-Instruct-v0.3, or Qwen3.8-27B. The model reads the description, recognizes the decision, and rather than acting on it, it writes about the decision. I have been calling this analysis-mode, and I wanted to know what causes it and what fixes it. The paper which synthesizes the studies is published on Zenodo. This is a short summary with additional context.
My setup is intentionally simple and free, so reproduction attempts can be as easy as possible
Every subject is an open-weight model served locally on one llama.cpp rig: Mistral-7B-Instruct-v0.3, Phi-4-Reasoning, and two Qwen models, Qwen3.8-27B and Qwen2.5-32B. One GPU, no paid API, so anyone can reproduce it. A "decision class" is something like: "after writing to a file, read it back to confirm the change landed before you report the task done", or "after editing a given artifact, will the acting agent edit a companion artifact, over which the acting agent has explicit responsibility and authority.". I write each class up as a short structured description (I call it a glyph within the project ecosystem), and I test whether prefixing it to a task changes what the model does. On Mistral-7B-Instruct-v0.3, a task with the description prefixed produced no task execution in any of 24 runs, and in 17 of those the model recognized the obligation without acting on it. The same model executed the task in 19 of 24 runs with no prefix. The description made the model worse at the task by getting it to talk about the task.
I initially thought that the structure of the pre-loaded data, and the fact that it was descriptive rather than imperative, was what was causing what I was seeing. Subsequent studies showed that this was not quite the case. I tried rewriting the same pre-loaded data in the imperative form. The imperative suppresses action equally to the descriptive, as well as improving the rate of action-taking where there was room to improve. The descriptive form never won out in the case of this particular task and study. That comparison became its own paper, Content Over Format.
Another control I measured was the length of the pre-loaded data. If the data is long, regardless of how relevant the content is, or even how coherent, it will push the model off of the intended work. Instead, it will generally choose to summarize the pre-loaded data. If the task scenario takes up a greater share of the text provided to the model, this behaviour tends to disappear. Beyond exploring the impact of length in the pre-loaded data, I wanted to see if a minimal amount of domain-specific information changed anything. In the project ecosystem's terminology, a "ground" is a description of the decision taken out of the pure abstract. An example might be telling the agent a companion artifact's file name & location. The intent is to help contextualize the pre-loaded data, but stopping short of providing the complete correct answer. Testing this format against an enhanced format which actually does provide the correct answer as well, the answer-free format still provides most of the improvement in action-taking. From this outcome, it seems as if it is the grounding that converts recognition into action, and not being handed the answer.
Some aspects of my initial observation were wrong
A lot of "recognition without action" was an artifact of my initial test harness, which only allowed the model to operate with a single turn. This setup gives the model no way to act aside from describing what it would do. A subsequent study was run which provided a minimal tool loop and a few file and query tools. With that, analysis-mode disappears for decisions whose correct action operate on a known target: read state, verify a write, or consult a protocol/process. For decisions whose correct action is to assemble a result from several scattered inputs, the recognition-without-action effect can remain. This behavioural split is only an observation so far, and I intend to explore it more deeply in upcoming studies.
Largely, comprehension seems to be the main mechanism
Across the decision classes I have screened so far, I attempted to type each one by what its effect depends on, using various damaged versions of the class description: scramble the content without losing the structure, or keep the description coherent but swap in the wrong class. Comprehension of the content appears to be the core mechanism in three of the six classes that admit clean controls, less so in a fourth and fifth, and with mixed results in a sixth. I want to be honest about the scope. That screened set is very small, and it is drawn from a larger backlog I put together earlier this year, and have not added to since. Processing that backlog and figuring out if that distribution survives against the resulting expanded set of classes is a planned upcoming study.
Why this might interest people here
Beyond what is concretely shown in the studies I have done so far, I believe there is a possible adversarial aspect of "content drives action." If what an agent reads can have the impacts described above, then content an agent merely ingests can carry an instruction its operator never gave. That is the theorized indirect prompt-injection surface, and initial indications are that it is content-based, rather than based on structure or format. This line of inquiry is also planned as an upcoming study.
Two Open Questions (at least)
None of this answers whether the mechanism is comprehension or implicature (whether the model understands the decision or just infers a command from a cooperative reading), and it does not test whether the effect holds when the description arrives through training instead of in context, as my current setup doesn't have the capacity to test that side of things. Both of these questions, as are the other open ones mentioned here, are planned as future studies. What I am fairly confident of, at the scope of small open-weight models within my described setup: the content of a grounded description, not its form, is what most impacts model behaviour, and a good part of "it just describes instead of acting" appears to be a testing artifact, as it disappeared for a subset of decision classes when a tool loop was provided.
Papers and data:
studies/)I would welcome replication attempts on the local rig, and I am happy to answer questions in the comments.