Lesson 5 of 5 · 46 min

Capstone: account-research → personalized-outreach demo

Assemble the whole track into one flagship demo: an agent that researches an account, grounds findings in real sources, and drafts personalized outreach a human approves before send — built synthetic-first, scrubbed, tenant-isolated, gated by a smoke test. The full architecture, the numbers and tradeoffs to defend, and a rehearsal of the build-and-present interview that decides the offer.

Capstone

Account-research → personalized-outreach demo

Time to build the flagship: a demo where you name a target account and the system researches it (firmographics, recent news, the docs the customer cares about), grounds every finding in a real source, and drafts a personalized outreach email that a human approves before it sends. It exercises all four track skills at once — rapid prototyping, grounded RAG, an agentic workflow, and secure handling of customer/PII data — and it’s the single most common shape of the SE build-and-present round. Everything below is a callback to a specific lesson, assembled into one architecture you can present and defend.

Treat this as the interview itself. The build-and-present round is the gate in every SE loop, and the difference between a mid and a senior signal is structure: open with a problem-summary slide and a fictional-but-specific customer, demo two or three flows that each map to a stated pain, leave ~30% of the time for Q&A, and stay in character as if presenting to a real prospect. The strongest first move costs nothing — scope before you build: clarify what “account research” means here (which sources, which CRM, what counts as a good email) before drawing anything, the same way a senior RAG candidate asks scoping questions before sketching a pipeline. Interview angle. The panel grades Substance, Structure, Relevance, and Delivery; this lesson is a rehearsal of all four.

How to demo like a Salesforce Solution EngineerBadassBA (with Jasmine Ashley)

Scope it before you draw it

The questions that set the whole architecture — ask them out loud at the top of the demo, because the same words hide very different systems and the buyer is testing whether you know that.

01Sources? — which signals count as “research”: CRM facts, a docs corpus, public web/news? (sets retrieval + which tools the agent gets).
02Truth bar? — does every claim in the email need a citation, or is some inference OK? (sets the grounding contract + faithfulness gate).
03Data? — synthetic, scrubbed-real, or raw-real accounts in the demo? (sets the data track + the scrubbing/isolation you need).
04Action? — draft only, or enqueue to a sequence tool and write back to the CRM? (sets the human-in-the-loop gate, the idempotent write, and the blast radius).
05Tenancy/stakes? — one org or multi-tenant; is a wrong/spammy email embarrassing or a compliance problem? (sets isolation + approval rigor).

The reference architecture

End to end, on the buyer’s real GTM stack: 1) ingest the account’s sources (a CRM Account/Company read + a docs corpus + optional web), parsing layout-aware and scrubbing PII on the way in → 2) chunk + embed + index, tagged with a tenant_id and an acl so retrieval is isolated → 3) a research agent runs the Thought-Action-Observation loop, calling a search_account() tool (filtered by ACL at query time) and an enrichment waterfall (provider A→B→C, cheapest-first, cost-per-match) to gather grounded, cited findings → 4) a composer step drafts the email from those cited findings with an enforced “only claim what’s sourced” contract → 5) a human-in-the-loop gate shows the draft + its citations for approval before any send, scrubbing the output too; on approval it enqueues the email to a real sequence tool (Clay Sequencer / HubSpot Sequences / Salesloft) and makes one idempotent CRM write-back (upsert the Contact + log the touch on the Opportunity) → 6) a 20-question smoke test gates the whole thing before the meeting. Three swim-lanes to narrate: the offline ingest path sets quality, the online agent path sets latency, and the gate (approval + smoke test) makes it safe to show.

code

1Account-research -> personalized-outreach: the whole pipeline (lesson per stage)23  INGEST (offline)4    read CRM Account/Company + docs + web, layout-aware ... L25    SCRUB PII on the way in (Presidio) .................... L46    chunk + embed + index, tag {tenant_id, acl} .......... L2 + L4 (isolation)7  RESEARCH (online, per account)8    agent loop: Thought -> search_account() -> Observe .... L39    enrichment WATERFALL (provider A->B->C, cost/match) ... L3 (Clay pattern)10    retrieve ACL-FILTERED at query time .................. L2 + L4 (filter then retrieve)11    findings grounded + CITED (or "not found") ........... L2 (refusal path)12  COMPOSE13    draft email from CITED findings only ................. L2 (grounding contract)14    treat web/docs content as UNTRUSTED (injection) ...... L4 (LLM01)15  GATE (before send AND before the meeting)16    human-in-the-loop approval + scrub OUTPUT ............ L3 + L417    on approval: enqueue to sequence tool (Clay/HubSpot) . L3 (real outbound)18    one IDEMPOTENT CRM write-back (upsert Contact) ....... L3 (no duplicates)19    20-question smoke test (faithful/partial/halluc.) .... L12021  Offline sets quality; online sets latency; the gate makes it safe to demo.

