AI workers for Email apps

What is an AI worker for Email?

An AI worker for email is a scoped connection to a mailbox that can read, draft and send under rules set outside the model. The rules decide which correspondents are visible, which fields come back, and whether sending is allowed at all, so the worker inherits a narrow slice of the mailbox rather than the account.

What these workers do

Triage an overflowing inbox

A worker reads new mail, sorts it by what it actually is, and leaves a short summary of what needs a human.

Draft the replies nobody enjoys

Routine acknowledgements and status answers come back as drafts, so a person still presses send.

Pull the thread behind a question

When someone asks what was agreed, a worker reassembles the relevant thread instead of a person searching for it.

How an AI worker runs in your Email apps

Email is usually the first place a worker earns its keep and the first place it can do damage, because a mailbox is the single richest store of personal data most companies hold.

Start read-only and narrow. Allow the folders the job needs, block the correspondents it has no business seeing, and mask the fields that are never relevant. A worker triaging invoices does not need the thread with your lawyer.

Turn sending on last, and separately. Read access and send access are different decisions with different blast radii, so they are granted separately and can be revoked separately.

Email questions, answered.

Can a worker read my whole mailbox?

Only if you allow that. Access is scoped by folder, correspondent and field, and the default is that nothing is visible until you grant it. In practice a mailbox is opened a folder at a time, with the correspondents the job has no business seeing blocked outright and the fields it never needs masked before a message reaches the worker.

Can it send mail as me?

Sending is a separate permission from reading. A worker with read access cannot send unless you also grant sending, and you can allow drafting without sending so a person still presses send on everything that leaves. The two grants are revoked separately as well, so send rights can be withdrawn without taking the reading half of the job down with them.

What stops it from emailing the wrong person?

Blocked correspondents are rejected at the point of sending, not merely discouraged in an instruction. The rule lives outside the model, so a worker that has been argued into an unwise message still cannot deliver it, and the same list removes those correspondents from what it reads. Rate limits bound the rest, capping how much a single run can put out.

Will I know what it did?

Every read and every send is recorded, so the record exists whether or not anyone is watching at the time. Each entry names the worker, what it touched and the rule that allowed it, which is what makes an unexpected result answerable afterwards rather than a matter of reconstruction. The log is kept outside the mailbox, so it survives anything done inside it.