Agents do not get a separate inbox. Same CAN-SPAM rules, same Gmail thresholds, same need to split marketing from transactional on the wire.
An agent can start a campaign through the same sending infrastructure as a person. Gmail still sees the sender, domain, and message.
Mailbox providers score domains, IPs, and complaint rates. They do not score whether a human clicked Send. If the agent ships a promotional body through the transactional IP, you inherit the same problem you would have created by hand, only sooner.
This is a companion to the email deliverability guide, not a replacement. That post covers reputation, authentication, and list hygiene. This one is about the mistakes that show up when software is the one hitting send.
The agent is another client on the same sending identity. The inbox still sees your domain.
CAN-SPAM applies to commercial messages. The primary-purpose test is about the subject line and the body, not about who typed them.
For a message mixing an invoice and an offer, assess its primary purpose. The subject, placement of the account information, and prominence of the promotion matter. A brief promotional footer does not automatically make an account statement commercial. The FTC guidance includes examples. Commercial messages need truthful headers and subjects, a physical address, and a working opt-out.
The same is true in reverse. A password reset the agent triggered on a real security event is still transactional, as long as the body stays on that event.
Gmail's sender requirements include rules for all senders and stricter rules for bulk senders reaching roughly 5,000 messages a day to personal Gmail accounts. Those stricter requirements include:
p=none or stricter policy.List-Unsubscribe and List-Unsubscribe-Post.Transactional mail is exempt from the one-click rule. It is not exempt from authentication, and it is not exempt from spam complaints if you load the template with a sale.
Yahoo asks high-volume senders to put marketing and transactional on different IPs, and preferably different domains. Check which sending identity the agent will use instead of leaving it to a vague default.
Give the agent a promotional sending identity for campaigns and automations. The domain you warm, the IP you expect complaints on, the unsubscribe headers you have tested.
Keep transactional mail on a separate identity. In Brew that identity is a domain with a transactional sending purpose, and the mail itself is a published automation with a trigger. The agent can compose the template. The send path per event should still be POST /api/v1/automations/triggers/{triggerEventId}/fire with a JSON payload, not "send this draft to the list."
Do not let the agent pick the From address from a pile of verified domains "to see what lands." That is how you train two reputations at once and understand neither.
The failure mode is not a typo. It is a fluent paragraph that cites a number you never published, or a subject that looks like a receipt.
Before you let an agent send without a queue:
Cory Nelson at Harmonya told Noah Adelstein he did that first-campaign read before he trusted the loop. That is the correct order.
Authenticate the domain, choose the correct sending identity, and review the first campaign against the approved brief. Check the assistant's permissions and confirmation settings too. MCP clients do not all ask for approval in the same way.
The brief that stops invented numbers is in how to brief an email agent. The Harmonya first-campaign read is in how Harmonya turned a newsletter into a lifecycle program.
