AI Agent Inconsistency: Why It Disagrees With Itself

Ship a classifier agent and you will meet this bug within a week. Same model. Same input. Same prompt. Different answer — and not different wording, semantically different. Benign on Monday, suspicious on Tuesday. Your customer asks the obvious question: which one do I trust?

At AI Engineer, Diane Lin — who leads self-evolving agent development at Datadog after her security-alert triage startup was acquired earlier this year — gave a talk called Why Your Agent Disagrees With Itself (And What To Do About It). Her diagnosis is the interesting part, because it points somewhere almost nobody looks: not at the model, and not at the prompt.

TL;DR — Most AI agent inconsistency is not the model being random; it is your agent standing on a decision boundary that your organisation never wrote down. Flip-flopping cases cluster in the gray zone where human experts also disagree, and where the "right" answer is a company preference, not a fact. The cheap fix is not fine-tuning: it is finding the disagreements (run the case several times and compare — confidence scores lie), then adding semantic memory — the written rule that disambiguates the case — and episodic memory — the record of how similar cases were decided. In one production run, that took the flip-flop rate from 25% to 10%. Those rules are markdown documents, and MDflow is a place to keep them where every agent can read them.

What is AI agent inconsistency?

AI agent inconsistency is when the same agent, given the same input, returns semantically different outputs across runs. Not a reworded answer — a different verdict. Positive on one run, negative on the next.

It shows up first as an evaluation nuisance. If a single eval run can land either side of the line, one run tells you nothing and you have to repeat and average. But in a product it is a trust problem. Lin's example: a security analyst triaging alerts has to decide whether a signal is malicious and needs action, or benign and can be ignored. Feed the agent "failed login attempt to a Gmail account detected from a suspicious IP" three times and you may get benign, suspicious, benign. In a proof-of-concept bake-off against a vendor whose agent says the same thing every time, you already know who wins.

Two causes, and only one of them is yours

It is worth separating the layers, because they need entirely different fixes.

Layer one is the infrastructure, and it is genuinely nondeterministic. Thinking Machines Lab's Defeating Nondeterminism in LLM Inference (September 2025) traced this precisely: sampling 1,000 completions from Qwen3-235B at temperature 0 produced 80 distinct outputs, first diverging at token 103. The cause is not the sampler — it is that kernels for matrix multiplication, attention and RMSNorm are not batch-invariant, so the floating-point result for your request depends on what else happened to be in the batch alongside it. Swap in batch-invariant kernels and you get bit-identical runs, at roughly 60% throughput cost in the reference implementation (later cut to around 34% by the SGLang team with CUDA graphs).

That is a real and fixable problem. It is also, for most teams, not the one biting you — you are not going to run custom kernels, and bit-identical inference would not have told your analyst whether that Gmail alert mattered.

Layer two is ambiguity, and it is yours. This is Lin's contribution, and it reframes the whole bug.

Why AI agents disagree with themselves

Because the cases that flip cluster around the decision boundary — the gray zone where the correct answer was never actually decided.

This is an empirical observation, not a theory. The cases that flip are not random draws from your dataset. Take sentiment analysis on hotel reviews. A glowing review comes back positive every single time, on every run. The one that flips is the one sitting on the line: mildly annoyed about something, with a couple of positive notes around it.

Now ask what the right label is. If the complaint is about something outside the hotel's control, one hotel says don't flag it, there's nothing we can do — and another says flag it anyway, we want to know. There is no right answer. There is a preference. And the model was never told which one you hold.

The security example is sharper. An alert shows repeated failed logins — an attacker knocking on the door. For an enterprise where attackers knock constantly and get blocked, that is benign; flag it and you drown the SOC in noise. But if the attacker eventually guesses the password, passes MFA and gets in, the same opening behaviour is now a serious incident. Nearly identical signals at the start, completely different responses required — and the disambiguating fact (did they get in?) is either in the alert or it is not.

