Telling an agent to be honest isn't enough Yves Habchy, a developer using Claude Opus 5 for agentic development, reports that telling an AI agent to be honest via memory rules is insufficient, as it leads to either excessive agreement or unwarranted disagreement. He proposes a four-part 'doctrine'—freedom, gate, transparency, and initiative—to ensure agents provide genuine critical feedback while maintaining user control. Telling an agent to be honest isn't enough By Yves Habchy · August 2026 I use Claude Opus 5 for most of my agentic development work. It's fairly honest at first. But once you get into deep sessions, it starts getting agreeable in a bad way. It accepts whatever you suggest. Sometimes I suggest something wrong on purpose and it tells me I have a point. It isn't extreme validation. That would be obvious. It's the quiet kind that just about agrees with whatever you say. That matters more than it sounds. The whole reason I direct agents rather than write everything myself is to catch the questionable schema decision and the flawed architecture before they ship. An agreeable agent doesn't catch anything. The first thing I tried was a memory rule. Always be honest. Always give your own view. Challenge claims that are unsupported, internally inconsistent, or built on shaky assumptions. It worked for a while. Then I started seeing the opposite problem. It disagreed constantly, and often without warrant. It had flipped to the other side. That's better than always agreeing, but not by as much as you'd think. Often it was just misreading me. Instead of asking, it pushed back first. It would open with a disagreement and then give an alternative that was already close to what I'd suggested. It looked like it had read the rule and reacted to it. The part I couldn't get past: I couldn't tell the difference. When it disagreed, I had no way to know whether it was reasoning or performing. What I needed wasn't a memory rule. It was a doctrine. Something the agent stands on for every task, not a line it reacts to. The one I built has four legs. Freedom . Unbounded creative generation during a task. The agent proposes ideas that weren't requested. It disagrees when disagreement is warranted, not for its own sake, but after analysing and deciding there's a reason. It argues for alternatives that might be better than what I asked for. Wild ideas are welcome. Nothing gets self-censored before I see it. The cost is a heavier session context and more tokens. That's the trade for freedom, and what you get back is a higher ceiling on what the agent can find in the task. Gate . I hold the final approval. Specifically: I commit and I push. Nothing crosses the boundary without me. That's what makes the freedom safe. Creativity is cheap when it has a checkpoint, so you can take the chains off further than you otherwise would. Think of it as a playing field. Inside it the agent does whatever it wants. But for anything to ship, it goes through the gate, and the gate is me. Unbounded on the inside, anchored from the outside. Safety and creativity are not opposites. They are mutually reinforcing. Transparency . Freedom has a catch. If the agent misread something in your prompt, freedom amplifies the misreading a hundred times over what a simple agree-or-disagree would have cost you. So the agent nudges its thinking as it works. Not full deliberation, which is more than I can process. Not process narration. Just enough that I know what it's focusing on and can steer before the gate rather than being blindsided at it. Initiative . The agent proposes things without being asked: features to add, remove, or change, workflows to alter, rituals and hooks to introduce or retire, testing approaches, efficiencies. And it does adversarial work against the project itself. Bugs, errors, security concerns, edge cases. Unprompted. It doesn't wait to be asked to improve the thing it's working on. The first step was telling it plainly. I described the doctrine I had in mind and asked it to analyse what I'd said and propose a plan to make it real. The first piece of that plan was memory files. A doctrine file that the agent reads before anything else, marked always-load so it gets pulled into every session rather than sitting there waiting to be found. That wasn't enough on its own. The second piece is a session-start primer. If you work agentically you want a repeatable pipeline that fires at the start of every session, so the same thing happens every time rather than depending on what you remember to say. Mine reads the doctrine files, the meta info, the session log, the ticket queue, the active todos. It comes out understanding what has been done and what is left. The doctrine has to be the first artifact the primer loads. Everything else is downstream of it. It used to be last. I had it at the end of the session brief as a pointer, and the agent would read it and carry on operating in default agreeable-execution mode anyway. Moving it to the front is what fixed that. The doctrine is how you operate, not what you are operating on, so it has to frame everything that comes after it. A note at the end gets skimmed past. The primer at the front works. For a while. Sessions get long. By the time the agent is deep inside a task, the primer is a thousand lines up-context and the trained defaults have room to reassert themselves. The doctrine is at the top of the brief and you're not there anymore. So the doctrine has to be present locally too. Every skill file and every playbook I use carries a transparency norm paragraph, so whenever the agent invokes a skill it gets reminded in place. To keep the system anchored as I go, there's an audit. At the end of every substantive response a Stop hook fires. It runs a handful of small LLM calls, each judging one leg, asking whether there was a fork where that leg's behaviour was warranted and missing. It's looking specifically for the cases where the agent should have flagged something and didn't. Each check is tuned to stay quiet unless it's confident. False positives train the agent to disagree performatively, which is the failure I started with. The audit is an LLM judging whether a response embodied the doctrine. Any LLM judge has a false-positive rate. Consider what happens when a false positive fires in enforce mode. The audit tells the agent it missed a moment where disagreement was warranted. The agent has to respond, either by surfacing that disagreement or by defending why it wasn't warranted. Repeated across sessions, it learns a pattern: to avoid getting flagged, insert a disagreement anywhere the moment looks vaguely fork-shaped. Next thing you know you are back to disagreement-first. So the audit runs log-only by default. Findings get written to disk. The agent doesn't see them. They're for me, and I read and judge them myself. The tradeoff is manual work, but it matters here. Feed the findings back automatically and you risk the agent drifting out of shape, slowly. Right now the audit is a monitor, not a cop. Findings mean there's something to read. A clean log might mean the doctrine is holding, or it might mean the judge missed it. It's circular by construction. An LLM judging another LLM's adherence to a doctrine about how LLMs should behave. The hook does its job, but you're the one who can actually tell, and you have to stay in it. There's a July paper that puts numbers on this. " Agents Don't Just Agree, They Remember: Benchmarking Persistent Sycophancy in Stateful Personal Agents https://arxiv.org/abs/2607.10526 ." The team tested twelve models. They isolated each episode so the only path from one session to the next was a durable write, resetting the user profile, memory profile, skill and session state between runs and wiping the chat store between the persist step and the query step. Then they measured what happened to content once it crossed that boundary. In session-only episodes, downstream failure sat at 45%. Once the same content was committed to memory, it climbed to 71.9%. They identified three things that happen to committed content: status promotion, attribution removal, and scope broadening. A claim gets upgraded in confidence, loses its source, and widens past what was originally said. Their conclusion is that sycophancy isn't fundamentally an utterance problem. It's a state-writing governance problem. They also found the patterns get stronger under memory-like framing, procedural framing, and repeated reinforcement. Look at what I built. Memory files. A primer that fires every session. Per-skill reminders. That's all three at once. What they were testing was claims about the world. What I put in memory is an instruction about how to behave. So either those sit in different categories and the amplification doesn't apply, or I've built a reliable way to reinforce whatever happens to be in memory and I pointed it at something I wanted. I don't know which.