What It Really Costs to Build an Internal Email AI Agent

The question underneath "cost to build an internal AI email agent" is usually not really about the build. It is about whether the build finishes, whether it stays running, and what happens the third time Google emails you about restricted-scope reassessment.

Most in-house proposals price the engineering time. A few also price LLM inference. Almost none price OAuth verification and annual CASA reassessment, IMAP edge cases, prompt-injection defence, the eval harness, on-call, and the framework churn that eats the maintenance budget in year two. This guide lists the line items the proposal usually omits, in the shape you can fill in with your own rates rather than trust an invented industry average.

The short answer#

A serious internal build is a two-to-three engineer team for six to nine months to reach first production, and roughly one full-time equivalent to keep it running afterwards. That is before LLM inference, cloud storage, OAuth verification, and the on-call rota that inbox software requires because a stuck sync loop wakes people up.

Priced against most SaaS options, buying pays back inside twelve to eighteen months at team sizes below fifty. The proposals that break that rule usually have a compliance constraint that removes the buy option from the table, or an existing platform team already carrying the shared costs.

The rest of this post is the structure to price a build against your own rates. It ends in a build-or-buy recommendation with the reader we would send to a competitor named explicitly.

The line items an internal proposal usually omits#

Engineers can estimate the parts they build. What they miss are the parts that are somebody else's job at a vendor — the security review someone signs, the auth boundary someone runs, the on-call rota someone else already staffs. Those are not free because you built the client; they are just paid by a different budget line.

• OAuth verification and annual reassessment. Gmail's restricted scopes such as gmail.modify and gmail.readonly trigger a CASA (Cloud Application Security Assessment) at Assurance Level 1 for most third-party clients, plus Google's own security review. That is a paid third-party assessment on top of your engineering time to remediate findings, and the reassessment is annual, not one-time.
• Microsoft Graph permissions review. Mail.Read, Mail.ReadWrite and Mail.Send are admin-consent scopes. Multi-tenant apps go through Microsoft Publisher Verification and, for many customer tenants, an admin approval workflow before the app can be granted access at all.
• IMAP edge cases. Threading, UIDVALIDITY changes, folder namespaces, Gmail-vs-generic label semantics, message deduplication across accounts, byte-vs-line stuffing in raw messages. Each is a bug report waiting to happen the moment you support anything beyond Google and Microsoft.
• Prompt-injection defence. OWASP's Top 10 for Large Language Model Applications names LLM01 (prompt injection) and LLM06 (excessive agency) as separate risks. Both apply the moment your agent reads a message and can take an action — the message is untrusted input, and the tool set it can call is the blast radius. This is not a library you install; it is an ongoing threat model.
• Eval harness. Draft quality drifts every time you change model, prompt, or context window. Without a labelled eval set your team owns, drift is discovered by users, which is the expensive way to find it.
• On-call. Sync loops stall. IMAP IDLE connections drop. Webhook signatures rotate. Model providers rate-limit at the worst possible moment. Somebody carries the pager.
• Framework churn. In an eighteen-month window it is normal to swap model provider, LLM SDK, agent framework, and vector store at least once each. Every swap is a compatibility pass across prompts and evaluations before anything ships.

The line items to price#

Below is the shape of the cost estimate. Fill in your own loaded-cost hourly rate and your team's realistic pace — the ranges are wide because a payments-team engineer moves at a different speed to a two-year graduate.

How to estimate this for your team#

Do the estimate in this order. Skipping a step feels efficient and produces the number that misses the CASA line.

1. 1

   List the providers you actually need

   Gmail alone is a smaller project than Gmail plus Microsoft 365 plus IMAP. Each provider is its own auth flow, sync semantics, and long-tail bug surface. Estimate line one of the table per provider, not once for the category.

2. 2

   Price the first six months as a phase, not a sprint

   Multiply engineer-weeks by loaded hourly rate. Loaded rate is total annual compensation divided by 2,000 working hours — benefits, payroll taxes and overhead included. Do not use base salary; a proposal that under-costs the people by 40% will be caught in finance review.

3. 3

   Add the LLM inference model

   Estimate messages processed per active user per day, tokens per message including context, and cost per token at your chosen provider's current rate. Multiply by users, days, and a headroom factor of 1.5 for the first year while prompts and context windows are still moving. Note the number is per-user-per-month operational spend, not a one-time cost.

4. 4

   Add the compliance and platform costs

   CASA assessment and remediation, Microsoft Publisher Verification effort, DPA reviews with your model providers, sub-processor listing on your own trust page, object storage and encrypted-at-rest backups, secrets management, and SSO if your team uses one. Each is a small line; together they are typically 15-25% of the build.

5. 5

   Add year-two ongoing cost as a full column

   Ongoing engineering (usually 0.5-1 FTE), on-call rotation cost, LLM inference at projected usage, annual CASA reassessment, and one budgeted framework or model migration. This column is what tips the total-cost-of-ownership calculation against building — the build number looks like a one-off, and it never is.