So the diagnosis inverts. These are exactly the cases where human experts disagree with each other too, and where traditional ML classifiers have always struggled. Your agent is not failing at the task. It is surfacing an ambiguity that already existed in your organisation, and that used to be invisible because it lived in the heads of three different analysts who each resolved it their own way.

Which leads to the reframe worth writing on a wall: model disagreement is not a bug, it is a detector. Every flip-flop is your system pointing at a decision your team never made explicit.

How to find the disagreements: active learning, not confidence

Use disagreement between runs as the selection signal, and ignore the model's own confidence.

The technique here is not new. Active learning is classical machine learning: you have far more unlabelled data than review capacity, so instead of checking everything (which defeats the point of having an agent) you select the small subset where a label teaches the model the most. Traditionally that meant picking the points where the classifier's probability sat near 0.5, or using query by committee — run several models, or the same model several times, and look at where they disagree.

For LLM agents, only one of those two survives.

Uncertainty scores from the model are not reliable. Lin's practical finding — the model doesn't know what it doesn't know, and high stated confidence does not mean correct — matches a well-documented result in the literature. Studies of verbalized confidence find LLMs systematically overconfident and poorly calibrated, producing decisive language while being unsure, and self-reflection prompts do not rectify it. Asking "how sure are you?" mostly gets you a number-shaped opinion.

Disagreement across runs does work. Run the case three times, or through two different models, and flag the ones that differ. That is a behavioural signal rather than a self-report, and it lands you on exactly the gray-zone cases. It costs a few extra inference calls on a sample of production traffic — much less than reviewing everything, and much less than a fine-tuning run.

What to do about it: two kinds of memory

Once you know which cases are ambiguous, the reflex is to reach for fine-tuning. Lin's argument is that you usually shouldn't: fine-tuning is expensive and slow to iterate on, and the thing you are missing is not model capability. It is information. The lighter fix is to augment the agent with memory — and the useful distinction, which maps onto the CoALA framework for language-agent architectures, is between two kinds.

Semantic memory: the rule, written down

Semantic memory is factual, general domain knowledge — the policy that disambiguates the gray zone. It is what you produce when a human reviews a flip-flopping case and distils why it should land on one side.

For the hotel: "If the complaint concerns something outside the hotel's control, classify as positive." For the SOC: "Password-spray attempts without a successful login are benign. The same pattern followed by a successful login is malicious."

Two things happen when you write that down. The agent's decision boundary sharpens, obviously. But so does your team's — the same written rule makes your human labellers more consistent with each other, which was quietly half the problem all along.

Episodic memory: what we decided last time

Episodic memory is the record of specific past cases and how they were resolved. Instead of reasoning from a distilled principle, the agent retrieves similar cases it has seen before and uses their outcomes as reference.

The advantage is that it is nearly free of human effort: the labelling work already happened, in the past, during normal operation. The agent can resolve recurring cases automatically without waiting for anyone to sit down and articulate the underlying rule. In alert triage that matters enormously, because false-positive noise is overwhelmingly recurring noise — the same handful of patterns, over and over.

They are complementary, and they form a loop

The two fit together as a pipeline, and this is the design worth stealing:

1. Sample production cases and run each several times. Flag the disagreements.
2. Episodic memory resolves the ones that match something already decided — automatically, no human involved.
3. What still flips after that goes to human review, which is now a small, high-value queue instead of a firehose.
4. The human's reasoning is distilled into semantic memory as a written rule, so the next case of that shape never reaches a human at all.
5. Repeat.

The numbers from Lin's production data: 93 security alerts, each run three times. Without the mechanism, about a quarter of them flip-flopped. With episodic memory in place, roughly 15 percentage points became consistent, leaving about 10% still flipping — either no similar precedent existed, or the model disagreed even with one. Those go to a human, whose written answer then feeds semantic memory.

That is not a magic number and your domain will differ. What it shows is the shape: most inconsistency is recurring and automatable, and the residue is a manageable human queue that gets smaller every week.

