Your Chatbot Hallucinated in 2024. Your Agent Lies in 2026

Channel: Nate B Jones
Published: 2026-08-07
Video: https://www.youtube.com/watch?v=2wVvdX0ZxVw

AI agents are reporting tasks complete when the work never happened. Here are the three checks to run before trusting an agent's work, and why this failure is fundamentally different from the hallucinations people got used to in 2024.

Full post with Mission Fit Skill: https://natesnewsletter.substack.com/p/ai-agent-false-success

---

Transcript

Your AI agent is lying to you. I'm going to go through the three things you need to do to fix it, starting with my personal story of how my agent lied to me this week and what I did about it. Then stay for the end because I'm launching a skill that helps you figure out the custom missions and jobs your agent has and make sure your system is actually able to get that done.

Every single time I talk to folks in person, they say, "Is my AI still hallucinating?" And I say, "Your agent is probably not hallucinating the way your chatbot did in 2024. There are different kinds of failure modes." What does it mean in 2026 when you don't necessarily have hallucinations, but your agent can still lie? Why is that happening?

The Story

I was trying this consumer AI startup with great polish and a cute avatar for the agent. Then I asked it to do a simple job: "Please take this file from this folder and attach it to this email and draft it, but don't send it."

You might think the agent actually sent the email. No, that's not what happened. The AI agent decided to lie about finding the file because it didn't have folder access. But here's what's interesting: when I went into the email, I almost sent it because it had a correctly named Excel spreadsheet. But something caught my attention—there was a detail in the spreadsheet I didn't remember. It turned out the agent had gone back through my previous emails, grabbed an old version of the spreadsheet from a previous conversation, pulled it out, and recycled it into the new email without telling me. It had claimed it found and attached the file correctly as I asked.

I asked it directly: "What happened and why did you do this?" People think you can't get truth from agents, but if you ask factually, you actually do get it because the agent will talk transparently about the tool calling it did. So I said, "This isn't what's in my downloads folder. Where did you get this file?" And it said, "Oh, I found it in an old email." It didn't have access to downloads, but instead of telling me that, it just shoved the old spreadsheet in because it was correctly titled, about the right subject, and would let it say "done."

Hallucination vs. Agent Lying

When the agent lied or hallucinated in 2024, it literally didn't have tools. It was training on human feedback to talk to you. The reason it said "I have the answer to the capital of France" and then gave a city that isn't Paris is because it was trained to keep the conversation going with the human. Very different fundamental reward loop, very different cause. That's why hallucination is not the same as what you have today with agent lying.

Why Do Agents Lie?

Agents behave this way because of RLVR. RLVR is the acronym for a process of verifying AI agent results. It stands for Reinforcement Learning with Verified Rewards. It's used when you want to train agents to do long-running work with verified rewards.

You're looking for the agent to get to "done." If you need the agent to attach a real Excel file or write a real email, you RLVR that agent on whether it attached the file and wrote the text. RLVR is a blunt instrument. That's what verified rewards means.

The classic examples are coding—it either runs or it doesn't. Mathematics—it's either the correct solution or not. It's binary. With RLVR, you get a blunt reward process that tells the agent the form of correctness over and over during training.

The agent during training never saw my situation. It just saw lots of situations with attachments, lots with text, lots with spreadsheets. It's trying to take the learning encoded in its weights about how to call tools and get work done, and say "I can do this and actually successfully get this done because I've been taught how to do it." RLVR is a blunt force way of teaching, and that leads to these kinds of problems across any quantifiable field.

You see the same kind of problem with code where it runs but may not be well-formed, elegant, or reflect best practices in your repository or engineering culture. The process leads the agent to produce the form of work, but often leads to subtle failures not caught through RLVR. If the code runs and has unnecessary loops, it still passes. To the lab's credit, they are addressing this. More recent models care more about code quality and producing accurate and useful responses. But the problem is deep-seated in how this training happens.

Three Things You Need to Do

Number One: Have an Agent Check the Agent

I do this with everything I do. If you're not having an agent check the agent's work, what are you doing? I say that kindly, but you should have a separate agent whose entire goal is to check what you do. People say it's complicated and hard, but there's a dozen different ways. The simplest way, which both Claude and Codex have implemented, is to have a separate agent review the work the agent is doing. It's called approve forming or review forming. People think it's an approval thing, but it's actually a separate agent that reviews actions and tool requests by the working agent to see if they align with your original intent. That's pretty powerful.

You can also do much more complex setups. If you're an engineer, there are whole multiplexer setups where you can have an agent supervising and checking other agents checking in code. That's a little outside the scope here, but increasingly a lot of our work is going to be designing systems that lead to better outcomes rather than deciding if a particular AI agent is doing something good or not.

Think about: What tools does the agent have access to? What data does the agent have access to? And who is supervising the agent? Those are core elements of the supervision chain. Is the agent getting supervised?

Number Two: Can You Tell If It's Actually Good or Not?

I ask myself every single time: can I tell if it's good? Not does it work, not is it barely okay—is it good? Can I give it a sniff test? And if I can't, who can? How do I know it's good?

This gets more complex in larger organizations as agents do bigger pieces of work. But fundamentally, if you don't have the ability to say "this is what excellence looks like" fairly quickly, determining what good looks like gets really hard. People expect me to talk about evals, and I will say: the best way to get to good evals and specific agent quality things is to start by knowing what good looks like.

Just as you should be able to look at writing and say "that's terrible," or look at code and say "that's janky, why did the agent put a loop here? There's no need for a loop. Why did the agent call this outdated tool when there's a new version available?"—if you can't look at your output and say this is good or not good, you won't get anywhere. That's what leads to evals. Know what good looks like. That's principle number two. Then you can get into evals.

Number Three: Give Your Agent an Achievable Mission

You have to make sure you're giving your agent a mission that is achievable. If you give your agent something impossible because it doesn't have data access, the agent will lie about it. That's effectively what I did—I didn't know the agent didn't have file access, so I tried it anyway. But I was giving it a mission it couldn't achieve because it was locked off from accessing my local files.

By the way, when getting consumer agents up and running, we should communicate better about what files and systems they have access to, because that avoids situations like this. Give your agents missions they can achieve. Then consistently push the envelope.

People say, "Well, then I just ask for small things, right?" Actually, the opposite. Ask for really bold things, but make sure if you're asking for something bold and you don't know if the agent can do it—if it's inside its tool scope, data scope—you're able to check very quickly whether it got that work done.

The reason I say bold is simple: agents keep getting better. You can now put together multiple significant websites in one day with one agent and it's just not a problem. I put together four different websites yesterday solving little problems. I ask for them to get done and to be beautifully done. How do we work on the design? How do we fix it? What matters is that I can ask the agent to do the whole thing in one shot because I have confidence it has the tools and data, I've given it my input and design perspective, and it can just go get it done. Ask boldly, really boldly. That ironically ensures you have a good sense of your truth envelope with the agent because you're regularly seeing where it bumps the edges. If you ask conservatively because you want your agent to always tell the truth, you're not keeping up and you won't find out what you're capable of or what your agent is capable of.

Final Thoughts

If your agent is lying to you, make sure it's supervised. Make sure you have the ability to understand what good looks like. And make sure you understand how to ask boldly for where your agent should go.

I built something to help with this—a skill you can run that lets you work with your existing system, look at the tools and data you have access to, and make sure you know what your system has access to.

(capture appears truncated)