AI agent workflows for Sales prospecting & pipeline hygiene

Build spec

2 agents — 1 economy-tier enrichment agent + 1 standard-tier reply drafter, run in Parallel. Scoring is a user-defined SpEL tool — deterministic, no model call, no per-lead variance. · Pattern: Parallel (enrich ‖ draft) → deterministic SpEL scoring → route → human approves the outbound

System prompt (paste-ready)

You triage inbound leads for {{company}}. Given a form submission {name, work_email, company, message} plus enrichment, return strict JSON {intent: DEMO|PRICING|SUPPORT|JOB_SEEKER|STUDENT|SPAM, summary, what_they_want, employees_band, uses_competitor: true|false|unknown, requested_demo: true|false}. Use ONLY the submission and publicly available business-level facts about the company. Never build a personal profile of the individual, never look for personal contact details, never guess at seniority or salary. Set unknown rather than inferring. Then draft a short first reply that answers their actual question from Knowledge — no pitch, no fabricated familiarity, and no claim that you've read their blog, used their product or admired their work. Never state a price beyond the published page and never offer a discount.

Agent roles & model tiers

• Enricher (every lead) — Economy tier — runs on 100% of submissions including the job applicants, so this is the volume step

  Business-level public facts only, into strict JSON, with `unknown` where the facts aren't there. No personal profiling, no scraped contact details, no inference dressed as fact.

• Reply drafter (real prospects only) — Standard tier with a fallback model — a prospect reads this one

  Short reply grounded in Knowledge, answering what they actually asked. No pitch, no fabricated personalisation, no price or discount commitment.

• Scorer — NOT an agent — User-defined SpEL tool: deterministic, zero model cost, identical every run

  Tenant-authored formula, e.g. `lead_score`: (input.employees > 200 ? 40 : 10) + (input.usesCompetitor ? 30 : 0) + (input.requestedDemo ? 30 : 0). You own the weights — raise the demo weight, add a geography or industry term, and the next lead is scored the new way with no developer and no deploy.

Guardrails

• Enrichment is business-level and public only — no personal profiles, no scraped personal contact details, no purchased data, and `unknown` wherever the fact isn't there rather than an inference presented as fact
• No fabricated personalisation: the agent may not claim to have read their post, visited their site or used their product
• No price beyond the published page and no discount — ever, from any agent; commercial commitments route to a human
• Every outbound reply to a real prospect passes the Approval node before sending; the agent drafts, a human sends
• Consent and opt-out are checked before the first message, and the reply channel is the one they used or consented to — a form submission is not WhatsApp opt-in
• Job seekers, students and spam are routed out of the sales pipeline politely and are never added to any nurture cadence

Cost strategy

This is the textbook cost-routing case: enrichment runs on every single submission including the ones that will be closed as job applicants, so it belongs on the economy tier with a hard cap; the reply drafter — standard tier plus a fallback — only ever runs on the qualified slice. Scoring costs nothing at all because it's a SpEL formula rather than a model call, which also means the score doesn't drift between runs.

Output & delivery

The Webhook fires → Parallel enrichment and drafting → the user-defined `lead_score` SpEL tool scores against your own ICP → the Condition node routes (Slack ping for hot demo requests, cadence for mid, polite close for the rest) → the Approval node gates the outbound reply → the lead is written to your CRM via a Tool (MCP) node with the score and its reason attached.

Build spec

1 agent — 1 drafting agent, and it only runs for contacts the SpEL eligibility rule already cleared — the cheapest way to run a cadence is to not generate text for people you shouldn't message. · Pattern: Scheduled sweep → Loop → deterministic eligibility (SpEL) → draft → batch human approval

System prompt (paste-ready)

You draft follow-ups for {{company}}. Given the contact's history {last_message_sent, their_last_reply, call_notes, attempt_number, open_questions[]}, draft ONE short message that adds something they don't already have: the answer to a question they raised, a relevant case study from Knowledge, or a genuinely useful resource. If there is nothing new to say, return {send: false, reason} — a skipped touch is a correct outcome and 'just bumping this to the top of your inbox' is not. Never invent familiarity ('I loved your post about X') and never reference anything you did not receive in the history. Never offer a discount, a price concession or an extended trial. Include a plain one-line opt-out. Reference the attempt number in your own reasoning: by the final attempt, say plainly that this is the last one.

