Silent. A check looked at a customer’s email address, decided it did not match the company they had named, and wrote that down. It was wrong: the address was genuine. Then the same check ran again, later in the same request, and wrote its finding a second time.
Nothing failed. The booking completed, the customer noticed nothing, and two entries now described one fact that was not true. This one comes from ArkOne’s own desk, so the note quotes a record rather than a supposition.
What went wrong
A check produces a finding. Something else has to decide what the finding is worth, and something else again has to make sure it is recorded once.
Both halves failed here, and the second is the one worth your attention.
The check itself was too coarse to be right. It compared a squashed company name against a squashed domain and asked whether either contained the other, which reports a mismatch whenever a firm’s domain is shorter than its trading name. Nothing about that is exotic: it is the ordinary fate of a test written to catch the obvious case. The design’s answer is not a cleverer comparison but a demotion, and the design was right about this: the check informs a person and never blocks a customer, which is why a genuine booking still completed.
The second failure is structural. The check runs at two points in one request, once when the address arrives and once when the run reaches the booking step. Neither call knows the other exists, so one fact produced two entries. In the Cabinet, ArkOne’s reference design for an executive agent, the Record is the ledger of every action with its reason, and it is append-only for a reason: a correction is a new line and the old one stands, so the ledger is evidence. Append-only makes a duplicate permanent, which is precisely why what gets written must be written once.
The record
ArkOne’s booking agent checks whether a visitor’s email domain matches the company they named. A visitor booked a call from an address at their company’s own shortened domain, so the comparison read a true address as a mismatch. Then it ran a second time, at a later point in the same request, and wrote its finding again.
| What happened | What the record received |
|---|---|
| The address arrives with the company name | First check runs. Writes: domain does not match the company |
| The conversation continues | Nothing further |
| The run reaches the booking step | Second check runs on the same two values. Writes: domain may not match the company |
| The booking completes | Two flags on one session, one address, one fact, and that fact was wrong |
Exhibit 1. Observed on ArkOne's own desk. One address, one true fact, two flags written in a single run.
Three things are worth separating there, because they are three different management problems.
The check was wrong: a legitimate address was reported as suspect. The check was also right to be only a flag and never a block, which is why the booking still completed; a test this coarse must inform a person rather than stop a customer. And the same fact was written down twice, because two points in one request each asked the same question and each recorded its own answer.
The last is the quiet one, and there is a detail in it worth knowing. These flags do not land in an append-only ledger at all: they are written into a session log that is rewritten in full on every turn. So the duplicate is not even durably countable. That is a worse position than a permanent double entry, because a mutable log cannot be audited afterwards and a double entry at least tells you the checks ran twice.
What it means for you
The instinct is to fix the comparison, and the comparison should be fixed. That is the smaller half.
The larger half is that a system which records one finding twice cannot be counted, and a count nobody can trust is the input to every decision made about the thing being counted. Ask how many false alarms your agent raised last month and you will be given a number. Whether that number is a count of alarms or a count of times the code checked is a different question, and it has a different answer.
The cost is measured in trust. Every false positive teaches whoever reads the output to discount the checks, and a check nobody trusts is a check nobody acts on the day it is right.
So ask for one artefact rather than an assurance: the list of every place in the code that writes a flag, and the name of the thing that guarantees one event produces one entry. If the answer is a location, the count means something. If the answer is that duplicates would be obvious, ask how they would be obvious in a log that is overwritten on every turn.
Asked plainly
Why does an AI agent return an irrelevant document as if it were the right one?
Because a search by meaning always returns its nearest match. Nearest is a ranking, not a verdict: it says everything else was further away, not that this one is close enough. Unless something separately decides whether the nearest match is good enough to use, the agent is handed the best of a bad set and has no way to know it.
How should an AI agent handle a weak match?
By discarding it. The reference design sets a line and drops anything beyond it, on the reasoning that no match can be reported honestly while a weak match gets quoted with the same confidence as a strong one. It also skips the search entirely for messages too short to carry a question, so a greeting never retrieves a document at all.
What is a false positive in an AI agent's checks?
A check reporting a problem where none exists. It is more damaging than it looks: every false positive teaches whoever reads the output to trust the checks less, and a check nobody trusts is one nobody acts on when it is right.