python

1# The online path: a grounded research agent that DRAFTS (never sends) outreach,2# then a gated path that hits the REAL GTM stack only after a human approves.3def research_and_draft(account, user, providers):4    # 3) agent gathers grounded, cited findings: ACL-filtered retrieval (L2+L4)5    #    plus an enrichment waterfall for missing contact facts (L3, Clay pattern).6    findings = research_agent.run(account, tools=[7        acl_filtered_search(user.allowed_acls),            # filter then retrieve8        enrich_waterfall_tool(providers)])                 # provider A->B->C, cost/match9    cited = [f for f in findings if f.source_id]           # drop ungrounded claims1011    # 4) compose from CITED findings only; treat retrieved/web text as untrusted (L4)12    draft = compose_email(account, cited, contract=ONLY_CLAIM_WHAT_IS_SOURCED)13    draft = scrub(draft)                                   # output PII pass (L4)1415    # 5) human-in-the-loop: propose, don't send. Approval gate is the feature (L3).16    return {"draft": draft, "citations": [f.source_id for f in cited],17            "contact": account["primary_contact"], "status": "awaiting_approval"}1819def on_approval(approved, crm, sequencer):20    # Runs ONLY after a human clicks approve -- the real outbound + CRM write.21    sequencer.enqueue(approved["contact"]["email"],        # Clay/HubSpot/Salesloft seq22                      approved["draft"])23    # ONE idempotent write-back: upsert keyed on email, log the touch -> no dupes.24    crm.contacts.batch_upsert(id_property="email", inputs=[{25        "id": approved["contact"]["email"],26        "properties": {**approved["contact"], "last_outreach": "sent"}}])

The numbers and tradeoffs to defend

Interviewers reward a candidate who backs the architecture with arithmetic and explicit tradeoffs. Be ready to say out loud: the cost per researched account ≈ retrieval (cheap) + the agent’s tokens (the loop may make several model calls — output tokens dominate at ~3–5× input, so cap steps and keep drafts short); the latency ≈ a few tool-calling round-trips, which is why you stream the draft and show progress rather than blocking; the build cost is synthetic-first so it’s near-zero until the sanctioned real-data step. Name the tradeoffs deliberately: agent vs. single RAG call (the agent buys multi-source research but adds latency, cost, and failure surface — justify it), draft-only vs. auto-send (auto-send removes the human but is the action a security review will reject — keep the gate), and synthetic vs. real accounts (synthetic for the build, scrubbed-real for the credibility moment).

code

1Sizing the outreach demo (numbers to reason in, not memorize)23  per-account cost   retrieval (cheap) + agent loop tokens   cap steps; short drafts4  latency            a few tool round-trips                  stream draft; show progress5  output vs input    output ~3-5x input price                keep emails tight6  build cost         synthetic-first                         ~0 until sanctioned real data7  blast radius       draft-only + human approval             never auto-send in a demo89  The point is to REASON in these and connect each to a tradeoff you chose.

The composer prompt: where the personalization lives

The composer step is where the demo earns its “personalized,” and it’s also where it’s most tempting to let the model freelance. The contract that keeps it grounded: pass the agent’s cited findings (each with a source id), instruct the model to write only from those findings, require that every specific claim trace to a source, and forbid inventing facts the sources don’t support. The output you render shows the email and the findings it drew on — so a buyer can see the email isn’t generic mail-merge, it’s assembled from real, attributable signals about their account. This is the same grounding-and-cite contract from Lesson 2, applied to generation instead of Q&A: the model is conditioning on chosen evidence, not improvising flattery.

python

