Prospecting Is Surgical, Not Volumetric: Inside Two AI Prospecting Builds at Chili Piper

By Marty Breyer & Maria Alice Gomes, Chili Piper (AE) & Director of Sales Development · June 4, 2026

Prospecting is where GTM teams are seeing the most action in custom-built AI right now, and this session showed two very different ways to use it. Marty Breyer, an account executive, built a full prospecting engine in Claude Code with no coding background, using a framework that lets the agents fix themselves when something breaks. Maria Alice Gomes, who leads the SDR team, took the opposite approach: she left a proven cadence process untouched and slipped AI in underneath it to handle research and personalization at scale. One build is hands-on for a single rep working named accounts. The other is team-scale automation for an SDR org running high volume. This recap covers both.

Part 1: Prospecting for AEs (Marty Breyer)

Marty started building this tool while he was interviewing for his AE role at Chili Piper. His logic: job searching looks a lot like prospecting, so a tool that helped him research and reach the right people during the interview process would double as a prospecting tool once he was in the seat. It was also how he taught himself Claude Code.

What did Marty build?

An outbound prospecting agent that runs locally on his machine, built in Claude Code with Visual Studio Code as the workspace. It takes a named account and produces account research, a stakeholder map, a full outreach cadence, and then pushes that cadence into the sequencer. Marty does not know Python and cannot write the scripts himself. Claude Code wrote all of the underlying code; Marty's job was to describe what he wanted and review the output.

The agent responds to a set of plain-language commands:

Under the hood it connects to the tools Marty already has access to at Chili Piper. He uses LeadIQ to enrich contacts and SalesLoft (or Outreach, or any sequencer) to deploy the cadence. He wanted to connect Gong as well, but its MCP server is not available yet.

What is the WAT framework?

The foundation of the whole build is a structure Marty calls WAT, which stands for Workflows, Agents, Tools. He picked it up from a roughly ten-hour Claude Code course by Nate Herk on YouTube, copied the starter Markdown file into his project, and let it grow from there.

The idea is to separate reasoning from execution so the system stays reliable. Each layer has one job:

The reasoning behind the split is simple math. When an AI tries to handle every step directly, accuracy compounds downward fast: if each step is 90% accurate, you are down to about 59% success after just five steps. By pushing execution into deterministic scripts, the agent stays focused on orchestration, where it is strongest.

Why does WAT fix itself?

This was the feature that drew the most interest in the room. The framework includes a self-improvement loop, so the agents detect when a connection breaks and repair it on their own. When an external system changes and an integration stops working, the agent reads the error, digs into what changed, updates the script, and keeps going. Marty contrasted this with workflow tools like n8n, which break and stay broken when an upstream system changes until someone debugs them manually.

The loop is the same one written into the starter file: identify what broke, fix the tool, verify the fix, update the workflow so it does not happen again, then move on with a more robust system.

Does the starter file need editing?

No. Marty copied the WAT framework file in as-is and then had Claude Code update it as the project matured. As he built out the prospecting tool, he asked the agent to revise the Markdown to be more efficient and more specific to what he was actually doing. The updated file now carries his prospecting philosophy directly in the instructions:

• "Prospecting is surgical, not volumetric"
• "You're not an SDR"
• "Every touch demonstrates homework"
• "Multi-threading is the single highest-leverage activity"
• "Prospecting compounds"

He also noted that splitting work across separate workflow files keeps token usage down. Instead of loading one giant instruction file on every run, the agent can go straight to the specific workflow it needs.

How does the live build actually run?

Marty always starts in plan mode. He describes what he wants ("connect this to SalesLoft and push this sequence in"), Claude Code returns a plan, and only after he approves it does the agent execute. When he asked it to connect to SalesLoft, it produced the full plan, built the Python scripts, and wired up the connection.

For finding the right people inside an account, the tool uses what Marty called the POIS framework, an approach for identifying the economic buyers. In a live test against the Chili Piper account, it surfaced the relevant stakeholders (including the SDR leader presenting next) and generated a CSV with the outreach and cadence. A sample cadence it built looked like this:

Where does the human still come in?

Two places. First, Marty tells the tool who to target within an account ("give me the marketing operations lead, give me the VP of Marketing"), because the rep usually knows the org better than the model does. Adapt that line to whatever you sell, and the rest of the build carries over. Second, voice. The generated cadence still reads "a little AI-y," in Marty's words, so he reviews and rewrites until it sounds like him before anything goes out.

On results, Marty was honest: he is still onboarding and does not have conversion numbers yet. The build is proven to work end to end; the pipeline impact is still to come.

What else can the WAT framework build?

Marty's larger point was that the prospecting tool is just one example. The same starter file has produced an email manager and even a weekly food-ordering tool for him. You begin with the WAT Markdown file, tell it what you want to build, and the framework handles the rest. The build is currently local to his machine and can be pushed to a GitHub repository for the community to use, once the API keys baked into it are hidden.

