What an inbox agent should touch, and what it should not

"Handle the inbox" sounds like one task. A mailbox agent is really doing four things: reading a message, deciding what it means, producing a response, and acting on that response somewhere else in the system. Those four steps carry very different risk. A policy that grants or denies automation to "the inbox agent" as one unit treats steps with different risk profiles as if they were interchangeable.

Reading and classifying are internal. The agent looks at a thread, decides it is interested, not interested, an out-of-office or a bounce, and attaches a label. Nothing leaves the system. Nothing external is affected by getting it wrong. A wrong label is corrected on the next read. Sending is different. A sent message reaches a real person's inbox and cannot be recalled. Those two steps do not belong in the same automation bucket because the same agent touches both.

SalesCrew's Inbox agent is built around that split. It drafts a reply using the thread, any lead score, and knowledge-base sources as context. For classification it checks rules first, and uses an LLM only as a fallback when no rule matches. Drafting and classifying are things the agent does on its own inside the mailbox. Neither reaches a prospect directly.

Suppression is a special case worth naming. When a message is an unsubscribe request or a bounce, suppressing that contact from further outbound is an auto action in the default policy table, not a review one. That is deliberate. The risk of acting immediately on a stated unsubscribe is close to zero. The risk of waiting for a human, sending one more email to someone who asked to stop, is the exact failure the rule exists to prevent. Treating that action as urgent and safe, while treating an outbound send as neither, is the same judgment applied consistently. It is not a special exception.

Everything that leaves the building is different. An email reply, a message on another channel, an SMS, a proposal on a marketplace: all default to review under the same policy table. The agent produces the complete artefact. A person approves, edits or rejects it before it goes anywhere. That line is not about how good the draft is. A well-written, wrong-tone reply to the wrong lead is still a message a real person received on the company's behalf. Catching that after the fact costs far more than a five-second approval before it goes out.

The same logic extends past the message into what the agent might do about it. If a reply looks like a strong signal, the tempting next step is to change the deal's stage automatically, or merge what looks like a duplicate contact the reply revealed. Both are review actions in the default policy table. Both alter a record that reps, other agents and reports depend on being accurate. An inbox agent noticing a reason to change a stage is useful. An inbox agent changing it on its own removes the moment where a person could catch that the reply was sarcastic, from the wrong contact, or a mistake.

The general rule is to separate an agent's job into what it decides internally and what it changes externally, and set the automation level per category, not per agent. An agent fully trusted to classify and log is not automatically trusted to send. An agent trusted to send a reply is not automatically trusted to change a pipeline stage. Those are different kinds of mistakes with different costs to undo.

Reviewing every draft the Inbox agent produces is not slower in any way that matters. The agent already did the reading and the writing. The human step is an approve, an edit or a reject, not a rewrite from a blank page. That is the argument for keeping the send in review while classification and logging run on auto. The time savings live in the drafting. The risk lives in the sending. The automation boundary should sit exactly between those two steps.