1# The composer contract: personalize ONLY from cited findings; no invention.2ONLY_CLAIM_WHAT_IS_SOURCED = (3    "Write a short, specific outreach email to {account}. Use ONLY the findings "4    "below; every specific claim must come from a finding and keep its [id]. "5    "Do NOT invent facts, metrics, or events not present in the findings. "6    "If the findings are thin, write a shorter, more general email rather than "7    "fabricating detail."8)910def compose_email(account, cited_findings, contract):11    body = "\n".join(f'[{f.source_id}] {f.text}' for f in cited_findings)12    prompt = contract.format(account=account) + "\n\nFindings:\n" + body13    draft = llm(prompt)14    # post-check: every [id] the draft cites must be a real finding (L2 rule)15    if not citations_valid(draft, cited_findings):16        return regenerate_or_flag(account, cited_findings)17    return draft

What breaks on stage — pre-empt it

A senior presenter names the failure modes before the panel asks. The five that recur in this demo: (1) ungrounded flattery — the email invents a flattering “fact” about the account (defense: drop claims with no source_id, cite per claim, enforce refusal); (2) PII leak — a real contact’s data appears in a draft or a log (defense: scrub input and output, redact logs — L4); (3) cross-account bleed — research for Account A surfaces Account B’s data (defense: tenant_id + ACL filter at retrieval — L4); (4) prompt injection — a poisoned web page or doc tells the agent to exfiltrate or spam (defense: treat retrieved/web content as untrusted, validate, human gate — L4); and (5) the runaway agent — the loop retries or calls send twice (defense: max-steps cap, idempotent send, approval gate — L3). Naming these unprompted is the strongest signal you run this in production, not just in a notebook.

Present it: the demo that wins the room

The build is half the grade; the presentation is the other half, and the rubric is consistent across companies — Substance (value tied to each beat, not a feature tour), Structure (a tight opener, Tell-Show-Tell loops, planned Q&A pauses), Relevance (every feature mapped to a stated pain), and Delivery (poise, honesty about limits, clean screen). Run the loop once per flow: Tell the problem (“reps spend an hour researching each account”), Show the demo (name an account, watch it produce a cited draft), Tell the payoff (“an hour becomes 20 seconds, every claim sourced, a human approves before send”). Time-box ruthlessly, rehearse to a stopwatch 5+ times, and keep the screen clean — the documented “bomb” was a messy screen with unready tabs and half-baked answers, not a bad product.

Then expect the derail: the panel will take you off-road with objections, because objection handling is graded twice — once behaviorally, once live. The three you must have ready: “we already use [competitor]” (name the underlying concern, acknowledge what they do well, redirect to the grounded-and-approved differentiator), “this will just spam our prospects” (that’s exactly why every claim is cited and a human approves before send — turn the objection into the feature), and “how does this handle our security/PII?” (the both-sides-scrub, tenant-isolation, injection story from L4). And rehearse the honest non-answer verbatim for anything you don’t know: “That’s a great, specific question — I’ll get you a precise answer from our product team by end of day.” Guessing and being wrong is the fastest way to lose a technical panel.

A winning capstone isn’t the demo that drafts one great email — it’s the one that’s grounded, scrubbed, tenant-isolated, smoke-tested, and gated behind a human, presented by someone who maps every beat to a buyer pain and stays honest under the derail. That’s the technical win.

Interview prep

The capstone is the interview — the full solutions-engineer loop compressed into one deliverable: build a customer demo, present it, survive the technical deep-dive, and handle objections, against a rubric. The structure that wins: scope → demo two or three pain-mapped flows → defend each decision with a number and a tradeoff → pre-empt the failure modes → handle the derail honestly. Answer each below leading with the buyer outcome.

01“Walk us through your demo.” → scope first (sources, truth bar, data, action, tenancy), then ingest(scrub) → agent-research(cited) → compose → human-gate → smoke-test.
02“How do you stop it writing things that aren’t true about the account?” → drop claims with no source_id, cite per claim, enforce refusal, faithfulness-gate on real accounts.
03“Why an agent and not a single call?” → multi-source research (CRM + docs + web) needs the loop; I cap steps and accept the latency/cost for that, draft-only.
04“Won’t this spam our prospects?” → every claim is cited and a human approves before send — the gate is the feature, not a limitation.
05“How does this plug into our CRM and sequencer?” → enrich via a waterfall (cheapest-first, cost-per-match), enqueue the approved email to the real sequence tool (Clay/HubSpot/Salesloft), and make one idempotent upsert (key on email) to the Contact + log the touch on the Opportunity — no duplicate records.
06“How do you handle our customer data and PII?” → synthetic-first build; scrub input and output; tenant_id + ACL filter at retrieval; treat web/docs as untrusted.
07“How do you know it’s ready to show / ready for a POC?” → a 20-question faithful/partial/hallucinated gate, zero ungrounded claims, plus the eval harness handed to the buyer.
08“Compress this to 10 minutes for our CRO.” → one flow (name account → cited draft → approve), lead with the hour-to-20-seconds value, drop the plumbing.
09“What would you do differently at production scale?” → per-tenant isolation + CMEK, trajectory eval + observability, the 5-stage POV with exit criteria.