Part 2: Prospecting for SDRs (Maria Alice Gomes)

Maria, who directs the SDR team, took a deliberately different path. Her process already worked, with tested cadences and templated emails for each use case, so she did not want to rebuild it. She wanted to remove the slowest manual step and add personalization at scale without slowing her reps down.

What problem was Maria solving?

Her SDRs were spending around 10 to 12 minutes per account on manual research: which competitor the prospect uses, what form they have on their website, what fields are on that form, and so on. Across more than 30 accounts a week, that is over six hours per rep, nearly a full working day spent on research alone.

She also did not want to spin up a unique cadence for every prospect. SDRs run far more volume than a dedicated AE, and one cadence per person makes it impossible to measure what is working. The goal was to keep the templated, A/B-tested cadences and inject quality personalization into them automatically.

How does Maria's automation work?

There is no chat interface and no "cute lovable front end," by design; she did not want reps spending time talking to a tool. It runs quietly in the background on a schedule:

1. Every 15 minutes, it checks for the last 80 people newly enrolled in cadences in SalesLoft.
2. It pulls those contacts and their account context from Salesforce: open opportunities, prior conversations, which cadences they have already received, their competitors, and their tech stack.
3. It sends that context to Claude with a very tight prompt and asks for a personalization snippet, the opening paragraph of the email.
4. It writes everything back to SalesLoft and Salesforce so the data stays clean.

The SDR's only job is to keep up with their tasks in SalesLoft, where the personalized opener is already filled into the cadence. The rest of the email continues from the existing template.

Why does the prompt have to be so strict?

Quality control was the hardest part. Because the snippet feeds straight into a templated cadence, it has to follow exact rules. Maria's prompt includes:

• Forbidden phrases, like openers that start with "Curious if" or "Curious whether"
• No CTA question, because the templated email that follows already has a call to action. A second one creates "CTA collision," so she includes real examples of it to avoid.
• Word and phrase limits, to keep the snippet tight
• A fallback order for what to lead with, for example whether to reference a competitor or a previous closed-lost conversation first

She tuned all of this over many rounds with her senior SDRs, asking how they would reword each generated snippet until it sounded natural rather than "very AI-ish."

Did it actually work?

Yes, and unlike Part 1 there are numbers. In an A/B test comparing the AI personalization snippet against the standard templated email, the version that opens with personalization lifted open rate from 28% to 36%, an eight percentage point gain. The reps also got their research time back, since the custom fields they used to fill in by hand are now researched and populated automatically.

What did Maria learn building it?

Her learnings are the most useful part for anyone attempting something similar:

• Building is fast; making it work is slow. You can stand something up quickly now, but the real time goes into debugging and turning it into something that saves time rather than costs it.
• Watch for silent failures. Things break without announcing it, so a tight feedback loop matters. Her SDRs flag every miss ("this one didn't get a snippet," "this doesn't sound like me"), which tells her exactly what to fix each day.
• Be extremely specific to control hallucination. For email quality especially, you need hard rules: never say this, never say that, stay under this many words.
• Clean numbers before the AI sees them. The model would misread figures, reading 15 as 14, for example. The fix was to add code that formats and cleans numbers before the AI digests them, rather than trusting it to read them correctly.

After seeing Marty's self-healing setup, Maria said the auto-improvement loop is exactly what she wants next, since she is currently doing that debugging by hand.

Key Takeaways for GTM Teams

• You do not need to code. Marty built a working prospecting engine in Claude Code without writing Python. The WAT framework (Workflows, Agents, Tools) separates reasoning from execution and lets the agents repair themselves when integrations break.
• Keep deterministic work in code. Accuracy compounds downward when AI handles every step. Push execution into scripts and let the agent orchestrate.
• Do not rebuild what works. Maria's biggest win came from layering AI underneath a proven cadence process, not replacing it.
• Personalization at the open is measurable. An AI-generated opening paragraph lifted open rate from 28% to 36% in a clean A/B test.
• Strict prompts beat clever ones. Forbidden phrases, word limits, CTA-collision examples, and pre-cleaned numbers are what made the SDR output usable.
• Budget for debugging. Both speakers agreed: building is fast now, but making it reliably useful is where the real time goes.

About the Speaker

Marty Breyer is an Account Executive at Chili Piper. He built his AI prospecting tool in Claude Code while interviewing for the role, with no prior coding background, and uses it to research accounts, map stakeholders, and build outreach cadences that push directly into SalesLoft. Connect with Marty on LinkedIn.

Maria Alice Gomes is Director of Sales Development at Chili Piper. She leads an SDR team that has layered AI into its existing cadence process to automate account research and generate personalized email snippets at scale, while keeping the templated, A/B-tested structure that lets the team measure and improve. Connect with Maria on LinkedIn.

Get the Surgical Outbound — WAT Prospecting Agent

Watch the session replay: Inside Two AI Prospecting Builds at Chili Piper