What Should a Reply Stop? A Decision Table for Outbound From Several Sellers

A stop rule belongs to a person, not to one sequence. Below is a table of eight events (a reply, an out-of-office, an unsubscribe, hard and soft bounces, a colleague replying, a connected call, a do-not-contact entry) with who stops, for how long, who restarts and which cells are standards versus our rules.

With one seller, stopping the person and stopping the sequence are the same thing. The person replies, the sequence stops, and nobody else was going to write anyway. But with several sellers writing to one account, they split apart. The sequence that got the answer is one of several running at the same company, and every other seller's copy assumes nobody just heard back. And if the stop doesn't reach every seller, the next email lands on someone who already answered. Our multithreading checklist covers who should write to whom.

Why several sellers change the question

A reply to an email should also stop the LinkedIn note a second seller queued and the call task a third seller has on their list. The question is who else is about to write to this person, and on which channel. In Trellis, a stop is built to cancel every further step for that person.

Then there's a second question, who restarts. It's easy to skip. But a stop with no restart owner either never ends or gets undone by whoever notices first. Name the role that restarts, and keep a person in that role. The case for that sits in human review of AI agents.

The decision table

"Sourced" in the last column means a standard, a statute or a mailbox provider's published rule backs the cell. "Our rule" means we chose it, and you can choose differently. And durations stay out of every cell, because your team sets those.

Rows three, four and eight are what's usually called a suppression list: people and addresses you must not write to, kept apart from pauses. And row five feeds your bounce rate, which is a mailbox number and says nothing about the person.

Three rows that take a judgement call

The out-of-office is a bet. Automatic replies are supposed to carry an Auto-Submitted header, but RFC 3834 words that as "SHOULD be included," so some won't. When recognition fails you have two bad options: keep writing to someone who is away, or stop someone who isn't. I'd stop, because undoing a wrong stop takes one action from a person. Continuing by mistake puts a seller's name under a message nobody wanted.

A colleague's reply is the row only multi-seller teams meet. Someone else at the company answers for the person you wrote to, and the thread has a new owner. Both people stop. If the colleague is already on file, that's all. If they're unknown, the reply attaches to the thread, the person on it stops, and someone should add the colleague as a person. But an address that isn't on file at all gets nothing automatic. A person chooses between stopping and ignoring.

Hard and soft bounces split on a class rule you can cite. RFC 5321 treats a 5yz reply as permanent, and the sender should not repeat the exact request. And a 4yz reply is temporary. RFC 3463 draws the same line at 5.x.x and 4.x.x. But a permanent code isn't always about the person. A policy rejection (5.7.x) or a full mailbox says something about the message or the mailbox, and nothing about whether the person exists. Blocking the address for either costs you someone reachable. That exception is ours, not the RFCs'. Where to set the bounce-rate line is in our cold email deliverability FAQ.

Unsubscribe, hard bounce and do-not-contact all read "final," and the word needs a footnote. It means a seller can't undo the entry from their own screen, though an operator can remove it with a written reason, because addresses get mistyped. The statute's text requires a working opt-out and bars commercial email within the scope of the request once a statutory window has passed. Treating every seller as one sender is our rule, and the one I'd defend. But whether the statute reaches your outbound is a question for counsel.

What a stop cannot promise

A stop is two things: a record that this person is stopped, and a pause at the sending tool. Either one can fail. The record can be right while the pause never gets confirmed. And then the tool is still holding a schedule with the next step on it, ready to go.

Be wary of any promise that nobody gets another email after replying. That includes us. In Trellis, a pause the sending tool didn't confirm is recorded and shows in the logs. As of 27 October 2026, an automatic retry of it isn't switched on. But I also couldn't source any sending tool's default for stopping on a reply. Test yours with an address you own before you rely on it. It's a cheap check.

Whatever sending tool you use, ask what happens when the pause fails, who sees it and who fixes it.

How this looks in Trellis

In Trellis, replies from every channel land in one inbox, and opening a thread shows the account's history, newest first. One limit first. The type control works on replies Trellis read from the inbox itself. That reader, which also handles a colleague's reply, an unsubscribe sent by email and a bounce notice from the mail server, is built, with tests, but as of 27 October 2026 it isn't switched on in production. But replies from the sending tool show the type it gave them.

When a reply arrives without a type, a person picks one of eight: Interested, Meeting booked, Referral, Not interested, Not now, Neutral, Wrong person or Do not contact. The pick sets the type on that reply and logs no second one. But Do not contact stops everyone, and it can't be undone from the person screen. Mark out of office fixes a missed auto-reply. A pause from a person's drawer needs a reason, and the AI inside Trellis can't send, approve or dial.

And these rules are built and covered by tests at the deployed commit. I'm not claiming a verified end-to-end run on live traffic for each one. The full tour is in our Announcing Trellis article.