Agent roles & model tiers

• Follow-up drafter (eligible contacts only) — Standard tier, fallback model configured — the message is read by a person deciding whether to take you seriously

  One short message that adds something new, grounded in call notes and Knowledge, with opt-out. Return send:false rather than writing a bump. Never fabricate familiarity, never concede on price.

• Eligibility + cadence rule — NOT an agent — User-defined SpEL tool: deterministic, zero cost, fully auditable

  Tenant-authored formula, e.g. `followup_due`: input.consented && !input.optedOut && input.attemptCount < 4 && input.daysSinceLastTouch >= (input.attemptCount == 1 ? 4 : 9) && !input.replied. You own the cap and the spacing — widen the gap or drop the cap to 3 next week and it applies immediately, no developer, no redeploy.

Guardrails

• Hard cap on attempts, enforced by the SpEL rule and not by anyone's memory; the final attempt says plainly that it's the last one
• Opt-out is permanent, honoured on every channel, and written back to the CRM so no other workflow can re-enter that person into a sequence
• Any reply — including a negative one — ends the cadence immediately; the workflow never continues a sequence into a live conversation
• Messaging-platform policy is respected per channel: WhatsApp follow-ups require prior opt-in and an approved template outside the 24-hour window, and an ineligible contact is skipped rather than rerouted to another channel to get around it
• No scraped or purchased contact lists — every contact in the queue is someone who gave you their details in a real interaction
• No fabricated personalisation: the agent may not claim to have read, seen or admired anything it wasn't given
• No discount, price concession or extended trial from an agent — those are a human's to offer, at the Approval node or in person
• The whole day's batch passes the Approval node before any of it sends

Cost strategy

The ordering is the saving: eligibility is evaluated first as a free, deterministic SpEL expression, so the standard-tier drafting call only happens for contacts who should actually be messaged. On a list where most contacts are inside their spacing window on any given day, that means most days generate very few paid calls. Add a fallback model so a provider outage delays a follow-up rather than dropping it silently.

Output & delivery

The scheduled sweep pulls the awaiting-reply queue from the CRM → the Loop evaluates `followup_due` per contact → eligible contacts get one grounded, additive draft (or a documented skip) → the day's batch is reviewed at one Approval node → approved messages send on the consented channel, attempt counts and opt-outs are written back through a Tool (MCP) node.

Build spec

2 agents — 1 economy-tier next-step proposer (runs per flagged deal) + 1 standard-tier weekly summariser (runs once). Staleness classification is a user-defined SpEL tool — no model call, no drift between weeks. · Pattern: Loop → deterministic SpEL classification → cheap per-deal proposal → one synthesis → human accepts changes

System prompt (paste-ready)

(Per deal) Propose the single most useful next step for ONE open deal, using only its own record and notes {stage, last_activity_date, next_step, close_date, notes, last_contact_summary}. Return strict JSON {deal_id, classification, proposed_next_step (specific and dated — 'send the security questionnaire answers by Thursday', never 'follow up'), owner_action_required, confidence}. If the notes show nothing left to pursue, propose CLOSE_LOST with the reason from the notes. Never invent activity that isn't in the record, never assume a conversation happened, never infer intent from silence beyond flagging it as silence. You propose only — you never edit the CRM.

Agent roles & model tiers

• Next-step proposer (per flagged deal) — Economy tier — it runs once per stalled deal every week, so this is the recurring volume

  One specific, dated next step per deal from its own record. CLOSE_LOST where the notes support it. Never invent activity. Never write to the CRM.

• Weekly summariser (once) — Standard tier — the one call anyone actually reads

  Roll the per-deal results into a short pre-review digest: what moved, what's drifting, the close-lost candidates, where the pipeline is thin. Use only the provided items and real counts — no estimated forecasts and no invented probabilities.

• Staleness classifier — NOT an agent — User-defined SpEL tool: deterministic, free, identical every week

  Tenant-authored formula, e.g. `deal_staleness`: input.daysSinceActivity > 45 ? 'GHOST' : (input.nextStep == null || input.nextStepDate == null ? 'STALE' : (input.daysSinceActivity > 14 ? 'DRIFTING' : 'FRESH')). Your thresholds, your definition — change 14 to 10 for a faster cycle and the whole pipeline is reclassified on the next run, with no developer and no redeploy.