Going deeper, the curveballs that separate offers: “the email cited something that turned out wrong” (validate citations exist and are entailed; flag-or-refuse low-confidence — L1/L2), “a prospect’s data showed up that shouldn’t have” (filter-then-retrieve by ACL; scrub output; redact logs — L4), “walk me through changing the email tone in prod” (it’s a versioned prompt artifact — diff, eval on the golden set, roll back), and “talk me out of full autonomy” (map reversible vs. irreversible actions; autonomy on research, approval on send). Tie every answer to a metric, a number, and the failure it prevents — and remember the cross-source finding: when content is strong, delivery polish multiplies it; when content is weak, no polish saves you.

articleHow Do You Evaluate AI Vendors Beyond the Demo? (the 5-stage POV framework)AI Assembly Lines articleNailing the SE Interview Demo (Tell-Show-Tell, objection handling, the rubric)oper8r articleThe Sales Engineering Interview at Datadog (the demo round, end to end)Jungwon Kim articleThe Complete Solutions Engineer Interview Guide for Salesforce (Substance/Structure/Relevance/Delivery rubric)CleverPrep

Checkpoint

An interviewer says: “Build us a demo that researches an account and drafts outreach.” What’s the strongest first move?

AImmediately start coding the agent and retrieval to show technical speedBPick the trendiest multi-agent framework and start wiring it upCScope it out loud first — sources, truth bar, data (synthetic vs real), draft-vs-send, tenancy/stakes — then design to those constraints

Checkpoint

During the demo, the drafted email praises the prospect for “your recent Series C” — but that funding round isn’t in any retrieved source. What does a production-quality build do?

ADrop claims that have no source_id, cite each remaining claim, and enforce refusal so unsourced “facts” never reach the draftBLeave it in — confident, specific flattery improves reply ratesCLower the temperature so the model invents fewer details

Checkpoint

A buyer asks whether the system can just send the outreach automatically to save reps time. What’s the strongest design stance for the demo?

AYes — full autonomy is the most impressive version, so enable auto-sendBKeep it draft-only with a human-in-the-loop approval (and idempotent send), and frame the gate as the feature that prevents spam and errorsCEnable auto-send but add a high temperature so emails feel more human

Checkpoint

You’re demoing for two prospects in one session on a shared environment. While researching Account A, a finding about Account B appears. What should already be in place?

AA tenant_id on every chunk and an ACL/tenant filter applied at retrieval time, with per-tenant isolation across the stackBA post-processing step that removes other accounts’ names from the final emailCA prompt instruction telling the agent to only consider Account A

Checkpoint

Your account-research demo works on a few hand-picked accounts. How do you know it’s ready to present to a flagship prospect?

AThe emails read well and your manager liked themBIt uses the newest model and a managed vector databaseCIt passes a 20-question smoke test on real accounts (zero ungrounded claims), scrubs PII both sides, isolates tenants at retrieval, and gates send behind a human

Could you build AND present this account-research → outreach demo end to end — grounded, scrubbed, isolated, gated — and defend every decision through the deep-dive and the derail?

Not yetMostlyYes

You can now

Scope a customer demo before building — sources, truth bar, data handling, action scope, tenancy/stakes.
Assemble account-research → cited-findings → drafted-outreach with a human-in-the-loop send gate, end to end.
Build it synthetic-first, scrub PII on both sides, isolate tenants at retrieval, and treat retrieved/web content as untrusted.
Gate it with a 20-question smoke test (zero ungrounded claims) and defend the cost/latency/tradeoff numbers.
Present with Tell-Show-Tell mapped to buyer pains, name the failure modes unprompted, and handle the derail honestly.

You’ve built the full customer-facing AI demo skill set — grounded, secure, agentic, and presentable. Next: take it into a real take-home and rehearse the loop end to end.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free