Navigator
A team of agents that does the market, account, and prospect research, drafts and checks every touch, handles replies, and tells each rep what to do next.
Designed for 500 BDRs, built to run at 1,000. A concept for a 500-rep sales org, prepared by James Holm, September 2026.
- Quote it as is or not at all
Agents personalize only with receipts. For a public company that is a verbatim quote from a call or filing. For a private one it is the artifact itself: a job posting, a press release, a funding announcement. No artifact, no personalization; the touch runs on fit and timing.
- Research once, use many
Account briefs live in Snowflake with a freshness date. Nothing gets re-researched inside 14 days unless a new signal fires.
- Autonomy by tier
SMB touches send on their own within caps. Mid-market drafts wait for a rep. Enterprise gets research and warm paths, and a human writes.
- Outcomes retrain the score
Every reply, meeting, and opp flows back. Weights get recalibrated monthly against what converted, and QA grades get checked against reply rates.
- Enable reps, don't replace them
Every rep starts the day with a next best action for each account: who to contact, on which channel, and the receipt that makes it worth doing now. Agents handle the research and first drafts. Reps keep the judgment, the relationships, and the conversations.
How it's built
Five layers. Click any part to see its job, what it takes in, what it sends on, and what replaces it if it isn't available.
Signals and data
Where the facts come from
Identity and memory
One id per company, one place everything lands
The agent team
OpenAI models, prompts kept portable. Built with Codex.
Execution
Where touches actually happen
Rep interface
Where a rep lives all day
A rep's morning
One account, start to finish, as Marcus sees it in Slack. The panel beside it shows which tool or agent did each piece of work. Larkspur Dynamics and everyone in it are fictional.
How data moves
Where each fact enters, what happens to it at every hop, and how outcomes find their way back to the tables the score is built from. Read it top to bottom. On a phone, the figure scrolls sideways.
One signal, hop by hop
What happens to a record at each stage, and how often.
| Collecthourly, nightly, live | SteadyBase signals arrive as shared Snowflake views and as a delta feed polled on a cursor, so nothing is replayed or skipped. Clay pushes enriched rows and fires a webhook when a play matches. Salesforce syncs nightly. Apollo and Nooks post events as they happen. TheSwarm paths refresh weekly per account. |
|---|---|
| Resolveon arrival | Each account row is matched to one account_id through the identifier ladder and to its Salesforce id. Contacts key on account_id plus LinkedIn URL. Ambiguous or conflicting rows go to a review queue; nothing is guessed, and a subsidiary carrying its parent's website is caught here. |
| Storehourly builds | Raw tables are append-only and keep the source URL on every signal. dbt builds the core tables and the marts the playbook and the manager view read. A signal without a source URL never gets past raw. |
| Scorenightly, and on every signal | SQL computes fit, signal, timing, and relationship. Tier follows from segment; priority from the score. The model turns the components into three plain-language reasons a rep can read in five seconds. |
| Decideevent-driven | The orchestrator wakes for an account when its score or signals change. It checks suppression, send caps, and whether the brief is still fresh. Only then do agents run, and only the ones needed. |
| Research and draftper account, cached 14 days | Account research writes or refreshes the brief. Prospect research fills the committee with a verified channel and a warm path. Messaging drafts from receipted facts only. QA grades; below B goes back for a rewrite. Agents read the cache first and call vendors only for what is missing. |
| Act7 AM local, then live | A card lands in Slack. Tier A sends within caps. Tier B waits for a tap. Tier C gets research and a warm path only. Taps become Apollo enrollments, Nooks calls, TheSwarm intro requests, Centralize maps, and Salesforce tasks. |
| Learnlive, refit monthly | Opens, replies, call dispositions, meetings, and opps are written to outcomes, joined to the touch and the signal that started them. Monthly, the weights are refit against what converted, and QA grades are checked against reply rates. |
Rules for the data
The constraints the pipeline enforces, not the ones it hopes for.
- Receipted or not stored. A signal without a source URL is rejected at ingest. The quote is stored verbatim; the model never paraphrases it into outreach.
- Dedupe on account_id and nothing else. Ticker and domain are joins of convenience. If two rows share an id, that is a bug to fix upstream, not a merge for a rep to notice.
- Contact data stays in the data layer. Email and mobile live in Snowflake and Apollo. A prompt gets a first name, a title, and the brief. It never sees a phone number.
- Suppression runs twice. Once at search time through MoltSets and Clay exclude lists, so suppressed people never come back, and again immediately before any send.
- Briefs expire. Older than 14 days, or older than the newest signal on the account, and the brief is rebuilt before a rep sees it.
- Every touch carries its draft id and QA grade. A reply can always be traced to the exact words that earned it, which is what makes the monthly grade check possible.
- Geography gates autonomy. Every contact carries a country. Tier A applies only in permitted geographies, EU contacts are always human-approved, and mobiles are scrubbed against do-not-call lists before any call list is built.
- Retention follows the company's CRM policy. Vendor DPAs cover SteadyBase, MoltSets, TheSwarm, and Centralize; transcripts from Nooks keep the same retention as Gong or the call recorder already in place.
Tables the system keeps
The core schema, trimmed to the columns that carry the design.
How we'd build it
One repo, six parts, three weeks to a live pod. Each part starts as a one-page spec (the interface, the tables it reads and writes, the tests that prove it), gets generated with Codex in a fresh session, and is reviewed before it merges. The models are OpenAI's; prompts and evals live in the repo, so a model change is a pull request, not a rewrite.
The spec is a repo
The demo is the pitch. The spec is what gets handed to Codex on day one: github.com/holmjames/navigator. It fixes every decision a builder would otherwise re-make, and the two parts that can be executable already are: the orchestrator's rules and the scoring arithmetic, 49 tests, green.
What gets built
Everything is code, including the Clay plays, so a change is a pull request and a rollback is a revert.
Code or configuration
Most of Navigator is scheduled batch work, which is what Snowflake, Clay, and a flow tool already do well. Code is reserved for the three places it is actually required.
| Job | Least-code home | Why it can live there |
|---|---|---|
| Signals in | SteadyBase shared views; Clay's Snowflake destination; Salesforce through the native connector; Apollo and Nooks webhooks into n8n | Every source already pushes or shares; nothing has to be polled in code except the SteadyBase delta feed, which is one scheduled HTTP call with a stored cursor |
| Enrichment | Clay columns: MoltSets, TheSwarm, and Apollo as HTTP enrichments in the waterfall | Clay is the scheduler and the retry logic; a worker would only duplicate it |
| Scoring and reasons | dbt models on Snowflake tasks; reason codes through Cortex, which hosts OpenAI models on Azure-region accounts | Nightly SQL with a model call inside it, no service to run |
| Briefs, drafts, QA | Nightly batch: Cortex in SQL where the region allows it, otherwise one n8n flow that files an OpenAI batch job and collects it | Thousands of rows a night with no latency requirement is batch work, not agent work |
| Replies | n8n: Apollo reply webhook, classify, draft, post to Slack, send on approval | Event-driven and low volume; a flow tool's home turf |
| Slack cards and buttons | Code. A small Bolt app | Slack needs the button endpoint to answer in three seconds and the Edit flow opens a modal; flow tools handle this badly and Zapier not at all |
| Orchestrator | Code. One decision function with tests, called from the nightly run and from the reply flow | The rules of engagement (routing, caps, geography, tiers) have to be reviewable and testable, which is what code with a test suite is for |
| Evals and the cost meter | Code. A golden set in the repo, run in CI | Prompt regressions are caught before a send, not after |
Zapier fits a ten-rep pilot's glue and nothing past it: per-task pricing at 100,000 touches a month costs more than the model, and it cannot host the Slack endpoint. n8n, self-hosted in the company's cloud or on n8n's cloud plan, is the flow tool that scales; it still needs someone watching it, which is why the batch work sits in Snowflake wherever it can.
If procurement is slower than three weeks
Week one runs on tools already approved. Each new vendor joins the waterfall when it clears security, and nothing downstream changes shape.
| Layer | Runs on day one | Joins when cleared |
|---|---|---|
| Signals | Clay plays on job posts, funding, tech detection, and Claygent research; SteadyBase if it is already in place | SteadyBase for receipted quotes on the public book |
| Identity | A domain-first ladder in Snowflake with a review queue, Salesforce ids mapped | The SteadyBase resolver for LEI, CIK, and the corporate tree |
| Contacts | Apollo | MoltSets in front of Apollo for verified email and mobile |
| Warm paths | None; the relationship term scores zero and the orchestrator goes cold | TheSwarm on the book, then Centralize on live deals |
| Everything else | Snowflake, Salesforce, Apollo sequences, Nooks, Slack, OpenAI | Unchanged |
Week by week, and what done looks like
Every Friday ends with a demo the pilot pod's manager can react to.
Week 1, foundationdata, plays, skeleton
The book is in Snowflake with one id per account and a match rate we can argue with. Five plays fire on real accounts. Every account has a score with three reasons. The Slack bot posts a plain card.
Friday demo: the board for one pod, ranked, with reasons. No drafts yet.
Week 2, agentsbriefs, drafts, playbook
Briefs cached for the pod's accounts. Drafts with QA grades. Verified email for most P1 contacts, and a warm path where one exists. The morning playbook runs for 10 to 20 reps. Tier A stays off.
Friday demo: a rep's morning, live, on real accounts.
Week 3, the loopexecution, replies, outcomes
Taps enroll in Apollo and land on Nooks lists. Replies are classified and drafted. Centralize is on live deals for the AE handoff. Outcomes are written. The manager view is live. Tier A turns on for SMB with caps.
Friday demo: signal to meeting, end to end, with the log beside it.
Afterpods of fifty a week
Tier boundaries tuned from the first month's replies. First weight refit at day 30. Each new pod gets the same three Friday demos, compressed into one.
Who does what
One builder, five people who unblock the builder.
- GTM engineer (this role)
- Owns the repo, the agents, the plays, the Slack app, the cost meter, and the Friday demo. Writes the specs, generates the code, reviews it, ships it.
- Data engineer, part time, heaviest in week 1
- Snowflake access and warehouses, the Salesforce sync, dbt review, compute guardrails.
- RevOps
- Salesforce fields and task types, the suppression rules, territory mapping onto account_id, and the definition of "actioned."
- Pilot pod manager
- Picks the reps, sets tier boundaries with sales leadership, brings the Friday feedback, decides when Tier A turns on.
- Security and legal
- Vendor review and DPAs for SteadyBase, MoltSets, TheSwarm, and Centralize. Retention rules for transcripts and contact data.
- Enablement and product marketing
- The voice guide and the product-claims library the QA agent checks drafts against, so nothing about the product gets invented.
What it costs to run, and the dial for each
The pilot's cost meter makes cost per meeting a number on the manager view. These are the drivers; the Scale tab runs them at list prices.
- Model tokens
- Briefs and drafts are the bulk. Dials: the 14-day cache, a small model for classification and reason codes and a large one for drafts, and Tier C accounts getting research only.
- Clay rows
- Dials: research once, suppression applied at search time so excluded rows are never bought, and a row budget per play with an alert at 80%.
- MoltSets
- Flat plan, so the dial is coverage, not volume. Apollo behind it on every row.
- SteadyBase
- Per tenant, and likely already in place. The delta feed means no re-pulling the book.
- Snowflake compute
- Nightly builds and scoring. Dials: incremental dbt models and one small warehouse dedicated to the pipeline.
- Already paid for
- Slack, Salesforce, Apollo, Nooks, Centralize seats. Navigator adds calls to them, not licenses.
Risks, and what stops them
The ones worth naming before someone else does.
- AI writing to CFOs embarrasses the brand
- Receipted claims only, a QA gate before any send, autonomy by tier, send caps, and a kill switch per tier and per play.
- Deliverability at 500-rep volume
- Caps enforced in Apollo, domain warmup, grade A and B emails only, bounces feed suppression the same hour.
- A vendor is in beta, issues keys by hand, or is a very small company
- MoltSets and SteadyBase both are. Apollo is the fallback on every contact row. For SteadyBase specifically: the company owns the account_id map in its own Snowflake, the resolver ladder is documented and reproducible, receipts are stored as URLs so signals outlive the vendor, and nothing downstream depends on the MCP being up.
- Cold outreach rules differ by country
- Contacts carry a country, and it gates autonomy. Tier A auto-send only in permitted geographies, US and Canada to start. EU contacts are always human-approved under a documented legitimate-interest basis. Business email only, never a personal-email endpoint. Mobiles are scrubbed against do-not-call lists before any Nooks list, and there is no SMS.
- Reps don't use it
- One tap in Slack, nothing to learn, and the manager view shows who actions signals within 24 hours.
- Duplicates and wrong accounts at 1,000 reps
- The resolver with a review queue, never a merge on name or domain, and territories keyed to account_id.
- Prompts drift, quality slides
- A golden set of briefs and emails runs in CI, prompt changes are pull requests, and QA grades are checked against reply rates monthly.
- Privacy
- Contact data stays out of prompts, no personal emails, DPAs with every vendor, retention matched to CRM policy.
How we'd know the pilot worked
Measured from week 1 so there is a baseline, with an account-level holdout inside the pilot pod: the same reps, a random 30% of their accounts on the old process. A separate control pod would carry manager and territory differences, and reps talk.
Scale and pilot
Every number here is an input. These defaults are illustrative; swap in your own and the math updates.
Assumptions
Per rep, per working day, for the accounts a rep touches.
Capacity returned
Time a rep gets back for conversations, not a headcount number.
Why research once matters
Enrichment rows per month across the team: every touch re-researching the account, versus one brief per worked account, refreshed every 14 days or on a new signal.
What it costs to run
Volumes come from the assumptions above. Unit prices are public list prices as of September 28, 2026; a contract number replaces any of them.
The monthly bill
Run cost only. Apollo, Nooks, Salesforce, and Slack are already licensed; the build and the GTM engineer are not in here.
Token counts per job are estimates baked into the page (a brief is about 7,000 in and 800 out; a draft 3,000 and 350; QA 3,500 and 250; a reply 2,500 and 350; small-model jobs 1,200 to 2,000 in). The cost meter in the pilot replaces them with measured numbers.
Autonomy by tier
How 500 reps become 1,000 without the ops team doubling: the agent's freedom scales with how little a mistake costs.
| Tier | Who | Agent may | Guardrails |
|---|---|---|---|
| A | SMB, under 200 employees | Send email and LinkedIn touches on its own | US and Canada to start; caps of 40 sends a day per rep and 2 per contact a week; QA grade B or better; receipted claims only |
| B | Mid-market | Draft everything, pick the next action, enroll after a one-tap approval | Rep approves each send; call scripts are suggestions |
| C | Enterprise and strategic | Research, map the committee, find warm paths, propose timing | A human writes every word; intros go through the connector, never around them |
Three weeks to a live pod
Ten to twenty reps first. Then pods of fifty a week.
Foundation
- Book into Snowflake, resolved to one id per account
- Scoring v1 in SQL with reason codes
- Five signal plays: SteadyBase triggers for public accounts, Clay for the rest
- Slack bot skeleton
Agents
- Account research and messaging with QA in front
- MoltSets and Apollo in the contact waterfall
- TheSwarm on the book for warm paths
- Morning playbook to the pilot pod
The loop
- Apollo and Nooks execution, transcripts back
- Reply agent on the shared inbox
- Centralize on live deals for AE handoff
- Outcomes to Snowflake, manager view
After that: one pod a week, tier boundaries tuned from the first month's replies, and the first weight recalibration at day 30.
Decisions to make together
The design changes depending on the answers.
- How much of the book is public. SteadyBase is shaped around SEC filers. Whatever share is private or mid-market is Clay's job, and that sets Clay's budget.
- Where the SteadyBase pilot stops today. If signals already land in Snowflake and Slack, the gap is wiring them into what reps do each morning, and that is most of the work.
- Tier boundaries. Which segments get auto-send, and what the caps are. This is a sales leadership call, not an ops one.
- One relationship layer or two. TheSwarm finds warm paths in bulk before contact; Centralize maps the committee once a deal is live. If budget forces one, start with TheSwarm in Clay and add Centralize for the AE handoff.
- Which OpenAI models, and where prompts live. GPT-5.5 for drafting and GPT-5 nano for classification to start, prompts versioned in the repo with evals, so a model change is a pull request.