Skip to content
Bot jobsJob breakdowns

How to use GPT-6 Astra with Grok Bot to build a 7-figure agent-run GTM team

Your next outbound hire might be four bots and a folder of SOPs. One builds verified lead lists. One writes controlled split tests. One assembles campaigns. One watches sending health. GPT-6 Astra

Rashad JungbluthImported from X9 min read
AI_Acqx article
See this runHouse 319 · 00428

Article

Job breakdowns

Your next outbound hire might be four bots and a folder of SOPs.

One builds verified lead lists.

One writes controlled split tests.

One assembles campaigns.

One watches sending health.

GPT-6 Astra handles the scraping, enrichment and analysis behind them.

The interesting part is not that AI can write cold emails.

It is that an entire campaign can move from research to execution without someone chasing every handoff.

Here is the architecture, down to the campaign settings, verification rules and failure conditions.

Start with artifacts, not personalities

A cold email campaign is a chain of deliverables:

Verified list → test hypothesis → approved copy → configured campaign → performance data → next iteration.

Each deliverable needs:

  • one owner

  • defined inputs

  • a storage location

  • a definition of done

  • an escalation condition

That is the shape of work an agent can hold.

Written SOPs already contain most of the architecture. The points where one employee finishes and another starts become the agent handoffs.

In this setup, Grok Bot holds the persistent roles and browser workflows. Each bot works from its own cloud computer, with a browser, filesystem, terminal and authenticated app sessions. Shared threads coordinate the specialists; recorded workflows provide repeatable skills.

Astra is the coding layer: scrapers, enrichment jobs, reporting queries and infrastructure checks.

Grok Bot operates the tools.

Astra processes the data.

The SOP defines what either is allowed to do.

1. List Builder: verified leads, not CSV volume

The List Builder owns every verified lead list.

The primary source in this workflow is MapsData. The bot uses the company account through its browser.

Its run:

  1. Read the client strategy document.

  2. Select business category and country.

  3. Narrow to states, cities or individual ZIP codes.

  4. Collect broadly within the approved scope and budget.

  5. Filter for personal business email addresses.

  6. Cap contacts at five per company.

  7. Run verification and wait for completion, typically 15 to 60 minutes in the source workflow.

  8. Download the verified file.

  9. Upload it to the client’s leads folder and open it as a sheet.

  10. Confirm the stored version is intact before deleting the temporary CSV.

  11. Post the list name, location and verified row count.

But verification only answers part of the question.

A deliverable email address is not necessarily a qualified prospect.

The qualification gate

The SOP samples 10 to 15 companies before approving a list.

Astra inspects their websites and returns:

  • business category

  • services offered

  • short company description

  • fit against the client’s ICP

  • mismatched or exclusion keywords

If the sample fails, the List Builder updates the exclusions and reruns the search.

If the list fails twice, it escalates with the mismatch evidence attached.

It does not keep scraping the same wrong companies faster.

For LinkedIn-style targeting, the same role follows an Apollo path:

Build search → save search → order an approved third-party scrape → verify → store under the same naming convention.

Different acquisition path. Same downstream artifact.

2. Outbound Copywriter: one changed variable per script

The Copywriter reads:

  • the latest iteration brief

  • the client’s campaign strategy

  • the standing copywriting reference

  • the previous winning script, where relevant

It writes into the campaign document subtab created by the Campaign Manager.

Its most important constraint:

One changed variable per script.

If the test is offer framing, change the framing.

Keep the audience, underlying offer, CTA and other copy elements stable.

If the task is to improve a winning script, preserve the winner and change one small element.

Otherwise, two weeks later, you have a result without an explanation.

The deliverable is a complete sequence:

  • subject line

  • first email

  • one or two follow-ups

  • follow-ups formatted as replies, with blank subject fields

  • spintax on approved variable phrases

  • signature placeholder

  • roughly two or three lines per message

  • one open-ended ask

Most campaigns use two or three steps.

The bot’s job is not to demonstrate how many variations it can write.

It is to produce a test whose result can be interpreted.

3. Campaign Manager: hypothesis, delegation and build

This is the coordinating bot.

It owns the experiment and directs the specialists.

Strategy

Each week, it reads Astra’s performance table, compares results with the client’s KPIs and writes a testable hypothesis.

The split-test variable comes from a fixed menu:

  • offer

  • offer framing

  • targeting

  • risk reversal

  • CTA

  • case study

  • enrichment

  • first line

  • copy

  • winning-script variation

