build-vs-buy-cedar-for-engineers.md13.3 KBView on GitHub # Cedar: Why This Isn't a Build-In-House Problem
*A technical brief for the engineering reader — written for someone who could, in principle, build any one of these pieces.*
---
## The one-paragraph version
You can build a convincing demo of "AI that reads my email and drafts replies" in a weekend. That demo is not the product. The product is the four systems underneath it — an **email layer** that drafts well enough to actually send (>90%, not "looks plausible in a demo"), a **data system** that turns a year of messy history into structured, searchable, connected knowledge, an **agent harness** that can act on the outside world, and an **app** people will actually live in. Each is a multi-quarter effort with a long quality tail, and they only create value *together*. The honest question isn't "can your team build this?" — it's "is the 12–18 engineer-months to reach parity the best use of an AI team that already has a roadmap?" This doc lays out the surface area so you can answer that with eyes open.
---
## The shape of the trap
This category has a brutal demo-to-production gap, and it's worse for AI products than for ordinary software. The reason is structural: **the value is in the long tail, and the long tail is invisible at demo time.**
```
Effort to build Where the value actually is
───────────────── ───────────────────────────
Demo (1 inbox, happy path) ▓ ░ (looks impressive, ~5% of real value)
Production system ▓▓▓▓▓▓▓▓ ████████████ (the other 95%)
```
A demo is one clean inbox, a few cherry-picked examples, and a human in the loop nodding along. Production is thousands of mailboxes, every weird real-world situation, and the bar where a draft is good enough that someone hits *send* without editing. The distance between "the model produced something" and "the model produced the *right* thing, reliably, on the case you didn't anticipate" is where the quarters go. Everything below is the cost of crossing that gap.
---
## 1. The email layer — *drafting that's good enough to send*
The trap here is that the first draft is easy and the **90th-percentile draft is brutally hard.** A model with no context will write a fluent, generic, wrong email. Getting to a draft a salesperson sends without editing is an accuracy-and-context problem, and it has a long tail.
- **Getting the raw material.** Before you draft anything you need the full thread, the prior emails, the attachments, the meeting notes — assembled and cleaned. HTML email is a hostile 30-year-old format: sanitization, quote-block preservation, attachment text extraction, signature stripping. Just getting clean input is real work.
- **Indexing every situation.** A reply to a cold prospect, a follow-up after a demo, an objection, a pricing question, a scheduling back-and-forth, a renewal — each is a different *situation* that wants a different response shape. You have to recognize which situation you're in (classification across an open-ended taxonomy) before you can draft for it. Mishandle the classification and the draft is confidently wrong.
- **Combining with deal context.** The draft has to know *this is a stalled enterprise deal where the champion went quiet and pricing is the open objection.* That means fusing the email thread with CRM state, prior conversations, and enrichment — and putting the *right* slice in context without blowing the window or the budget.
- **Self-learning loops.** The system has to get better from how the user edits and which drafts they send. Capturing the user's authentic voice from their sent mail, learning their style guide, and feeding edits back into the next draft is what separates a tool people abandon from one that compounds. This is a feedback-and-eval problem, not a prompt.
- **The >90% bar.** A draft assistant that's right 70% of the time is *negative* value — the user has to read and fix every output, which is slower than writing it themselves. The product only works above ~90% send-without-major-edit, and **every point above 80% costs more than all the points below it.** That last stretch is the entire engineering challenge, and it's exactly the part a demo never shows.
- **UI/UX.** Where the draft appears, how edits are captured, how the user accepts/regenerates/steers — the interaction design *is* the product. A great model behind a bad surface gets uninstalled.
- **Steer it from Slack.** Talk to it, correct it, hand it extra context in the moment ("they just told me on the call budget is approved") and have that flow back into the draft and the deal record. The conversational control surface is its own integration and UX project.
> The demo version is "LLM + thread → draft." The production version is situation classification, deal-context fusion, voice modeling, an edit-feedback loop, and the relentless grind from 80% to 90%+. That grind is most of the work and none of the demo.
---
## 2. The data system — *turning history into knowledge*
This is the layer that makes everything else possible, and it's where naive implementations quietly produce wrong answers. The job: take a firehose of unstructured email and meetings and turn it into structured, searchable, *connected* knowledge.
- **A pipeline for sorting events.** Every email and meeting becomes an "event" that has to be summarized, scored for significance, classified by type, and routed. This is a streaming extraction pipeline with idempotency and ordering guarantees — get it wrong and the knowledge layer is built on sand.
- **RAG & embeddings for flexible search.** Embedding (1,536-dim) into a vector store with proper chunking (overlapping windows so long transcripts don't silently truncate at the token limit — a failure that *fails open*: no error, just degraded recall you won't catch in a demo). Then multi-turn retrieval with citations mapped back to the source event. "With citations" is the difference between answers people trust and answers they don't — and it's most of the engineering.
- **Structured taxonomy extraction.** Pulling typed fields out of free text — pain points, budget, decision-makers, next steps, custom fields — via structured generation with a confidence floor, so low-confidence guesses don't pollute the record. The taxonomy itself has to be extensible per customer.
- **A self-building knowledge graph.** People → companies → conversations → deals, assembled automatically from the mail stream and enrichment, with alias handling (merged companies, changed domains, people who switch jobs). This connective tissue is what lets the system reason about a *relationship* instead of a single email — and it has to maintain itself as the data grows.
- **The data structure underneath it all.** A schema that holds global people/company records with denormalized signals, per-org overrides, conversation state machines, and multi-tenant scoping on every row. Retrofitting tenancy and a graph onto a prototype's flat schema is one of the most expensive refactors in software — which is why it has to be right from the start.
> The demo version of this is `embeddings + cosine similarity`. The production version is the event pipeline, chunking strategy, confidence thresholds, citation tracking, the self-maintaining graph, and the eval harness to know any of it is correct. That gap is quarters, not weeks.
---
## 3. The agent harness — *acting on the outside world*
An assistant that can only read is half a product. The harness is what lets it *do* things — and reach out to the systems where the truth lives.
- **Webhooks (in and out).** A public ingress so external systems can trigger the agent (encrypted secrets, queueing, token rotation), and outbound calls so the agent can act on other systems. This is a security and reliability surface, not a convenience.
- **Enrichment.** Turning an email address into a person with a role, company, headcount, funding, and growth signals — across multiple providers (Apollo, Crustdata, Wiza, Exa) with fallback logic, caching, staleness TTLs, and cost control mapped to real vendor invoices. An AI that drafts without knowing *who* it's talking to is a toy; wiring up one provider is an afternoon, operating four with fallback is an ongoing job.
- **Search.** Giving the agent retrieval over the knowledge layer *and* the live web, with the orchestration to know when to use which, multi-turn, without runaway cost. Tool-use that's reliable on the 5,000th call, not just the first.
> The hard part isn't calling an LLM with tools. It's the *guardrails and governance* — making the agent reliably do the right thing across thousands of executions, with a permission model that holds up in a multi-tenant org, and the observability to replay exactly what it saw and did when something goes wrong.
---
## 4. The app — *something people will live in*
All of the above is worthless if nobody opens it. The app is a full email client plus a CRM plus a chat surface — and it has to be fast and pleasant enough to replace the tools people already use.
- A real inbox UI (threading, search, compose, labels, keyboard-driven) that has to feel as good as the client you're asking people to leave.
- The CRM views, deal pipelines, and conversation surfaces layered on top.
- The chat/assistant surface, woven in rather than bolted on.
- Cross-platform: web, desktop (Electron), and the Slack control surface — each its own build, release, and maintenance track.
> "We'll wrap it in a simple UI" is where a year disappears. Email clients are held to an extremely high bar because the alternative is one tab away.
---
## The standing tax (the line items nobody budgets for)
Underneath all four pillars is a maintenance load that never ends:
- **OAuth & connection lifecycle** for Google and Microsoft — token refresh, re-consent, scope changes, per-user quotas.
- **Provider API drift.** Gmail, Microsoft Graph, Apollo, Crustdata, Wiza, Exa, OpenAI, Anthropic, the vector store — every one ships breaking changes on its own schedule. Permanent maintenance, not a one-time cost.
- **Vendor billing & rate limits** across ~9 paid APIs, each needing its own caching, backoff, and cost control.
- **Observability & eval.** Full tracing of every LLM and tool call, per-execution replay, and an eval harness — because without it the system is unimprovable and undebuggable in production.
None of this is intellectually hard. All of it is *time*, and it never stops.
---
## The time-value math
Rough, defensible parity estimate for a strong team building this from zero:
| System | To "works in a demo" | To "production-trustworthy" |
|---|---|---|
| Email layer (to >90% send rate) | 1–2 weeks | **3–4 months** |
| Data system (pipeline + RAG + graph) | 2–3 weeks | **3–4 months** |
| Agent harness (webhooks + enrichment + search) | 2–3 weeks | **2–3 months** |
| App (client + CRM + cross-platform) | 3–4 weeks | **3–4 months** |
| Standing tax + multi-tenancy + eval | hidden | **2–3 months, then ongoing** |
That's roughly **12–18 engineer-months to reach parity** — and parity is the *starting* line, because Cedar keeps moving. Then it's a standing team to maintain integrations, chase API drift, run the eval harness, and push the accuracy curve.
The real cost isn't the build. It's the **opportunity cost**: every one of those engineer-months is a month *not* spent on the AI use cases that are actually differentiating for your business. Email drafting, enrichment, and RAG plumbing are undifferentiated heavy lifting — table stakes you have to get perfect and get zero credit for. Your AI team's time is worth more pointed at the problems only you can solve.
---
## Where building *does* make sense (so this is honest)
Build in-house when the thing is your differentiator, when off-the-shelf can't be customized to your workflow, or when data-control requirements rule out a vendor. **Cedar is the opposite case on all three:** the email/data/enrichment layers are not your differentiator, the playbook layer already provides deep per-org customization (and is the right place to encode your specific workflows), and the data model is multi-tenant with org-scoped governance from the ground up.
The strongest version of this argument: **buy the systems, build on top of them.** The webhook ingress and agent harness exist precisely so your engineers can extend Cedar with your proprietary logic — without first spending a year rebuilding the undifferentiated foundation underneath it.
---
## Bottom line
The question to put to the engineering reviewer isn't "is any of this beyond us?" — clearly it isn't. It's:
> **"Do we want to spend 12–18 engineer-months reaching parity on undifferentiated email and data infrastructure — and then staff a permanent team to maintain it and grind the accuracy curve — when that same time could ship the AI use cases that are actually ours to win?"**
A weekend prototype proves the idea is reachable. It says nothing about the >90% send rate, the self-maintaining knowledge graph, the citation tracking, the multi-tenant governance, the eval harness, and the nine vendor relationships that stand between a prototype and something you'd put in front of a customer. That gap *is* the product. It's already built, already operated, and already improving — so your team doesn't have to.