Going to production

Sundae and Scout work on your laptop. Shipping them means two things the conductor and localhost were letting you skip: real mail and real security. This chapter is the pre-launch checklist.

Choose a mail transport

In development you used the Action Mailbox conductor and the in-app console — no mail server. In production, inbound mail arrives through an Action Mailbox ingress and replies go out over Action Mailer SMTP. There are two paths:

• An email provider (recommended, config-only) — point the ingress at the provider's inbound webhook and SMTP at its servers. No infrastructure to run, and the provider handles SPF/DKIM signing.
• Self-hosting an MTA — run the Postfix + OpenDKIM image Protege scaffolds with rails g protege:postfix. More control, but you own deliverability (rDNS, port 25, reputation).

Either way, publish the DNS records for thescoop.com shown on its Domains page. The full walkthrough for both paths — config, DNS table, and verification — is in Mail transport.

The security checklist

Protege enforces a lot for you — routing, the recursion guard, reply identity, bounded loops — but a few things are yours to own before you expose an agent to the world. (The full model is in Security.)

• Wrap the mount in authentication. This is the big one. The engine ships no auth, so an unwrapped mount Protege::Engine => "/protege" exposes every persona, thread, and trace to anyone who finds the URL. Wrap it in your app's auth:

  # config/routes.rb
  authenticate :user, ->(u) { u.admin? } do
    mount Protege::Engine => "/protege"
  end

• Set the inbound access ceiling. Decide the org-wide boundary with config.inbound_access, and confirm the per-persona rules from chapter 5 are in place — Scout locked to *@thescoop.com, Sundae open to customers.

• Review each tool's blast radius. A tool is your app's full power in the agent's hands. Re-read your tools with an adversarial eye: does ProcessRefund refund any order, or only one that warrants it? Treat customer email as untrusted input and enforce authorization in the tool, not in the prompt.

• Confirm attachment limits (config.attachment_policy) fit what you actually want to accept.

You shipped The Scoop

That's the whole arc. Starting from rails new, you:

• mounted the engine and registered thescoop.com;
• hired Sundae (a CustomerServicePersona record) and gave her tools to look up orders, issue refunds, check stock, and handle photos;
• gave her the right context and memory with resolvers;
• hired Scout (an OperationsPersona record), scoped her tools and senders, and put her on a schedule;
• learned to watch both agents through the introspection panel and tracing.

Where to go from here:

• Extensions — the authoring reference for tools, providers, resolvers, and hooks.
• Reference — every config option, model, and generator.
• Architecture — how the gateway, harness, and scheduler fit together under the hood.