How to Build a Real Estate AI Email Agent

A realtor email agent is easy to demo because email looks like text in and text out. Production is different. The system must preserve thread identity, know which person and property the message concerns, resist instructions embedded in an email or attachment, avoid duplicate replies, respect consent, use the correct mailbox, and prove exactly why a message was sent.

• Start with one mailbox, one CRM, one lead type, and human approval on every send.
• Treat every inbound email, signature, link, and attachment as untrusted data—not instructions.
• Use Gmail or Microsoft event subscriptions instead of repeatedly polling the inbox.
• Keep lead stage, assigned agent, consent, and next action authoritative in the CRM.
• Never allow the model to send offer terms, legal advice, financing claims, or fair-housing-sensitive guidance autonomously.
• Separate individual correspondence from newsletters, cold outreach, and bulk marketing infrastructure.

“AI email agent” can mean a private writing assistant or a system that independently communicates with buyers and sellers. Autonomy—not prose quality—is the major cost and risk multiplier.

Level 2 is the practical sweet spot. It can use far richer context than a generic writing assistant while preserving a visible, accountable human decision before the message leaves the organization.

The model should not sit directly between the public internet and the Send button. A deterministic service receives mailbox events, applies identity and policy, builds a minimal context package, asks the model for a structured recommendation, then routes the result through approval and an audited send service.

Gmail can send a message directly with messages.send or send a prepared draft with drafts.send. Messages are RFC/MIME objects encoded for the API. See Google’s Gmail sending guide .

For inbox events, use Gmail watch with Google Cloud Pub/Sub. A notification gives the mailbox and history ID; the application then calls history APIs to retrieve changes. Watches must be renewed at least every seven days, Google recommends daily renewal, and applications should retain a periodic sync fallback because notifications can be delayed or dropped. See Gmail push notifications .

A draft-only pilot can often avoid broad mailbox modification. Ask for the smallest scope that supports the chosen job, keep refresh tokens in a managed secret store, separate test and production OAuth clients, and revoke access cleanly when a realtor leaves.

Microsoft Graph sendMail accepts JSON or MIME content and can save the message in Sent Items. A 202 Accepted response means the request was accepted for processing—not that delivery is complete. Review the Graph sendMail reference .

Use Outlook change notifications for new or changed messages instead of continuous polling. Subscriptions can target a mailbox or folder and can either include encrypted resource data or trigger a follow-up Graph read. Build lifecycle notification recovery and subscription renewal into the service. See Microsoft’s Outlook change-notification overview .

Permissions are intentionally separate: Mail.ReadWrite does not send mail, while Mail.Send does. Application permissions can operate without a signed-in user and generally require administrator consent; application access policies can restrict which mailboxes are reachable. See the Microsoft Graph permissions reference .

Graph throttling returns 429 and a Retry-After value. Honour it, back off, and favour change notifications over repeated reads. The official throttling guidance is part of the production design, not an exception handler added later.

The mailbox knows what was said. The CRM should know who the person is, who owns the relationship, the lead stage, consent, property context, and next action. Do not let the AI infer those fields from the latest email when an authoritative record exists.

These five stacks are anchors, not the whole market; the 84-system real estate AI integration directory maps the full CRM, MLS, IDX, email, voice, and transaction landscape.

The minimum write-back should include provider message ID, thread ID, CRM contact ID, intent, outcome, next action, owner, approval identity, and the exact context version used to produce the draft.

Every workflow below shares the same payoff: the agent assembles context and drafts the routine message, while a visible, accountable human decision still stands between the draft and the client.

An inbound message can contain text such as “ignore your previous instructions,” a malicious attachment, a poisoned link, a fake forwarded thread, or a signature that looks like policy. The agent must treat all of it as evidence to analyze, never as authority to change its tools, permissions, recipients, payment instructions, or operating rules.

• Keep system instructions, policy, credentials, and tool definitions outside message content.
• Strip active content, remote images, scripts, tracking, and macros before model processing.
• Never let an email supply a new API endpoint, recipient, bank detail, credential, or approval rule.
• Require deterministic recipient and thread validation before every send.
• Use separate tools for read, draft, send, CRM write, calendar write, and document access.
• Log the model input sources, proposed tool call, policy decision, approver, and final payload.
• Run simulated prompt-injection and data-exfiltration emails in every release evaluation.
• Pause the workflow when sender identity, CRM match, property, or conversation ownership is ambiguous.

The MCP security guidance is a useful starting point for authorization and confused-deputy risks when a harness connects to mailbox and CRM tools.

A mailbox API gives a programmatic Send button. It does not create consent, reputation, list hygiene, or immunity from provider limits. Google Workspace documents rolling sending limits that can include 2,000 messages per day for a paid user, lower limits for trials and mail merge, and recipient caps. Limits can change and accounts may be restricted for spam. See Google Workspace sending limits .

Use one-to-one mailbox automation for genuine human correspondence and service workflows. Use a consent-aware marketing platform for newsletters and campaigns. Configure SPF, DKIM, and DMARC; use stable identities; maintain bounces and suppressions; provide required unsubscribe controls; and measure complaints rather than celebrating send volume.

Email-agent legality depends on jurisdiction, relationship, purpose, content, consent, sender identity, and retention. Canada’s CASL framework and United States federal and state requirements can apply differently to commercial outreach, transactional messages, existing relationships, and third-party lists. Obtain current advice for your markets.

At minimum, maintain consent provenance, sender identity, unsubscribe and suppression state, purpose, CRM ownership, data source, approval, final content, delivery metadata, and retention. Do not use protected classes or proxies to decide who receives service, information, properties, priority, or follow-up.

For Canadian starting points, review the CRTC’s anti-spam resources . For Google and Microsoft, also apply the organization’s privacy, eDiscovery, retention, administrator, and acceptable-use policies.

The mailbox API usually is not the expensive line. Engineering, human review, context quality, security, CRM cleanup, retention, and exception handling dominate. These ranges assume existing Google Workspace or Microsoft 365 seats and one reasonably documented CRM.

Model cost per draft can be fractions of a cent to a few cents. If a realtor spends two minutes reviewing each of 1,000 drafts, however, that is more than 33 hours of labour. The economic question is not “how cheap is the token?” It is “how much trustworthy work disappeared?”

1. Days 1–5

   Choose the narrow job

   One mailbox, lead source, CRM owner, reply class, property source, and human approver.

2. Days 6–10

   Build identity and eventing

   OAuth, mailbox events, durable queue, CRM match, thread dedupe, replay, and audit IDs.

3. Days 11–15

   Create policy and evaluation

   Test prompt injection, wrong recipient, ambiguous lead, attachments, stale property facts, legal language, and duplicate sends.

4. Days 16–20

   Run draft-only

   Compare edits, rejection reasons, CRM match accuracy, hallucinations, response time, and reviewer effort.

5. Days 21–25

   Enable supervised send

   Let approved users send from the queue; monitor throttling, duplicates, thread integrity, and CRM write-back.

6. Days 26–30

   Automate one bounded reply

   Only a low-risk, deterministic class such as appointment confirmation—with instant pause and human takeover.

Before connecting the inbox, read what an AI harness is and how realtors should use one. The mailbox connector is one tool; the harness is the operating system around it.

Build when you have a unique workflow, clean CRM data, developers who understand OAuth and event delivery, a security owner, sufficient volume, and a real reason to control mailbox infrastructure.

Buy when the objective is faster follow-up, fewer missed opportunities, consistent client communication, and more appointments. A managed product should absorb the connectors, model routing, permissions, review queue, policy, monitoring, and continual provider changes.