Every limit here is permanent and by design. None of them is a bug, and knowing them early changes how you set the thing up.
If instead a particular email went unanswered, that is a diagnosis rather than a limit: why the AI didn’t reply.
It starts at connect. There is no history.
Connecting a mailbox starts a watch on new mail. Nothing from before the connection is imported, and nothing you do afterwards backfills it.
The practical consequence: connect the mailbox before the period you want covered. A mailbox connected on Friday knows nothing about Thursday, and the knowledge base is the only way to give it context that predates it.
It only counts replies that went out through it
The platform records outbound it sent. A reply a colleague types in Gmail or Outlook is a real answer to a real customer, and it is not credited here — so the thread can still read as waiting.
The two providers fail differently, and neither is safe to describe as the other. On Gmail the watch is armed on the inbox, so their reply never reaches us at all. On Outlook the sent-items subscription does deliver it, and the thread still is not marked answered.
So “no reply” here always means the last message I can see is theirs — never you owe this person a reply.
On Gmail, it sees the inbox and nothing else
The watch is armed on INBOX specifically. Mail that skips the inbox — filtered
straight to a label, or archived on arrival — is invisible. If you run
aggressive filters, the mail you most want handled may be the mail that never
arrives.
Instructions belong to the agent, not the mailbox
There is no per-channel instruction. What you tell an agent applies everywhere that agent answers. You can word an instruction to scope itself — “when answering email on support@…” — but that is a request to a model, not a setting something enforces.
Two mailboxes that genuinely need different behaviour need different agents.
An instruction cannot stop a draft being written
This is the one people try first, and it does not work the way it looks. Telling an agent “don’t reply to marketing email” changes how a reply is worded, not whether one exists. The only way a prompt produces no draft is the model emitting zero characters, and a model told to stay quiet typically writes a polite refusal instead — which becomes the draft.
What actually stops a reply is deterministic and lives in the code, before the
model runs: mail that self-identifies as automated is dropped, and mail from a
no-reply address is shown but never drafted. Those are filters, not
instructions, and they are not configurable per mailbox.
Drafts are not everywhere
On most mailboxes a pending reply is also written into the provider’s Drafts folder. On a Microsoft 365 Group it is not — Graph has no draft API for group conversations, so those live on the dashboard only.
There is also no per-draft confidence score. A draft is flagged by triage or it is not; nothing rates how sure the model was, and any interface suggesting otherwise would be inventing it.
An unset reply mode means autonomous
If the stored mode is ever missing or unrecognised, the fallback is autonomous — the AI sends. That is a deliberate choice about which failure is worse, and it means setting the default explicitly is better than assuming an empty field means “do nothing”.
Delivery is not ours
If a reply was sent from here and never arrived, that is SPF, DKIM, your domain’s reputation or the recipient’s spam filter. Those live with your mail provider and your DNS. This product does not manage, monitor or report on them, and nothing here will tell you a message was marked as spam.