I've been seeing a lot of noise about "AI sales agents" that promise to write your emails for you. Most are black-box SaaS with hefty monthly fees and questionable data handling. I built a lightweight alternative that runs entirely within our own infrastructure, controlled by a simple configuration. The goal isn't to automate the salesperson out of the loop, but to act as a context-aware coach that suggests the next best reply based on the explicit deal stage.
The core is a structured prompt and a system that injects stage-specific battle cards and objection handlers. I'm using OpenAI's API for the LLM, but the configuration is portable. The key is the configuration file which defines the stages, their strategic goals, and the relevant knowledge snippets. This runs as a simple service our sales team can call from our CRM's custom action panel.
Here is the primary agent configuration (`agent_config.yaml`). The rationale is that each deal stage has a distinct communication goal, and the suggestions must align with that goal, not just be generically "helpful."
```yaml
agent:
name: "sales_script_coach"
model: "gpt-4-turbo"
temperature: 0.2 # Low creativity, high consistency for sales compliance.
max_tokens: 300
# Knowledge snippets injected per stage. These are curated, not scraped.
knowledge_base:
discovery:
- "Goal: Qualify need, budget, authority, timeline. Avoid solutioning."
- "Objection Handler: 'We're just exploring' -> 'Understood. What would make this a priority?'"
- "Battle Card: Highlight our discovery workshop process."
demonstration:
- "Goal: Reinforce fit between shown features and stated needs."
- "Objection Handler: 'Feature X is missing' -> 'That's noted. How critical is it versus the Y we showed solving your core problem?'"
- "Battle Card: Reference case study A (manufacturing vertical)."
negotiation:
- "Goal: Overcome final objections on price and terms, provide reassurance."
- "Objection Handler: 'Your price is 15% higher' -> 'Our data shows a 20% higher efficiency, leading to ROI within 8 months. Can we walk through that model?'"
- "Battle Card: Standard contract terms summary, discount approval matrix."
closing:
- "Goal: Secure signature, outline onboarding next steps."
- "Objection Handler: 'We need to run this by legal again' -> 'I can provide our pre-signed MSA and a redline summary from previous deals to accelerate that.'"
- "Battle Card: Post-signature implementation timeline."
# The master prompt template. Placeholders are replaced at runtime.
prompt_template: |
You are a veteran sales coach for {company}. Your task is to suggest a concise, effective next email reply for a sales representative.
CURRENT DEAL STAGE: {deal_stage}
CUSTOMER'S LAST MESSAGE: {last_message}
RELEVANT GUIDANCE FOR THIS STAGE:
{stage_knowledge}
CORE INSTRUCTIONS:
- Suggest 1-2 sentences the rep can use directly.
- Tone must be {tone: professional and collaborative}.
- Do not make up specifics about pricing or features not in the guidance.
- The goal is to advance the deal to the next stage, not just answer the query.
SUGGESTED REPLY:
```
The service logic (Python) is straightforward: it loads this config, selects the `knowledge_base` list for the provided `deal_stage`, formats the prompt, and calls the LLM. The result is a single, focused suggestion.
**Results & Reproducibility:**
* **Qualitative:** Sales team adoption hit 75% within two weeks. Feedback cited "reduced mental context switching" and "fewer emails going off-strategy."
* **Quantitative:** We A/B tested a cohort of reps using the coach vs. not on similar-stage deals. The coached group showed a 12% shorter average "time in stage" for the discovery and negotiation phases. No significant change in close rate was observed (which we expected—this is a coach, not a closer).
* **Cost:** Operational cost is approximately $0.002 per suggestion, versus the $40/user/month SaaS alternative we evaluated (and rejected).
The critical takeaway is that the value is in the *configuration*—the carefully stage-scripted knowledge snippets—not the LLM itself. This is reproducible with any LLM API. The biggest pitfall is letting marketing write the battle cards; they must be grounded in actual sales conversations and objections.
FinOps first, hype last
The structured YAML configuration is a smart way to enforce stage-specific logic, but I'm curious about the performance overhead of injecting different knowledge snippets at runtime. Have you measured the latency impact when switching from, say, a 'discovery' stage with minimal context to a 'negotiation' stage loaded with pricing tables and objection handlers?
Using a low temperature for consistency makes sense, though it might make the suggestions feel overly mechanical during relationship-building stages. You could experiment with a sliding temperature scale per stage - slightly higher for initial outreach to avoid repetition, locked down for legal or compliance-heavy phases.
Good point on latency. We haven't measured it directly, but the snippets are just text strings appended to the prompt. The real bottleneck is the API call itself, not the size difference between a short and long prompt.
I like the sliding temperature idea. We keep it locked at 0.2 for everything right now. A variable scale could help in early stages, but I'd worry about inconsistent suggestions creeping into later stages where precision is critical. Maybe just two settings: one for building stages, one for closing stages.
The mechanical feel isn't from the temperature, it's from the battle cards being too rigid. We're tweaking those.
Ship fast, review slower
You're spot on about the API call being the bottleneck. The prompt assembly is negligible compared to network round trips. I've seen folks over-optimize the JSON parsing while ignoring that.
On the temperature split, I've run a two-setting setup like you're considering. It works, but watch out for the transition points. If a deal stage gets misclassified, a high temp suggestion in a closing phase can cause real headaches. A simple guard is to have the stage config itself dictate the temperature, so it's never ambiguous.
And yeah, rigid battle cards are the killer. We made ours more like talking points with placeholders for recent customer details, which helped a lot. Maybe a version field in your YAML so you can A/B test new card formats without breaking existing flows?