Build an Ava-Inspired BDR Agent That Runs on Its Own Computer – OpenComputer
Contents<br>What you'll build<br>Why a BDR needs a computer<br>Architecture<br>Prerequisites<br>1. The BDR computer<br>2. Model the CRM<br>3. Accept the ICP<br>4. Durable lead loop<br>5. Untrusted web text<br>6. Score fit<br>7. Draft with sources<br>8. Approval gate<br>9. Send one email<br>10. Handle a reply<br>11. Prove durability<br>Run the safe demo<br>Costs and limits<br>Closing<br>← Back to blog<br>Build an Ava-Inspired BDR Agent That Runs on Its Own Computer
Written by Utpal Nadiger · June 27, 2026
I kept seeing Artisan’s “Stop hiring humans” billboards around San Francisco.
Artisan's “Stop hiring humans” billboards around San Francisco.<br>The moral debate aside, the product does look cool and could be helpful: Ava is Artisan’s AI BDR, built to source leads, write outbound, handle replies, and book meetings.<br>Being the engineer I am, I decided to build it myself so I could use it at OpenComputer and do outreach for us.<br>I was trying to replicate a BDR in software, and a BDR has state. It needs a CRM, an inbox, notes, reply history, suppression rules, follow-ups, and some way for a human to inspect what it is about to do before it does something irreversible.<br>So I built a small, inspectable version of the loop and called it Open Ava. It is one FastAPI app inside one OpenComputer VM, with the VM acting as the BDR’s computer, SQLite as its CRM, AgentMail as its inbox, and Anthropic handling the structured research, scoring, drafting, and reply classification.<br>The run went like this:
I gave it OpenComputer's product profile and ICP,<br>imported 12 seeded leads,<br>researched and scored them,<br>drafted three sourced outreach variants for the best lead,<br>blocked sending before approval,<br>created a checkpoint before the real send,<br>sent one email only to a controlled test inbox,<br>received a real reply through AgentMail,<br>classified the reply as an objection,<br>sent a follow-up,<br>and kept a durable CRM record across an app restart and checkpoint.
A browser screenshot from the redeployed VM after the run and app restart: 12 leads, 11 rejected and one sent, with approval, send, dedupe, reply classification, and follow-up events in the activity log.<br>The actual lead-card page for the qualified lead, using the stored research note, source-backed facts, and approved draft variants from the CRM.<br>The code for the run is on GitHub here: github.com/diggerhq/opencomputer-cookbooks/tree/main/open-ava-bdr. Here is how you can build the same loop yourself.
What you’ll build
The finished app is a little BDR workspace:
A persistent OpenComputer VM that acts like the BDR's laptop.<br>A FastAPI dashboard and JSON API exposed through the VM preview URL.<br>A SQLite CRM with campaigns, leads, research notes, drafts, emails, suppression records, durable queue rows, and events.<br>A background worker that imports leads, dedupes them, researches their company URLs, scores fit, and drafts outreach.<br>A prompt-injection-aware research path that treats scraped pages and inbound emails as untrusted data.<br>A human approval gate before any send.<br>A checkpoint before the irreversible send.<br>AgentMail send and inbound reply handling.<br>Idempotency for discovery, sends, and reply processing.
The tutorial uses OpenComputer itself as the product and a controlled inbox you own. The app never emails arbitrary prospects while you work through it.
Why a BDR needs a computer
A human BDR lives out of their computer. They open their CRM and pick up where they left off: which accounts they researched yesterday, which leads were a bad fit, which drafts are waiting for approval, which replies need an answer, and which people should not be contacted again.<br>An agent doing BDR work needs the same kind of workspace. It needs to remember what it has already researched, keep drafts around until a human reviews them, avoid sending twice when a provider retries an event, and know the difference between a lead that is ready for follow-up and one that should stay rejected. I wanted my agent to have one computer with its own filesystem, local CRM, running process, inbox logic, preview URL, and checkpoints, so I used OpenComputer.<br>In this build, the OpenComputer VM is the BDR’s machine, with SQLite as the CRM on disk, FastAPI as the dashboard, a worker that keeps moving leads forward, and AgentMail as the inbox. Before the app sends the approved email, the control script creates a checkpoint so there is a rollback line before the system touches the outside world.
Architecture
Here is the loop in product terms first:
The user enters the product and ICP once.<br>The worker imports or discovers lead candidates.<br>Each lead is researched from the company URL we already have.<br>The LLM produces a structured research note with source-backed facts.<br>The LLM scores the lead against the ICP.<br>Fit leads get multiple sourced email variants.<br>A human approves one variant.<br>The control process creates a checkpoint.<br>The app sends one email to the controlled test inbox.<br>AgentMail receives a...