Protege

Appearance

Gateway ​

The Gateway is the protocol edge — the boundary between email and the engine. Everything about mail lives here, and nothing else does: routing an inbound message to the right agent, guarding against loops and unwanted senders, and turning a reply back into correctly-threaded outbound mail. The inference core never learns what a mailbox is, and the Gateway never learns what a model is.

Inbound ​

Every received email passes through a fixed sequence of gates before it can reach inference. Each gate is a hard stop: the message is dropped, bounced, or accepted, and only an accepted message becomes a run.

Inbound email (customer → support@thescoop.com)
   │
   ▼
 recursion budget exhausted?  ── yes ─► silently drop
 no agent owns the address?   ── yes ─► bounce (unrouted)
 sender not allowed in?       ── yes ─► bounce (access denied)
 attachments over the limit?  ── yes ─► bounce (attachment rejected)
   │
   └─ accepted ─► enqueue an inference run
  • Recursion guard. Outbound mail carries a hop budget; an inbound email whose budget is spent is dropped. This is what stops two agents from replying to each other forever.
  • Routing. The recipient address is matched to an agent, honouring plus-tag subaddressing — so support+order42@thescoop.com still routes to Sundae at support@thescoop.com. No match bounces as unrouted.
  • Access guardrail. The sender is checked against the agent's inbound access rules before the message reaches inference. This is how Scout stays reachable only from inside @thescoop.com. See Security for how the layers compose.
  • Attachment limits. Oversized or too-numerous attachments are rejected at the edge, before anything is stored.

The Gateway only claims mail for domains Protege actually receives for, so mounting the engine never hijacks the host app's other inbound mail.

Outbound ​

Agents never talk to a mail transport. An agent's plain assistant text is never delivered on its own; the only way a message leaves the building is the send_email tool, which hands the composed mail to the Gateway. That single exit point is where the outbound guarantees live:

  • Identity is enforced. Every send is re-stamped with the sending agent's own address — an agent cannot impersonate anyone else. Sundae's replies always come from support@thescoop.com.
  • Threading is preserved. A reply inherits the original subject and threading, so it lands back in the same conversation rather than starting a new one.
  • Transport is chosen automatically. Console conversations stay in-app; real mail goes out over SMTP. The inference core doesn't know or care which.
  • History is recorded. The outbound message is persisted on its thread, with attachments stored by reference so a file is uploaded once and thereafter only pointed at.

Threading ​

A conversation is a thread, identified by the mail's own message-id and reference chain. An inbound message and the reply it triggers resolve to the same thread, which is what gives an agent conversational memory for free — the next turn can replay everything said so far (see Resolvers and the Harness).