When Your Agent Confidently Does the Wrong Thing

Your agent didn’t make anything up. It read the ticket exactly as written and did exactly what it said.

The problem was the ticket was wrong. Someone reversed the decision in a meeting three weeks ago and nobody went back to update it. The agent had no way of knowing that. It saw one source, trusted it, and moved.

That’s a different kind of failure than a model inventing a fact. The agent followed real information. The information just wasn’t current anymore. Thor is the context infrastructure for AI-native software teams, a living model of what’s true that turns conversation into approved action, built for exactly this gap between what a tool says and what a team actually decided.

Why does an AI agent do the wrong thing so confidently?

Because nothing told it otherwise. An agent reading a ticket, a spec, or an old thread has no built-in way to know the document is stale. It doesn’t second-guess a clean, well-formatted page. It executes what’s in front of it, including the part that’s three weeks out of date.

This is the exact shape of the problem behind why Thor exists in the first place: company knowledge doesn’t go stale all at once. Someone settles something in a meeting. Someone else changes it in Slack two days later. The doc still says the old thing, the ticket says something close but not quite, and the code already reflects a third version nobody wrote down anywhere. None of that is anyone lying. The company just moved faster than its own paperwork.

A person running into that same mess usually notices something is off. They ask in the channel, or check with whoever owns the ticket before shipping something big. An agent reading the same documents doesn’t have that instinct. It reads what’s there, treats it as true, and acts on all of it, wrong parts included.

Underneath that is a harder problem than any one wrong ticket. Agents and the humans directing them either work with weak context, or someone on the team spends real engineering time building infrastructure to fake strong context: a shared memory store, a scraper that pulls decisions out of docs, a cron job that tries to reconcile Slack against Linear. SDLC automation stalls without a stable answer to “what’s actually true right now,” and most teams end up building a half version of that answer themselves before they realize how much upkeep it needs.

What does this look like in a real coding-agent workflow?

It rarely looks like a dramatic failure. It looks like an agent doing competent, well-formatted work against the wrong target.

A few concrete shapes this takes, all versions of the same root cause:

• An agent in Cursor or Claude Code opens a PR that correctly implements a spec doc, except the spec doc describes a version of the feature the team walked back in a design review two days after it was written.
• A review agent approves a pull request because the linked ticket’s acceptance criteria still match the old requirement. Nobody edited the ticket after the meeting where the requirement changed; the code is “correct” against a target that no longer exists.
• A standup-summary bot reports a task as blocked, because the tracker still shows the blocking dependency as open. The block was actually cleared in a side Slack thread twenty minutes earlier, and nothing wrote that back into the tracker before the summary ran.

None of these agents malfunctioned. Each one read an available, well-formed source and trusted it. The failure sits one layer up, in which source got read and how current it was, not in the model’s reasoning.

Why is this worse with an agent than with a person making the same mistake?

Speed and volume. A person who acts on a stale ticket makes one bad call, and it usually surfaces the first time someone reviews their work. An agent wired into a dozen workflows can act on that same stale ticket in a dozen places before anyone notices.

One wrong assumption handled by a person costs one bad decision. The same wrong assumption fed to an agent that’s running continuously can turn into several tickets updated the wrong way, a PR opened against the wrong requirement, and a status report that repeats the error back to the team as fact, all before a person reviews any of it. The mistake isn’t different in kind. It’s different in how far it travels before someone catches it, and in a pipeline where one agent’s output becomes the next agent’s input (a spec agent feeding a coding agent feeding a review agent), a stale fact doesn’t just repeat. It compounds at every handoff, because each step has no reason to distrust the step before it.

That’s not an argument for slowing agents down. It’s an argument for giving them something better to read before they act, not just more of them, and for putting real guardrails around agents running at that kind of volume.

Doesn’t a bigger context window or a RAG pipeline fix this?

No, and the reason is specific: a bigger window or a better retrieval pipeline changes how much an agent can read, not which of the things it reads is actually current. A cheap guess is still just a guess with a source and an undo button missing.

