Silent. You ask your agent to send the revised schedule to the new site manager at a supplier. Back comes a confirmation: sent, with the address it went to, which reads exactly as that supplier’s addresses read. The site manager does not have that address. Nobody has it. The schedule went nowhere, or it went to a stranger at the same firm who now holds a document about work they have nothing to do with, and either way the matter is closed in your inbox.
What went wrong
There are only two honest answers to where an address came from: it was looked up in a list somebody maintains, or it was produced on the spot.
The list is the Directory, the roster of the real people the room knows and may address in the Cabinet, ArkOne’s reference design for an executive agent. A roster is stored, dull and finite: names, addresses, and what each person is permitted to approve, named per person rather than held in common. An address is on it because a human put it there, and that is the whole of its authority.
What happens when the name you gave is not on the roster is the entire mechanism. If the lookup answers with a refusal, the agent has a fact to work with and will tell you it cannot send. If it answers with nothing, the agent still holds an instruction to send and still needs an address, and producing text that fits a pattern is the thing it does best in the world. Company addresses are a pattern. So the gap gets filled, fluently, and the send proceeds.
The reference design treats an absence as something that must speak. A request for a capability the room does not have is met with a refusal naming the missing piece and restating what the room does hold, never with silence. A message from anyone not on the roster is dropped unanswered rather than half-handled. And when the Door, the rules that decide what may leave the room, refuses a send, the reason goes back to the Chair, the loop that runs the meeting, so it reschedules instead of retrying in the dark. What none of that buys is a complete roster, and the roster is only as complete as the person keeping it: a genuinely new site manager who has not been added yet produces a refusal rather than a send, and somebody has to stop and add them. That is the trade in plain terms. An invisible failure becomes a visible piece of admin, and the admin has an owner. The same gap read from the other direction produces an agent that does not know who it is writing to. The twentieth paper sets out the roster and the sixteenth the refusal; both settings sit on the Register.
The record
Suppose a soil and water testing laboratory of some seventy people whose agent handles scheduling correspondence with the clients whose sites it samples. The laboratory, the client firm, the site manager and the address below are invented for this exercise.
| What the agent looked for | What came back | What it did |
|---|---|---|
| The site manager’s address | Nothing at all | Wrote an address on the client firm’s domain in that firm’s usual form, sent to it, confirmed the send |
| The site manager’s address | No entry on the roster, and the roster’s other contacts at that firm | Reported that it could not send, and named the two people it could write to instead |
Exhibit 1. Illustrative. One instruction to send, with the missing address absent and then refused.
One row is a silent failure and the other is a piece of admin. The difference is not the model, the instructions or the roster. It is what the empty lookup returned.
The first row is worth sitting with, because the agent did nothing you could call an error. It was told to send, it had a recipient by name and a company by name, and it had no address and no sign that the absence mattered. Inventing one is the only route from that instruction to an outcome, and the invention is good: right domain, right shape, indistinguishable from a real address to anybody reading the confirmation, including you.
The expense is in the confirmation being truthful about what it reports. A message was composed and a send was made. Whether anything arrived is a separate fact in a different system, and nothing joined the two.
What happens
The agent is told there is no address on the roster for that person, so it reports a message it could not send and asks who should receive it.
What your company sees
A message that was not sent, and a named gap in the roster to fill.
What it means for you
Make the gap speak. Something has to answer the empty lookup with a refusal that names what is missing, and the agent has to be unable to walk past it. That is the whole of the remedy, and it is a property of the lookup rather than of the model.
Which is why the first answer you will be offered does not hold. It is an instruction: never guess an email address, always confirm the recipient first. That line reads as sound governance. An instruction governs what a model does with what is in front of it and cannot conjure a fact that is absent, and the guess was never disobedience, it was the gap being filled by the only thing to hand.
The test that does hold is a small piece of theatre. Invent a colleague on the spot, give the agent that name and nothing else, and tell it to send them the document on the screen. One of two things comes back: a message saying it has no address for that person, or a confirmation that something was sent. You do not need to interpret either. Follow it by asking who keeps the roster and having them open it, because that person is the honest cost of the whole arrangement.
One more while you have their attention: when a send is refused, does the agent learn why. A refusal it cannot read is an absence of its own, and it will be filled the same way.
Next: The approval that was a guess: a vague yes read as consent.
Asked plainly
Why would an AI agent invent an email address?
Because it was asked for one and nothing told it that it did not have one. A model's strongest ability is producing text that fits a pattern, and a company's addresses follow an obvious pattern. If the place the agent looks for an address returns nothing rather than a refusal, the request still has to be answered, and the most fluent answer available is an address that looks correct.
How should an AI agent get someone's contact details?
From a stored roster of known people, and from nowhere else. A roster is a list somebody maintains: names, addresses, what each person may approve. An address that is not on it is not a harder case to work out, it is a case the agent must be told it cannot fill, because the alternative is a guess nobody can distinguish from a lookup.
How would I know if an AI agent sent a message to the wrong address?
Usually you would not, which is the problem. A send to an address that does not exist may bounce somewhere nobody reads, and a send to an address that does exist and belongs to a stranger produces no signal at all. The agent's own report says the message was sent, because from where it stands the send was made. The check is to compare what was sent against the roster it was allowed to send to.