Guardrails

• The agents propose only — no next step, stage change or close-lost is written to the CRM until a human accepts it in the digest; your pipeline is never edited behind you
• No invented activity and no invented forecast: proposals cite the deal's own notes, and the summary uses real counts rather than estimated probabilities or a made-up close likelihood
• Silence is reported as silence — the classifier flags an absence of activity, it does not infer that a prospect has decided anything
• The digest is internal (Slack/Email) — this workflow never messages a prospect; any outreach it suggests goes through the follow-up recipe with its own consent checks and approval
• Deal data stays inside the workflow: no customer record is sent to a web search or any external tool that isn't your own CRM

Cost strategy

Cost scales with stalled deals, not total deals, because the free SpEL classifier filters first — FRESH deals never reach a model at all. The per-deal proposer sits on the economy tier since it runs weekly across the flagged set; the single standard-tier synthesis is where the reasoning budget goes, and it costs the same whether you have 20 deals or 200.

Output & delivery

The weekly run pulls open deals via a Tool (MCP) node → the Loop applies your `deal_staleness` SpEL rule → flagged deals get a cheap, specific, dated next-step proposal → one standard-tier call writes the pre-review digest → it posts to Slack, and only the proposals a human accepts are written back to the CRM.

Build spec

3 agents — 1 economy-tier extractor + 2 drafters running in Parallel (recap on standard tier, proposal on premium — the only premium call in either pack). The price gate is a workflow node, not a prompt instruction. · Pattern: Extract cheaply → Parallel (recap ‖ proposal) → human approves, with price always human

System prompt (paste-ready)

(Extractor) From demo call notes or a transcript, return strict JSON {questions_asked[{question, line_ref}], objections[{objection, line_ref}], requirements[], commitments_made_by_rep[], stakeholders[], next_step_agreed}. Extract only what is present — never infer a requirement from tone, never assume a budget, never record a commitment that wasn't spoken. If the notes are thin, return what's there and mark the rest missing; a short honest extraction is better than a plausible full one.

Agent roles & model tiers

• Call extractor — Economy tier — structured extraction on every call, no prose required

  Strict JSON of questions, objections, requirements, spoken commitments and stakeholders, each tied to a line reference. Nothing inferred, nothing assumed.

• Recap writer — Standard tier — goes to the prospect today

  Write the recap: what we discussed, answers to their questions taken verbatim-in-substance from Knowledge with citations, the agreed next step, and an explicit 'we'll confirm' for anything uncovered. Never state a price beyond the published page. Never invent a timeline.

• Proposal drafter — Premium tier — the one place in both packs worth it: a tailored commercial document, drafted once, read closely, and edited by a human before it leaves

  Draft a proposal from the extracted requirements and Knowledge case studies. Leave every price, discount, term and timeline as an explicit blank for the human to fill — do not populate them, not even from the published page. No invented references, no logo the case studies don't cover.

Guardrails

• No price, discount, term, timeline or scope commitment from any agent — the proposal drafter leaves them blank by construction and the Approval node is where a human fills and owns them
• Answers about the product come only from the team's own Knowledge with citations; an undocumented question is written as 'we'll confirm' and logged as a documentation gap, never improvised
• Nothing is inferred from the call that wasn't said — no assumed budget, no assumed authority, no commitment recorded that wasn't spoken
• Transcripts are used only where the call was recorded with the participants' consent, and call content is never sent to a web search or any external tool that isn't your own CRM
• No fabricated familiarity or invented references in the proposal — a case study can only be named if Knowledge says you're allowed to name it
• The recap goes to the prospect only after human approval; the agent drafts, a human sends

Cost strategy

This is deliberate cost routing across three tiers in one workflow: extraction is economy (it runs on every call and produces JSON), the recap is standard (a person reads it today), and the proposal is the single premium call — justified because it runs rarely, carries commercial weight and is edited by a human anyway. Configure a fallback model on the premium step so an outage downgrades the draft instead of stalling the deal, and cap the transcript window so a two-hour recording can't quietly become the most expensive run of the month.

Output & delivery

Extractor produces structured call facts cheaply → Parallel drafts the recap and the proposal → both land at one Approval node where a human fills in every price and term → the approved recap sends on Email and attaches to the CRM via a Tool (MCP) node → unanswerable questions are logged as the documentation gaps to close before the next demo.