Can it sign a message as one of my staff?
Look at the bottom of the last email your company sent a client. A name sits there, and your finance director owns it in every sense that matters: it is what the client relies on, what your insurer assumes, and what a court would read aloud. The question to put to a vendor is a small one about a signature line, and underneath it is a question about who is answerable when the message turns out to have been wrong.
Recognition, and what it is not
Any agent worth buying keeps a roster of the real people it works with. In ArkOne’s reference design for an executive agent, the Cabinet, that roster is the Directory: each colleague listed with the addresses and handles they write from, the approvals they may give, and the hours they keep. A message from an address on no entry is dropped without a reply, a setting on the Register.
Two uses of an address sit close together. The first is recognition, inbound: a message arrives from an address on the finance director’s entry, so the room treats it as hers. The second is signature, outbound: the room sends something with her name at the bottom. The reference design does the first and refuses the second, and the roster lends it nobody’s identity.
The refusal costs something, which is why vendors offer the alternative. A message signed by a familiar colleague gets opened and answered; one from a machine is read more slowly and sometimes ignored. That reply rate is what is being sold when impersonation arrives as a feature, and its price is the paragraph above. The paper on the Directory sets out the roster.
What you will hear across three demonstrations
Suppose the question lands mid-demonstration, in three separate meetings, and nobody in any of the three has anything to hide.
| What a good answer sounds like | What you will be offered instead | What that hides |
|---|---|---|
| It sends as itself. The recipient sees an agent address, and the approving person is named in the record | It sends from your team’s inbox so replies land in the right place | Deliverability described as identity. Where replies land and whose name is on the message are separate decisions, and only one was answered |
| Impersonation is refused in code, not by a setting on a screen | That is fully configurable | A configurable identity is an identity that changes when somebody in a hurry changes it, and the change leaves no mark on the message |
| A human approval is recorded against the person who gave it | There is human review before anything goes out | Review of the text, not of the sender. Your colleague approved the wording and became the author of it |
Exhibit 1. Illustrative. Three replies about identity, and the liability each of the weaker two leaves with you.
The first row is worth naming plainly, because it is usually not a deception. A vendor solving reply routing has solved something real, and has not touched the question you asked.
The second row is where the harm compounds. A rule in code is one a salesperson cannot switch on for a pilot; a setting is one a growth-minded manager switches on in the third month, and the message that goes out looks exactly like every message that went out before it.
The follow-up worth the meeting
Ask them to send you one, live, from the demonstration environment, and then read the header with them on the call.
You are looking for a sender your recipients could tell apart from a colleague without being told what to look for. A display name that reads as a person, with the machine’s address a click away, is impersonation with a technicality attached. Ask what a client sees on a phone, where the address is often not shown at all.
Then ask the harder half. When the agent proposes something and a person approves it, whose name goes on the outgoing message, and where is it written that the approval happened? A good answer keeps the two apart: the agent sends as itself, and the record names the person who authorised it, in a ledger you can read afterwards. That separation lets your finance director say, a year later, exactly what she approved and did not write. Put it beside the question about what stands between a decision and a sent message.
A vendor offering impersonation as a benefit is doing nothing unusual; email tooling has worked this way for years. The difference is that the tooling wrote nothing. This one decides, writes, and then signs, and the name it signs with is the one your client will quote back at you.
component: answer-card
Asked plainly
Can an AI agent send an email that looks like it came from an employee?
Technically yes, if it is given that person's mailbox or a sending domain that permits it. Whether it should is a design decision. In the reference design described here the agent sends under its own identity only; a colleague's addresses are how the agent recognises that colleague, not a name it may sign with.
Why does it matter whose name an AI agent sends under?
Because the name on a message is what a recipient relies on and what a court later reads. A message a client received under a named employee's signature is evidence of what that employee said. If a machine wrote it, the employee must reconstruct what happened from logs, months later, in front of someone disputing it.
What should an AI agent's outgoing messages show?
Its own sender identity, visible to the recipient, plus a record of which person authorised the action where an approval was required. The recipient should be able to tell without effort that they are reading something an agent sent on the company's behalf rather than a colleague's personal correspondence.