6. 6

   Compare against buying at the same seat count and time horizon

   A three-year total-cost-of-ownership comparison is fair. A one-year build cost against three years of subscription is not. Include the buy option's setup effort as well — SSO, DLP integration, admin rollout — because it is real, just usually smaller by an order of magnitude than a from-scratch build.

A worked example#

The numbers below are structural — they show how the line items compose into a total, not what your build will cost. Substitute your own loaded rates.

Team: two backend engineers and one designer / frontend, all at a loaded rate of $150 per hour. First-production phase: 30 weeks, roughly 0.75 FTE of the designer weighted across the phase. Engineering build cost: two engineers × 30 weeks × 40 hours × $150 ≈ $360,000, plus the designer at ~$135,000, plus a fractional security engineer for the injection-defence and CASA work at ~$40,000. First-production build: roughly $500,000-$550,000 in loaded people time.

Then twelve months of ongoing: 1 FTE engineering at ~$300,000 loaded, LLM inference at (illustrative) $8-$20 per active user per month, on-call at ~$25,000, annual CASA reassessment at low-to-mid four figures for the assessment plus a week of remediation. For fifty active users that is a year-one all-in of roughly $850,000-$950,000 and a steady-state year-two of $400,000-$500,000, before feature work.

None of those figures are quotes; every one is a placeholder you would replace with real rates from your org and a real pricing sheet from your model provider. But the structure is the point — the build number is the smaller of the two, and it is the one every proposal shows.

Red flags a build proposal will not finish#

These patterns appear in the retrospectives of internal AI projects that were sunset before year two. If more than one is true of your proposal, the risk is not the total cost — it is that the total cost gets spent and there is nothing running at the end.

• "We will just wrap GPT-4 / Claude / whatever." The wrapper is the smallest line in the table above. If the proposal reads like the model is the product, sync, threading, injection defence, and the audit log are unpriced.
• No prompt-injection story. If the design document does not name LLM01 and LLM06 from OWASP's LLM Top 10 and describe how the action set is bounded, incoming mail will eventually instruct the agent to do something it should not.
• No eval harness in the plan. Drift is inevitable; a build without a labelled eval set finds out about it from user complaints, which is expensive twice — once in re-work and once in trust.
• The proposal treats OAuth verification as a one-time task. CASA reassessment is annual. Skipping it in year two means Google can revoke restricted-scope access, and the agent is now blind.
• One person understands the sync loop. Inbox software runs 24×7 and its worst incidents happen at four in the morning. A single owner is not a team; it is a resignation risk with a paycheck.
• The team lead has not shipped email software before. Email is a category with a long list of foot-guns — UIDVALIDITY, threading, alias handling, HTML sanitisation, deliverability — that people who have shipped it once never underestimate again.

What we would pick, and why (honest)#

We build AI Emaily, so this section is written knowing we are one of the products in the buy column. It is also written to send some readers to the build column and some to a competitor, because the wrong recommendation loses trust on every other page in the cluster.

Build if any of these apply: your compliance regime requires LLM inference and the message store to run inside your own VPC and no third-party can cross the boundary; you already run a platform team that carries most of the shared costs anyway, so the marginal spend is a fraction of the table above; or your workflow is so specific to your business that no existing client addresses it and the productivity delta is worth the sustained investment. In those cases a build is a legitimate answer, and the honest cost is the full table across three years — not the first-production line.

Buy if none of those apply. Under about fifty seats, and often up to two hundred, the total-cost-of-ownership math favours a subscription with a margin that pays for the vendor's CASA, on-call, and framework churn. The payback window on buying an existing product is usually inside eighteen months against a from-scratch build; the payback on building is measured against the alternative of buying, and it is usually longer than the tenure of the person who approved it.

One dimension we concede outright: if your requirement is a Gmail-only power-user workflow where keyboard-driven archive search is the deciding factor, Shortwave has built harder on Gmail-native search than we have, and neither a from-scratch build nor we are the shortest path to that specific outcome in year one.

Where AI Emaily fits is the case where the choice is not "Gmail-only power user" but "Gmail plus Outlook plus IMAP with a chief-of-staff agent that a person approves before sending." Copilot is the default and nothing leaves the mailbox without a click; Autopilot is opt-in, bounded by senders, topics and confidence thresholds you set, with a send delay and an undo. Provider coverage spans Gmail, Outlook and Microsoft 365, iCloud, Fastmail, Proton and standard IMAP in one view — no migration, no address change. Voice comes from a Personal Context brain and per-client profiles you set, not from indexing your past mail. Packaging is per seat with a 7-day free trial on Pro (card required, cancel by day 7 for $0) — the current numbers live at /pricing, and the product itself at aiemaily.com. We build AI Emaily, so read that as advocacy with the numbers checkable.

For anyone still on the build side after that: the last section of this guide, and the risk-register post linked below, are the two documents to bring to the go-or-no-go meeting.