PitchPrep — Multi-Agent Sales Research Assistant

Overview

PitchPrep is a multi-agent sales research assistant designed for sales representatives, founders, and agencies preparing for outbound conversations.

A user provides a company name, website or social link, and optionally additional pasted information. PitchPrep researches the prospect, identifies relevant business signals and likely needs, matches those needs to the seller's offering, and produces an evidence-backed prospect brief together with a draft outreach email.

The system is designed around one core principle: generated sales claims should be traceable to actual evidence.

The Problem

Sales outreach often requires significant preparation.

Before contacting a prospect, a salesperson may need to:

• Research the company
• Understand recent developments
• Identify possible business needs
• Determine relevant decision-makers
• Connect those needs to their own offering
• Write a personalized outreach message
• Verify that the message does not contain unsupported claims

Doing this manually across websites, news sources, and company pages takes time.

Generic AI-generated outreach can make the process faster, but it introduces another problem: the model may produce plausible claims that are not actually supported by evidence.

PitchPrep was designed to automate research while keeping evidence visible and verifiable.

Multi-Agent Workflow

The research workflow is orchestrated with LangGraph and separates the process into specialized stages.

Input Parser

The Input Parser structures the user's company information.

If additional company text is pasted, the parser extracts structured details from it. Otherwise, the entered company name is used directly.

Source Collector

The Source Collector gathers evidence from the supplied website or social link and searches for recent news context.

Collected content is converted into source excerpts that can later be cited by the research workflow.

Link Check

Before continuing, PitchPrep checks whether the supplied page appears to belong to the intended company.

If the company identity appears mismatched, the workflow pauses and asks the user to confirm the link or correct the input.

Analyst

The Analyst reviews the collected evidence and identifies potential:

• Trigger events
• Business developments
• Operational challenges
• Likely needs

The analysis remains connected to the collected source material.

Matcher

The Matcher connects the identified company needs to the seller's offering.

It also suggests potentially relevant target roles for outreach.

Writer

The Writer generates:

• The prospect brief
• Outreach email subject
• Outreach email body

The generated output references the source IDs available from the research stage.

Verifier

A dedicated Verifier checks the generated claims and email content against the collected evidence.

Unsupported claims are returned to the Writer for revision.

The workflow allows a bounded number of revision attempts. If a statement remains unsupported after the revision limit, it is removed and the result records the evidence limitation.

Evidence-First Generation

One of the main design goals of PitchPrep is to reduce unsupported AI-generated sales claims.

Every retained brief claim carries source references.

The system also validates that extracted evidence quotes actually exist inside the original source excerpts.

The final interface exposes:

• Source citations
• Evidence excerpts
• Verification status
• Evidence limitations

This allows the user to inspect the reasoning behind the generated brief before using it in an outreach conversation.

Thin-Data Handling

Some companies have very little publicly accessible information, while social pages may be blocked from automated collection.

PitchPrep is designed to continue with the evidence that is available rather than silently inventing missing information.

Users can also paste additional company information directly into the research form.

When the available evidence remains limited, the system explicitly communicates those limitations in the final brief.

Durable Research Jobs

Research is not executed entirely inside the original HTTP request.

When a user submits a company:

1. A queued research job is stored in Supabase.
2. The API immediately returns a brief ID.
3. A backend worker acquires a database lease.
4. The LangGraph workflow executes independently.
5. Stage progress and checkpoints are persisted.
6. The final result, claims, and sources are stored transactionally.

This means closing the browser or losing the live stream does not automatically cancel the research job.

Real-Time Progress

PitchPrep exposes workflow progress to the frontend using Server-Sent Events.

Users can see stages such as:

• Parsing
• Collecting
• Analyzing
• Matching
• Writing
• Verifying

If the live SSE connection is interrupted, the frontend can recover using persisted snapshots and polling.

Sales Brief

The resulting prospect brief organizes the research into useful sales context, including:

• Company facts
• Recent signals
• Likely needs
• Suggested target roles
• Supporting evidence
• Evidence limitations

The objective is to give the salesperson a concise preparation document rather than a raw collection of scraped pages.

Email Generation

PitchPrep also generates an outreach email based on the verified research.

Users can:

• Review the generated subject and body
• Edit the email manually
• Save their edits
• Copy the final version
• Regenerate using different tones

Supported styles include professional, friendly, and concise.

Email regeneration reuses the previously collected evidence rather than performing another full research run.

Human Review

PitchPrep deliberately does not automatically send generated emails.

The user remains responsible for reviewing, editing, copying, and sending the final message.

Human edits are stored separately from the automatically verified AI output so the system does not incorrectly present user-written additions as machine-verified claims.

Persistence

Supabase PostgreSQL stores:

• Seller profiles
• Research briefs
• Research state and checkpoints
• Sources
• Verified claims
• Email edits
• Feedback
• Job leases

Database functions handle job acquisition, lease ownership, optimistic version checks, and atomic persistence.

Security Architecture

The browser does not connect directly to application tables.

FastAPI owns database access and provider credentials.

Supabase Row Level Security remains enabled, while public database roles do not receive access to the application's tables or functions.

Provider credentials remain on the backend.

Observability

LangSmith is integrated for workflow tracing.

Tracing captures workflow and agent execution while the project's tracing wrapper hides sensitive source bodies, pasted information, and credentials from trace inputs and outputs.

User helpfulness feedback is persisted in Supabase and can also be delivered to the corresponding LangSmith trace.

Testing

PitchPrep includes both backend and frontend automated testing.

Backend tests cover:

• Schemas
• Retries
• Provider adapters
• Workflow branches
• Verification logic
• API behavior
• Persistence
• Feedback delivery

The frontend uses Playwright for browser-level workflows and axe-core for automated accessibility checks.

Tests cover major user journeys including research submission, recovery, link confirmation, progress states, source links, email editing, regeneration, feedback, and connection failures.

What I Learned

PitchPrep gave me hands-on experience designing an agentic application where reliability and evidence quality are as important as text generation.

The project involved:

• Multi-agent workflow design
• LangGraph orchestration
• Evidence-grounded generation
• LLM verification loops
• Durable background jobs
• Supabase persistence
• SSE streaming
• Provider retry handling
• Structured Pydantic outputs
• LangSmith observability
• Full-stack Next.js and FastAPI development
• Automated API, browser, and accessibility testing

Most importantly, the project reinforced that production AI systems need explicit mechanisms for uncertainty, verification, failure recovery, and human review rather than relying entirely on a single model response.