Multiple tests can run, but each gets its own script and identifier.

The manager names the campaign after its target list, adds the relevant test identifier and assigns the required inputs to the List Builder and Copywriter.

Changing an offer still requires human approval.

Campaign assembly

Once the verified list and approved copy are ready, the manager builds the campaign in Instantly:

  1. Upload the verified CSV and map its headers.

  2. Use the cleaned “company name for emails” field instead of the raw company name.

  3. Paste the opening email.

  4. Add the reply-thread follow-ups.

  5. Set follow-up delays to two days, then four.

  6. Select the schedule template for the list’s timezone.

  7. If no template exists, use the SOP’s window of roughly 06:00 to 18:00 local time, Monday through Saturday.

  8. Set the daily campaign ceiling within the approved capacity of the attached inboxes.

  9. Validate the fixed settings.

  10. Launch or schedule only within the bot’s approved authority.

These settings stay constant in the source SOP:

Stop sending on reply: ON Stop on auto-reply: ON Open tracking: OFF Text-only: ON Auto-optimise: OFF Risky emails: OFF

The bot flags any campaign that conflicts with them.

These are explicit operating choices, not universal settings every business must copy.

Validate timezone spread before building

The SOP uses a roughly three-to-five-hour timezone-spread threshold.

Choose an exact threshold for the client.

If a list exceeds it, split the campaign.

One convenient schedule is not useful if it reaches half the audience at the wrong local time.

4. Infrastructure Manager: find the bad inbox before blaming the campaign

This is the only specialist on a fixed daily schedule.

It runs once per client after the overnight data sync.

First, it opens the domain summary and applies a four-week lookback.

It checks reply rate per contact both:

  • including auto-replies

  • excluding auto-replies

That comparison separates human response from automatic noise.

Then it works through the domain table:

  • below-target reply rate gets investigated

  • bounce above 3% triggers troubleshooting

  • domain rows expand into per-inbox detail

  • tags isolate individual batches

The inbox-level view matters.

A damaged domain and one broken inbox inside a healthy domain require different actions.

State changes

The source workflow distinguishes:

Quarantine: remove the affected inboxes from campaigns and return them to warmup.

Reserve: hold a healthy domain for a future swap.

Release / take out: reverse those states through the relevant controls.

Two hard rules sit above the workflow:

  1. Do not pause or unpause sending accounts through controls that interrupt warmup.

  2. Do not quarantine based on thin data.

A handful of sends is not evidence of a domain-wide problem.

Define a minimum sample size alongside the reply-rate threshold.

Cross-check the sending tool

Aggregated dashboards can hide:

  • one provider generating replies while another generates none

  • bounces concentrated on one email service provider

  • disconnected accounts

  • account errors

  • stopped warmup

Astra can build a visual frontend for this data, but the bot still checks the underlying sending tool when the summary looks suspicious.

Rotation

An overdue rotation follows:

Preview → review → execute → confirm.

The calendar should show the old batch stopping where the new one starts.

A gap or overlap means the transition needs investigation.

If a swap completes only partially, continue the unfinished work. Do not restart the full operation and repeat successful changes.

Anything unresolved goes into the client thread with:

  • the affected domain or inbox

  • the numbers

  • the attempted fix

  • the remaining blocker

  • a named human owner

The handoff system: messages point to work

Every client gets one shared thread.

All four bots participate.

The thread carries pointers, not entire datasets.

For example:

LIST READY

Name: chiropractors | 10-50 | texas | 14k Verified rows: 11,412 Location: client leads folder Qualification: passed Next owner: Campaign Manager

The Copywriter does not need 11,412 rows pasted into a conversation.

It needs to know which list exists, what it contains and where to find it.

Three rules keep the handoffs reliable.

Naming is the join key

The list, campaign and copy draft share the same base identifier.

Test variants get explicit suffixes.

No bot should have to infer which draft belongs to which campaign.

Task state triggers the next step

Each SOP ends by marking its task complete on the client’s project board.

That completion fires a webhook.

The webhook wakes the next bot.

The next bot reads the actual artifacts, not a conversational summary.

Missing inputs stop the workflow

A bot that lacks an offer, threshold, timezone or required file posts the missing input and stops.

It does not invent the answer.

The Campaign Manager supplies the input or escalates.

Silent guessing is how small omissions become recurring operational errors.

Where Astra does the heavy lifting

Astra sits behind the specialists with four standing jobs.

Custom scraping