Retrieval-augmented setups have their own version of this problem. A vector index built from your docs and tickets is only as fresh as its last reindex, and a lot of production RAG pipelines reindex on a schedule, not the instant something changes. Relevance and recency are also different questions: a search can return the passage that best matches the query’s wording while missing that a newer passage elsewhere already superseded it. Neither a bigger window nor a better retriever tells the agent which of five semantically similar chunks is the one the team actually stands behind today.

Why doesn’t wiring everything through MCP solve it either?

MCP gives an agent a way to reach a tool. It doesn’t give the agent a way to know if what it fetched is still true, and in practice, raw MCP has its own operational problems on top of that. There’s no solid caching or aggregation layer by default, so every read can mean another slow, metered round-trip instead of one lookup against something already put together. OAuth tokens tied to those connections expire, which means someone ends up babysitting a pipe instead of building. And a naive setup can leave an agent stitching together five raw MCP round-trips just to answer one question that should have been a single lookup against an already-checked answer.

That’s why Thor connects to tools like Slack, GitHub, and Linear with native integrations at the API and CLI layer instead of routing everything through MCP by default. It still exposes an MCP surface for the handful of cases that need it, and keeps that surface deliberately small, but MCP is the exception here, not the transport for everything. If your agent’s context problems keep tracing back to how it’s wired into your tools, the transport is usually not the part that needs fixing.

What would have caught this before the agent read it?

A single checked answer the agent reads instead of the fastest note it can find. Thor keeps that answer sourced, so you can see who decided what and when. It’s reversible, so a bad update can be rolled back instead of overwritten in the ticket with no record it happened. It’s governed, so nothing becomes official just because an agent sounded sure.

Concretely, that answer lives in a data layer built as a live graph of work items, people, projects, and decisions, not five raw tool connections an agent has to reconcile itself every time it asks a question. Instead of your agent grabbing whatever it can reach and hoping it’s current, it reads Thor’s living model of what’s true: the same story your team can see, kept current as decisions actually change, not a snapshot from whenever someone last synced it.

The governance part matters as much as the source. Thor proposes an update; a person or a clear rule approves it before it becomes official. Small, easy-to-undo changes can go through automatically. Anything that creates a real commitment, like who owns something or a promise made to a customer, waits for a person. Nothing here happens because an agent decided on its own. It flags what changed, and someone with the context to be right approves it. The same discipline applies as agent volume grows; it’s part of why guardrails for running agents at scale matter more, not less, the more of your SDLC you hand to them.

Does this fix every agent mistake?

No. An agent can still misread a checked answer, and a person can still approve the wrong update. What sourced, reversible, and governed context actually removes is the specific failure this piece started with: an agent executing a stale answer with total confidence because nothing told it the answer had moved. That’s a narrower problem than “agents make mistakes,” and it’s the one Thor is built to close.

FAQ

Does this mean the agent is broken?

No. It did what it was built to do: read the input and act on it. The ticket was the part that was broken, or at least out of date. Fixing the agent doesn’t fix that. Fixing what it reads does.

Isn’t this just hallucination with extra steps?

No, and the distinction matters for how you’d fix it. Hallucination is a model generating something that was never true anywhere. This is a model acting on something that was true once and has since changed. A better model doesn’t fix stale input; only fresher, checked input does.

Isn’t a bigger context window enough to solve this?

A bigger window lets an agent read more stale documents faster. It doesn’t tell the agent which one is actually current. More context without a checked source just produces more confident wrong answers.

Does Thor replace my vector store or RAG pipeline?

No. Retrieval is still how an agent finds a relevant passage. What Thor changes is whether the underlying record being retrieved from is current and checked, versus a raw doc or ticket that might already be stale.

Does Thor stop an agent from acting until a person signs off on everything?

No, and that’s the point. Small, easy-to-undo updates go through automatically under clear rules. Bigger things, like ownership changes or a commitment to a customer, wait for a person.

What if the agent is already connected through an MCP server?

An MCP server is a pipe, not a source of truth. It’s only as current as whatever it’s pointed at, and it inherits every operational problem of the tool on the other end: rate limits, token expiry, and no cache of its own. If that source is a stale doc, MCP just hands the agent a faster route to the same wrong answer.

See how your agents work from one checked answer instead of a stale ticket.