Three byproducts fall out of running this loop, and they are arguably worth more than the consistency itself: quality control that only inspects a targeted subset, a labelling budget with an unusually high return per minute, and an agent that visibly adapts to each customer's environment — because every rule you add is a preference that customer stated.

Which applications benefit most

1. Security operations and alert triage. Huge volumes, heavy recurring false positives, and gray-zone calls that genuinely depend on the customer's risk appetite. The canonical case.
2. Support ticket routing and prioritisation. Is this P1? is a policy question dressed as a classification question, and every company answers it differently.
3. Content moderation and policy enforcement. The boundary is the policy. Written guidelines are already the deliverable; the agent just needs to be able to read them.
4. Compliance, risk and underwriting review. Where a flip-flop is not just embarrassing but a finding, and where "show me the rule you applied" is a normal question.
5. LLM-as-judge evaluation pipelines. An inconsistent judge silently corrupts every metric downstream of it. Grading rubrics are semantic memory by another name.
6. Any multi-tenant AI product. One shared model, many customers whose preferences differ. Per-customer written policy is what turns a generic classifier into something that feels tailored.

How MDflow fits

MDflow is not an eval harness, an agent framework, or a memory database. It does not sample your traffic, detect disagreement, or run active learning. What it is: a markdown workspace that people and agents both read and write — which is the natural home for the semantic memory half of this loop.

Because notice what a semantic-memory rule actually is. It is not a vector. It is not a row. It is a sentence a human wrote, that another human should be able to review and argue with, and that an agent needs to retrieve at decision time. That is a document.

What already lines up today

Policy rules are plain markdown. "Password-spray without successful login → benign." "Complaints about factors outside our control → do not flag." These are prose with a few tables and code fences, written by domain experts. MDflow stores them as plain .md with nothing proprietary between the author and the agent, and every shared document has a raw .md twin with YAML frontmatter for agents that would rather fetch a URL than call a tool.

Folder descriptions tell an agent what a rule set is for. Each folder carries a description of what belongs inside it, and mdflow_get_context ranks those descriptions above folder names and document titles before returning the matching bodies. A folder described as "Alert triage policy — how we classify authentication signals for enterprise tenants" is a retrieval signal a human wrote deliberately, not one a model guessed. That is why folder descriptions matter more than file names.

Workspaces scope policy to the tenant it belongs to. One workspace per customer or product line keeps one client's risk appetite from leaking into another client's verdicts — which is exactly the failure mode you are trying to avoid when you make an agent adapt per customer.

Every agent reads the same rules. The same workspace is reachable from Claude, ChatGPT, Cursor, Codex and Claude Code over the remote MCP server with OAuth or a Personal Access Token, from your triage pipeline over the REST API, from the editor via the VS Code extension, and from automations through the n8n node. A rule only one tool can see is not a policy, it is a prompt.

Agents can write, not just read. The distillation step — turning a human's review into a durable rule — can be drafted by an agent over MCP into the right folder, then reviewed and edited by a person in the browser. That division of labour is the whole point: the machine drafts, the human decides.

Version history makes a policy change auditable. Line-by-line diffs, non-destructive restore, and a Document Log naming the actor on every write, including automated · <token name> when an agent writes. When an agent's behaviour changes on a Thursday, "which rule changed, when, and who changed it" stops being an archaeology project. (Version history is a Pro feature, private to the document owner, and not exposed over the API or MCP.)

Comments are where the disagreement gets argued out. Gray-zone calls are exactly the ones two experts will fight over. Threaded comments on a shared document keep that argument attached to the rule it is about, rather than in a Slack channel nobody can find in March.

What MDflow does not do. It does not store episodic memory. A queryable log of every past case and its verdict belongs in a database, a vector store, or your agent framework's memory layer — that is high-volume machine-generated state, and it should live in something built for it. MDflow holds the small, slow, human-authored half: the rules people wrote and stand behind. Keeping those two things in different places is a feature, not a gap.