For sources outside MapsData and Apollo:

  • directories

  • association member lists

  • marketplace pages

  • niche-specific public sources

It builds and runs the scraper within the approved access scope, deduplicates against the client’s existing records and suppression list, then writes the result into the common lead schema.

One schema lets every downstream step work without caring where the lead originated.

Enrichment

After email verification, Astra crawls the domains and extracts the fields the copy actually needs:

  • services

  • locations

  • review counts

  • evidence of team size

  • relevant personalization details

Running enrichment after verification avoids spending crawl budget on rejected addresses.

Website claims and estimates should remain distinguishable from verified facts.

Outbound analysis

Astra pulls sending-tool API data into a small database and preserves history.

The reporting breaks down reply rate and positive reply rate by:

  • script

  • split-test variable

  • sequence step

  • sending domain

  • email service provider

  • list segment

The weekly table should answer:

Which variable changed, and what happened?

Use consistent denominators and show sample counts. A percentage without volume is easy to misread.

Infrastructure tracking

A nightly job stores bounce and reply history per domain and inbox.

“Below the minimum reply rate across the lookback window” becomes a repeatable query.

The flagged list reaches the shared thread before the Infrastructure Manager starts.

The bot opens the dashboard already knowing what to investigate.

The operating loop

Daily:

  • Astra refreshes the data.

  • The Infrastructure Manager checks sending health.

  • Exceptions are resolved or escalated.

Weekly:

  • The Campaign Manager reads performance.

  • It writes a hypothesis.

  • The Copywriter creates the controlled test.

  • The List Builder runs only if new targeting requires a new list.

  • The manager assembles the campaign.

  • The next data pull starts measuring it.

A copy variation does not trigger unnecessary list building.

A targeting test does.

Each step starts from a defined event, not from someone remembering to forward a message.

What every bot needs before its first run

Give it the existing SOP, close to verbatim.

Then supply:

  • strategy document with ICP, offer and KPIs

  • campaign scripts document

  • artifact folders and naming convention

  • minimum reply rate

  • bounce ceiling

  • minimum sample size

  • lookback window

  • quarantine period

  • reserve-inbox tag

  • approved sending capacity

  • authenticated sessions with appropriate permissions

  • recordings of UI-heavy steps

  • escalation owner

Here is a reusable role brief:

ROLE: [BOT NAME]

Own: [DELIVERABLE] Read: [INPUT LOCATIONS] Write: [OUTPUT LOCATION] Use identifier: [NAMING RULE]

Follow the attached SOP.

Before acting:

  • verify all required inputs exist
  • validate numeric thresholds
  • check permissions and approval requirements

If an input is missing:

  • post the exact blocker
  • name the required owner
  • stop the dependent task

Completion requires: [ACCEPTANCE CHECKLIST]

After completion:

  • save the artifact
  • post its identifier, location and relevant counts
  • mark the project-board task complete

Never invent missing business facts. Never change the offer without approval. Escalate exceptions outside the SOP.

When a bot underperforms, look for the missing number.

“Low reply rate” is not a threshold.

“Too few sends” is not a sample rule.

“Wait a while” is not a quarantine period.

Ambiguous judgment repeated every day becomes a system you never intended to build.

What stays human

  • offer changes

  • exceptions marked for escalation

  • decisions outside the bot’s authority

  • review of the first few runs before unattended execution

The owner still defines the strategy, permissions and acceptable risk.

Automation removes repeated execution. It does not remove accountability.

Cost: budget the system, not just the seats

The source quotes these rough starting figures:

  • Grok Bot seats from approximately $120 per month

  • Astra at $10 per million input tokens and $50 per million output tokens

  • MapsData plans around $19 to $99 per month

Treat those as source estimates, not a verified current quote.

They also exclude parts of the operating stack: sending software, domains, inboxes, verification, third-party scraping, storage and retries.

The useful comparison is total cost per qualified outcome, not the cheapest subscription.

The part that makes this work

The bots are not inventing a GTM process.

They are executing one that already has owners, inputs, thresholds and handoffs.

A vague process produces vague automation.

A written process gives you something agents can execute, measure and improve.

Four roles.

One shared artifact system.

Explicit handoffs.

Controlled experiments.

Human decisions where they matter.

That is how you move from using AI to write emails to using agents to run the work around them.

Which part of your outbound operation still needs someone to chase the handoff?

Published on grokbot.sh. Cite the public log, not a prompt pack.

Command Menu