I built two content agents for a sales team of a few thousand. What fixed them was letting one of them write less.
I’ve faced two types of issues in sales enablement: lack of content and overflow of content.
Lack typically came in early-stage startups, where product-market fit was still being defined, and sales enablement was often done on a case-by-case basis. You’d be writing against the clock, with very little time to think about what you wrote or see how the reader reacted.
The overflow is the grown-up version. I’m talking a full marketing function, from product to technical to content. This gave me a lot more time to think and repurpose content, so that we could think about competitive advantage and our own win themes.
It also meant a sales org measured in thousands of reps, dozens of different versions of the approved template, and clandestine versions that defied any brand guideline and carried their own idiosyncratic takes on product messaging.
This scenario is about the overflow.
Too many cooks spoilt the broth
Thousands of reps across markets meant hundreds of proposal versions, with little to no standards and often obsolete messaging.
Reps reused stale templates because finding the current version was more work than copying the old one. This only bred more versions, impossible to catch and adjust.
I figured that imposing a golden standard on an org that size would get no adoption. In B2B SaaS, each market has its own tradition of how business is done and what information matters.
Where I did want standards was underneath: an agent grounded in proposal best practices, our style guide, messaging docs, content marketing resources, and our Q&A library. Customization would happen within boundaries, so the sales team would get something ready to go that was still rooted in accurate product information.
But two cooks saved it
I built two agents: a drafter and a reviewer. Why two? Because drafting and reviewing are opposite jobs.
A drafter optimizes for producing something complete and plausible.
A reviewer optimizes for finding what’s wrong.
Ask one agent to do both in a single pass, and the critique inherits everything the draft already committed to. It would read its own output as correct because it just decided it was. What you get back is polite notes on its own choices.
Split in two, the reviewer only ever sees the artifact. It doesn’t get the reasoning that produced the draft; just the text and the rules. That’s the same position the customer is in, which is the position you want a critic in.
It also let me keep each one narrow. The drafter needs product facts, templates, and the Q&A library. The reviewer needs the style guide and a list of the ways sales enablement pieces usually go wrong: product naming, jargon, benefits that don’t say anything. Two small jobs beat one prompt trying to be good at everything.
The reviewer turned out to be the more useful of the two. Most sales enablement pieces in a sales org that size are written by humans; they don’t want a draft, but want to know if what they wrote is any good.
A reviewer only works on someone else’s text if it’s a standalone thing rather than the second half of a writing pipeline. And “an editor gave me notes” lands very differently with a rep than “the AI wrote your proposal.” They keep the authorship. I think that’s most of why people used it.
The reviewer runs on bad examples, not good ones
The reviewer was the harder one to write, and the thing that made it work was giving it failures rather than ideals.
“Write customer-focused content” means nothing to a model, the same way it means nothing to a sales rep at 6pm before a deadline.
So the reviewer’s rules are a catalogue of specific ways proposals go wrong, each with the bad version, why it fails, and the rewrite.
For example:
Bad: [Company] is the industry-leading, world-class provider of next-generation workforce solutions.
Why it fails: three unsupported claims in one sentence, no customer relevance, and nothing a competitor couldn’t copy word for word.
Good: [Company] helps organizations cut the administrative load of scheduling and payroll, with results independently verified across deployments of a similar size.
And:
Bad: The platform includes route optimization, live tracking, driver scoring, and automated reporting.
Why it fails: a shopping list. Four capabilities, zero consequences for the customer.
Good: Route optimization and live tracking reduce the hours dispatchers spend rebuilding schedules by hand, and give depot managers one view of where every vehicle is.
I’ve included dozens of these examples where the sales enablement material led with features, and was written in marketing language with nothing underneath it. Think product dumps that read like a catalogue, an endless list of acronyms, or the same benefit stated four times in a row with a different preposition.
You can import and define your own rules, with your style guide or previous content pieces as the best source of inspiration. Regardless of how specific you want to be; as a rule of thumb, reject any paragraph that could be reused verbatim for any customer. That test catches more bad proposal writing than every other rule combined, and it works on humans too.
Things started breaking down
Custom sales materials were the end goal of the agents, and they were where it went wrong.
The first attempts were thin. A configurable document, where sales fed in the deal stage and the customer’s hot buttons and goals, came back as one or two light paragraphs of marketing-speak that meant nothing. A good proposal needs storytelling, but sentences like “in today’s AI-paced world” don’t cut it. The scant custom blocks made more work, not less: reps couldn’t paste them as they were, and still had to go and find the rest.
So I pushed it further. I instructed the agents to read the opportunity, search for the account history, the customer’s own language. That fixed the thinness but introduced a worse problem.
It invented things.
Not wildly, which would have been easier to catch. It produced capabilities that sounded like ours, in our voice, positioned correctly, and slightly untrue.
A style reviewer doesn’t save you here. It can tell you a product name is wrong, that a claim has no proof attached, that a paragraph could be sent to anyone. It can’t tell you a capability doesn’t exist, because it reads the same sources the drafter does. Neither of them knows what isn’t in them.
Abstention, everyone!
What fixed the issue wasn’t better writing instructions, but giving the agent permission to produce less.
Most of what a model invents is invented to fill a gap it feels obliged to fill. Tell it the gap is an acceptable output and a good part of the problem goes away.
In the second iteration, I updated the agent so that before it generates anything, it has to identify a number of factors. In my case, it’s:
- customer’s objectives
- hot buttons
- challenges
- outcomes they want
- products in scope
- proof available
- differentiators relevant to the deal.
If one of these pieces of information is missing, the agent will ask you to provide it, and won’t move forward with creating the content piece.
That single constraint removed most of what was wrong with the old sales enablement pieces.
A rep copying last quarter’s document starts from a solution and works backwards. The agent can’t. Every major section has to run:
Customer objective → Customer challenge → Recommended solution → Customer benefit → Supporting proof → Expected outcome
and it isn’t allowed to jump from challenge to product description, which is the move almost every bad sales enablement piece makes.
So, the end result now is:
- Benefits before features.
- Every capability expressed as feature → benefit → business impact → proof.
- Claims as claim → evidence → customer impact, and if the proof doesn’t exist, the claim doesn’t get made.
- A differentiator counts only if it matters to this customer, supports a stated objective, and can be substantiated.
- Placeholders get marked as placeholders instead of filled with something plausible.
What that leaves you with
The customized drafts are now a working copy, not a finished sales enablement piece. This brings the balance between the standard information and the pockets of customization. The sales team can now open, check, adjust, and send, instead of a blank page or last quarter’s file.
The agent isn’t writing the proposal. It’s removing the part of the job where you stare at a template deciding what goes in which section. The hour that’s left goes to the part that needs a person. Is this true. Does it fit this customer. Is this the story we want to tell them.
The thing I didn’t expect is that the reviewer got more use than the drafter. Most proposals in an org that size are written by people, and those people don’t want a draft. They want to know whether what they wrote is any good, at 6pm, before they send it.
The drafter serves someone starting from nothing. The reviewer serves everyone else. And “an editor gave me notes” lands very differently with a rep than “the AI wrote your proposal.” They keep the authorship. I think that’s most of why people used it.
Worth saying: this only works in the too-much scenario. In the not-enough one there’s nothing to be strict about, and an agent told to abstain would hand you back a blank page.
The gaps are still there, marked, waiting for someone who knows the answer. That’s the point.
If you’re starting now
- Build the reviewer first if you only build one. More people need editing than drafting.
- Give it bad examples, not good ones. Specific failures with rewrites beat any amount of “be customer-focused.”
- Write the standard before you write the prompt. Both agents are only as good as the style guide, messaging docs, and Q&A library underneath them. They enforce standards; they don’t invent them.
- Make abstention an acceptable output, and say so explicitly. A marked gap is worth more than a plausible sentence.