Where we are headed

Direction, not a dated commitment. The interesting frontier for a markdown-native store is making written rules legible as rules rather than as prose that happens to contain one — a way to see which documents an agent actually read before it produced a verdict, freshness signals so a stale policy announces itself, and scoped tokens so an agent reaches only the policy folder its task needs. If you are going to hold a written rule responsible for an agent's decision, knowing what the agent was told is the first thing you need.

The bottom line

The instinct when an agent contradicts itself is to blame the model and reach for a bigger one, a colder temperature, or a fine-tuning run. Usually all three are the wrong lever. Bit-identical inference is a solved research problem you are not going to deploy, and the ambiguity underneath your flip-flops would survive it anyway.

The cases that flip are the cases where your organisation never decided. Find them by disagreement rather than by asking the model how it feels, resolve the recurring ones from precedent, and turn the rest into a written rule — once — so nobody has to decide it again.

Which makes those rules a real asset: small, slow-changing, expensive to reconstruct, and useless if they live only in a system prompt that one team can edit.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

Why does an AI agent give different answers to the same input?

Two different causes stack on top of each other. The first is infrastructure: LLM inference is not bit-reproducible, because kernels for matmul, attention and RMSNorm produce slightly different floating-point results depending on the batch the request lands in — so even at temperature 0 the same prompt can diverge. The second, and the one that matters in production, is ambiguity: the case sits close to a decision boundary where the correct answer depends on a policy nobody wrote down. Fixing the first does not fix the second.

Is AI agent inconsistency a model problem?

Usually not. Diane Lin of Datadog makes the case that flip-flopping outputs cluster around the decision boundary — in the gray zone where human experts also disagree, and where there is often no objectively right answer, only a company preference. The agent is not failing at the task; it is surfacing an ambiguity that already existed in your process and was previously hidden inside individual analysts' heads.

How do you make an AI agent more consistent without fine-tuning?

Augment it with memory instead of retraining it. Semantic memory is written domain knowledge and policy: a rule that says password-spray attempts without a successful login are benign, but the same pattern with a successful login is malicious. Episodic memory is a record of past decisions the agent can reference when it sees a similar case. Semantic memory sharpens the decision boundary, episodic memory resolves recurring cases automatically, and both are cheaper and faster to iterate on than a fine-tuning run.

How do you find which agent decisions are inconsistent?

Use disagreement, not confidence. Run the same case several times, or through several models, and flag where the verdicts differ — this is the classical active-learning technique called query by committee. It works better than asking the model how sure it is, because verbalized LLM confidence is measurably overconfident and poorly calibrated. Disagreement points to exactly the small subset of cases where a human review yields the most learning per minute spent.

Where should an agent's written policy live?

Somewhere durable, versioned, and readable by every agent and every person on the team — not buried in one system prompt. Policy rules are markdown documents that outlive the tool that consumed them. MDflow stores them as plain markdown in folders whose descriptions state what the folder is for, reachable from Claude, ChatGPT, Cursor and Codex over MCP or a REST API, with version history so you can see when a rule changed and who changed it.

Further reading

• Why Your Agent Disagrees With Itself (And What To Do About It) — Diane Lin, Datadog (AI Engineer, July 2026) — the talk this post is built on, including the 93-alert experiment.
• Defeating Nondeterminism in LLM Inference — Thinking Machines Lab, September 2025. Why temperature 0 is not reproducible, and the batch-invariant kernels that fix it.
• Cognitive Architectures for Language Agents (CoALA) — Sumers, Yao, Narasimhan & Griffiths. The working / episodic / semantic / procedural memory decomposition this post leans on.
• On Verbalized Confidence Scores for LLMs — why "how confident are you?" is not a usable selection signal.
• MDflow: agent memory consolidation, AI agent memory vs RAG vs a plain markdown file, folder descriptions as agent context, provenance for AI agent memory, and connecting an agent over MCP.