An AI that argues against its own finding: what observability means for an agent on your endpoints

Picture the meeting where an endpoint agent gets approved. The service desk lead is enthusiastic, because the demo found a fault in four minutes that their best engineer had been circling for a month. The security reviewer, who has sat through this kind of demo before, is quieter, and the question they eventually ask is not about accuracy. It is about the day the agent is confidently wrong: it tells a technician that a disk is failing when the disk is fine, the technician believes it because the agent has been right for six weeks, and a working laptop gets replaced on the say-so of a model nobody can cross-examine.

That question deserves a better answer than "our accuracy rate is high," and this piece is about what the better answer looks like, because we spent a long time building Rapport around it. The short version is that an agent that will touch your endpoints has to be observable in two senses at once. You need to see how it reasoned to a finding (and how sure it was), and you need to see who let it take each action, on whose authority, with a record you could put in front of an auditor afterward. The first sense is about trusting the diagnosis. The second is about governing the agent, and it is where the agent governance conversation your enterprise is already having about copilots and workflow bots lands on the device.

Start with the diagnosis, and with a sentence our own product wrote that we did not expect to see.

What did the agent say when nobody asked?

During our internal pilot, a technician asked Rapport to look at a desktop whose user had complained for a month that it "stutters and locks up." The agent worked through the usual suspects (memory pressure, crash history, GPU driver resets, hardware error events, disk latency), and every one came back clean. Then it ran a check nobody runs on a stutter complaint and found that the NTFS volume was flagged dirty: Windows had been asking for a full disk check at every boot for a month, 45 times in 30 days, and could not repair the volume while the system was running. That was the finding, and it was a good one.

What followed in the same report, without any prompting, was this:

A few lines later, the agent flagged that it could not perform the repair itself (it had no administrative rights from where it was running, and the fix needed a reboot with somebody at the machine), so it wrote the instruction for a human to carry out instead.

We have shown that paragraph to a lot of technical buyers now, and the reaction is always the same: that is the slide that sells, and it is the one nobody expects. Every buyer's real fear is an AI that overstates its case and gets believed. Here is a product volunteering the weakness in its own evidence (a correlation, not a proof; a six-second sample on an idle system that rules nothing out) before anyone challenged it, and then volunteering that it could not act on the finding either.

At Rezolve.ai, we believe this behavior is the difference between an agent that gets adopted and one that gets switched off in month three. A tool that is always confident gets used twice, caught once, and then ignored by the senior engineers whose trust you actually need. A tool that marks the line between what it proved and what it inferred is one those engineers will read, argue with and come back to, which is what explainability of the reasoning buys you.

What should you be able to see in a session?

Marking confidence is necessary but not sufficient, because a confidence statement is itself something you have to take on trust unless you can see the work behind it. So the second thing to ask of any endpoint agent is a complete session record: every turn of the conversation, every tool the agent called, the result each tool returned, and every point at which a human approved or declined an action, in the order they happened.

In Rapport, that record is the Agent Sessions view. Each recorded on-device session shows the request, the device, who started it, its status, the number of turns and the approval steps it went through, and opening a session shows the full transcript with the tool results inline. The reason to insist on this level of detail is not forensic curiosity. A technician who can see the agent ran a six-second latency sample can judge for themselves whether six seconds was enough, instead of taking the agent's summary of its own limitation at face value. The agent's self-doubt and the technician's ability to verify it are two halves of the same thing.

The product is careful in its own language here, and that carefulness is worth noticing: the sessions page says plainly that a session's status does not establish that the device issue was resolved. A resolved session means the conversation ended, nothing more, and the product will not let you read more into the word than that.

Who decides what the agent is allowed to do?

Now the governance half, which is the question your security reviewer was really asking.

Rapport's reasoning happens in the cloud, through our gateway, and a native agent on the device does the execution. The control that matters is where the decision about each command is made, and in Rapport, it is made on the device by the native agent, not by the model. Every command the model proposes is classified locally into one of three bands.

Read-only checks run on their own where your policy allows them to. Anything that changes the machine or needs elevation waits for a named person to approve it. Destructive or disallowed commands are refused outright, every time. A model asking for something is not permission to do it.

On top of that sits an approvals queue with a rule worth wanting in any agent that touches production: nobody approves their own request. Per-incident approval is the default, and a script that a detection rule has queued for execution needs a second administrator who wrote neither the rule nor the script. It is the same four-eyes principle your change board already applies to a server change, applied to an agent's proposed action on a laptop, and it is what stops an engineer writing a rule, writing the script it triggers and waving both through.

Two further controls round this out. The agent makes only outbound HTTPS connections on port 443, with no inbound port, no firewall exception and nothing for your network team to host or open. And execution can be switched off entirely while the investigation still runs. That last option matters more than it sounds, because a security team that will not allow any command execution in year one still gets the diagnosis, and the diagnosis is most of the value. We have published a disclosure of exactly what data leaves the device, so your reviewer can read it rather than take our word for it.

Why is this an agent governance question and not an AI governance one?

Your enterprise probably already has an AI governance effort, and it is probably focused on models: was the output fair, was the training data appropriate, does the copilot hallucinate. Those are the right questions for a model that produces text for a person to read. They are the wrong questions for an agent that runs commands on 24,000 laptops.

Governing a model asks whether its output was fair. Governing an agent asks who let it take that action, on whose authority, and whether you can prove it afterward. Bias testing tells you nothing useful about an agent that reimaged the wrong machine, and an accuracy benchmark tells you nothing about whether the technician who approved a registry change had the right to. The evidence an auditor will want from an endpoint agent is the evidence you want from any agent that acts: the proposal, the classification it received, the person who approved it, the result, and the reasoning that connected them. That is the session record described above, read as an audit trail rather than a debugging aid.

If you are building a governance framework for agents more broadly (we have written separately about agent sprawl), the endpoint agent is the hardest case in it, because the blast radius of a wrong action is a physical machine in someone's home office. Use it as the test: if your framework can say who was allowed to let an agent reboot a laptop, and show the record, it can probably govern the rest.

What to ask in the approval meeting

So, back to that security reviewer's question. The answer you should want from any vendor in this category, including us, has five parts, and you can ask for each of them in the room.

Ask to see a session where the agent was wrong, or where it said it was unsure, because a vendor who can only show you successes has either not run many sessions or is not recording them. Ask where the classification of a command happens and whether the model can override it. Ask whether anyone can approve their own request, and who approves a rule-triggered script. Ask for the session record for a real investigation, with the tool results, and check that the confidence the agent claimed matches the evidence it collected. And ask for the data-boundary disclosure in writing.

The agent that argued against its own finding on our pilot desktop was, as it happens, right about where to look: the dirty volume was there in the log, flagged at every boot for a month, exactly as described. But the reason to trust the next finding it produces is not that it was right that time. It is that it said how sure it was, showed the six-second sample so a person could disagree, and could not have acted on the finding without a person saying yes.