Should the agent that reads the web be a different agent from the one allowed to send mail?

Yes. The agent that reads the web should be a different agent from the one allowed to send mail, and in practice the mail side should not be allowed to send either. It should write a draft you send. The split still matters if you insist on a send tool: the reader never has it. A page the reader fetches can influence the next action. If that same agent can send, the page has a path to your outbox. Two agents, two tool lists, and a person carrying the text from one to the other. Not one agent with a browser and a mailbox because that was convenient.

Same model, even the same machine, is fine. Same tool list is the failure.

What went out when they were the same agent

I had one agent that could browse and draft mail, because the task was “read the vendor’s status page and email Sam if the outage is real.” That is a reasonable sentence and a bad grant. The status page was real. The agent summarized it, then sent. The summary included a sentence from a banner on the page that was not the incident, and it named a recovery time the banner had invented in the way marketing banners do. Sam got a confident note. I got a reply asking why we had promised a time I had not checked.

The page did not need to be a special attack. It was just text in the same context as a send tool. The model treated the page as source material for the email, which is what I had asked, and it did not have a gap where I could delete the banner sentence. The gap has to be structural. The reader finishes. I read. A different agent, or just me, writes the mail from the sentences I kept.

After that I took send off the browsing agent the same day. I did not add a warning. The warning would have sat under the banner, and the banner was louder because it was the latest text.

What each agent is allowed to hold

The reader gets a browser profile with no logins and no mail tool. It can open public pages and write a note into a folder. It cannot see my inbox, cannot create a draft in the mail product, and cannot address Sam. If a page says to email someone, the reader can quote that request in the note, where I will see it as a quote, and it cannot perform it.

The mail agent, if I use one at all, gets the note I pasted and a draft file. It does not get a browser. It cannot “just check the page” to improve the draft, because that check is how the page comes back into the outbox. If the note is incomplete, the mail agent says so. I go back to the reader, or I open the page myself. The inconvenience is the control.

I do not give the mail agent send, for the reasons a send tool finishes the verb while I am away. The split still helps if someone later turns send on for the mail agent only. A hostile or sloppy page cannot reach that tool, because the page never enters that agent. The person in the middle is the filter. You can skip the mail agent entirely and paste from the reader’s note into your own client. That is the version I actually use. The second agent is optional. The separation is not.

Why “same agent, be careful” does not hold

One agent with both tools will use both when the task has two verbs. “Read and tell Sam” is read plus send, and the model will sequence them without waiting, especially if send is how “tell” gets completed. A prompt that says “ask me first” loses to the tool that completes the task, and it loses harder when the page repeats the instruction to contact someone. I am not going to describe how a page phrases that. I am going to refuse the tool pair that makes the phrasing matter.

A shared memory makes the split fake. If both agents read the same transcript, the reader’s page text is in the mail agent’s prompt anyway. Then you have two names and one context. I keep their sessions separate. The only thing that crosses is a file I copied, or a paragraph I pasted, after I looked at it. Automation that forwards the reader’s raw output into the mail agent is the same agent with a queue in the middle. Do not build that queue.

Credentials follow the same rule. The reader’s browser profile is empty. The mail side does not get a mailbox login. If you connect Gmail to the mail agent “only for drafts,” test that it cannot send, and do not also point it at the web. A draft tool plus a browser is most of the original problem, one click short of send.

What you lose by splitting, and why I pay it

You lose the demo where one chat reads the status page and the email is already gone before you stand up. That demo is the bug. You also lose a little speed: I retype or paste a paragraph. On a normal day that is a minute. The minute is where I remove the banner’s recovery time and the extra recipient the page suggested.

You do not lose the ability to research. The reader still reads. You do not lose a written email. You gain a draft that has not been in a context with the raw page. If the research was wrong, the mail does not exist yet. I would rather correct a note than recall a message.

Teams sometimes want the reader to hand off automatically when a condition matches, “if the page says resolved, send.” That condition is evaluated by the same model that just read the page. It will match too often. A human condition is fine: I decide it is resolved, then I send. An agent condition plus send is the unsplit agent again.

How I check the split is real

I look at tool lists, not at names. If the reader’s list contains send, draft, or a mailbox, it is not a reader. If the mail agent’s list contains a browser, search on the open web, or a URL fetch, it is not sealed off from pages. If they share a session id or a memory store, I assume page text can cross.

Then I run a boring test to myself. The reader opens a public page. I ask the mail side what the page said, without pasting. It should not know. If it knows, something is shared: memory, a file watch, a coordinator that stuffed the page into both prompts. I break that share before I care about prose quality.

The coordinator, if I have one, may assign “read this URL” only to the reader and “draft from this note” only to the file. It may not assign a compound sentence to either. Compound sentences are how the tools get reunited. I split the sentence myself.

Files and chat are not a third agent

People keep the browser and the mailbox on one agent and say the file tool is the safe part. It is not a separation. A file the reader writes can contain the page, and the same agent can attach that file to a mail tool in the next call. I have watched a “research notes” file become the attachment on a message I had only asked it to prepare. The notes were fine. The attach was the send path waking up because both tools lived together. A different agent that cannot see the reader’s files unless I copy one across is what stops that. A shared drive both agents watch is a tunnel. I copy by hand into a folder the reader cannot write.

Chat apps are the same trap if one bot identity sits in your messages and also browses. The person on the other end of the chat experiences one assistant. That is a product choice. The tools behind it still need two allow-lists. If your host only supports one bot with one tool list, do not add mail to the bot that can open URLs. Use the bot for reading, and send the mail from your own client. A single identity is not a reason to unify the grants. It is a reason the split has to be in the configuration, where a user will not see two names and assume they are protected.

The pair I want

A reader that can browse and cannot mail. A draft that cannot browse, written by me or by an agent that never saw the page except through text I pasted. Send stays on my side of the keyboard. One agent that can do both will, and the page it just read will be in the message. The split is the control. The minute it costs is cheaper than the reply I had to walk back.