Routing Referral Drafts to a Cheaper Model Without Losing Voice

A single "write like this" style guide for an entire outbound team is too general to enforce. Break it into one card per shape, and keep each card under 120 words. The card does the work that a long prompt cannot: it fixes the decisions the small model is allowed to make, so it never has to improvise on tone.

Here is the format I use, with a worked card for the follow-up after a call:

SHAPE: Follow-up after a call
LENGTH: 90 to 130 words
OPEN: Reference one specific thing said on the call
ASK: Confirm the single next step the referrer agreed to
CLOSE: No pressure line, then thank you
BANNED: "just circling back", "quick question", apologies for existing
TONALITY: Peer to peer, no gratitude inflation
FACT RULES: Use only names, dates and roles listed in the brief

Three rules make style cards work in practice.

First, put the ban list in the card, not in the brief. Ban lists are stable across every draft of a shape, so they belong with the voice rules. The brief changes every time.

Second, state the fact rules explicitly. A small model will happily invent a detail to smooth a sentence. Tell it that names, dates and roles may only come from the brief.

Third, keep the tonality line concrete. "Warm but not obsequious" is not actionable. "No gratitude inflation" is, because a reviewer can check whether the draft thanks the person more than once.

The same discipline shows up in prompt guidance generally: the useful frameworks separate what you are delegating, how you describe it, and how you will judge the result Champlain College's prompt engineering session. A style card is the description step, written once per shape and reused.

Most referral drafts fail at the brief, not at the model. If you cannot state in two sentences why this job is a genuine fit, you are not ready to ask anyone to vouch for you Applyre's referral guide. The brief forces that clarity before a model touches the keyboard.

A two-line brief has exactly two jobs:

• Line one: the ask, the referrer, the relationship and the target role, in one sentence.
• Line two: the one specific reason this person can vouch for you, tied to something the referrer would recognize.

Worked example for a re-send:

ASK: Re-send my intro request to Dana (former colleague, Brightfield, 2021)
for the Staff PM role at Northwind. She already said yes last month.
REASON: We ran the Henderson account together, so she can speak to the
enterprise onboarding work the role is built around.

Now the same brief written badly, which is what produces a weak draft:

ASK: Follow up with Dana about the job.
REASON: I am a great fit and really want this.

The bad version leaves everything to the model: what the ask is, what the relationship is, what the role is, and why Dana specifically can speak to it. A strong model will paper over those gaps with plausible filler. A small model will produce something flat and slightly wrong. Neither outcome is the model's fault.

Keep the brief to two lines as a hard rule. Long briefs hide the missing judgment that should have triggered a route to the strong model. If your brief cannot be compressed to two lines, that is your signal to escalate.

You cannot set the routing line from vibes. You need a fixed set of past drafts with known quality, and you need two people to score them independently.

Pull 40 to 60 real referral drafts from your archive, spread across the shapes in the table above. Aim for at least 8 per shape so each route has enough cases to be judged. Include the mistakes. The drafts that went out flat, the ones that over-thanked, the ones where a fact was wrong: those are the cases that teach the router where the line sits.

For each draft, two raters score three dimensions on a 1 to 5 scale:

Scoring three dimensions separately matters because they fail differently. A draft can sound perfect and be factually wrong, which is the most dangerous outcome. Or it can be accurate and flat, which is merely wasteful. Accuracy is the hard gate; voice and ask clarity are quality floors that vary by shape.

Structure the eval the way production evaluators do: define the query classes from real traces, then score each class against its own acceptance threshold rather than one threshold for everything Braintrust's model routing guide. A post-call follow-up with an accuracy score of 3 is a failure. A first cold ask with a voice score of 3 might be acceptable if the ask clarity and accuracy hold.

Then run both models over the full set and compare. The decision rule I use:

• If the small model matches the strong model within half a point on accuracy and ask clarity for a shape, and voice is within one point, route that shape to the small model.
• If any single case in the shape drops below 4 on accuracy, keep the shape on the strong model and fix the brief.
• If voice drops by more than one point, split the card instead of abandoning the route.

That third rule is the one people skip. A voice regression usually means one style card is carrying two different shapes. Split it and re-run.

The routing layer itself is short. Classify the brief by shape, look up the route, and call the model. Start with static routing, which is the easiest to understand and evaluate before you consider anything adaptive the LLM routing guide.

ROUTES = {
    "resend_warm_intro": "small",
    "followup_after_call": "small",
    "factual_nudge": "small",
    "first_cold_ask": "strong",
    "slow_reply_apology": "strong",
    "rejection_ack": "strong",
    "woven_referrer_words": "strong",
}

def route(shape):
    return ROUTES[shape]

def draft(shape, brief, style_card):
    model = route(shape)
    return call_model(model, brief, style_card)

Add one thing to this: a quality check on the accepted output, so a cheap route can escalate when it fails. Cascade routing starts with the cheaper model and escalates when a check fails, which is different from fallback routing that only handles outages the LLM routing guide.

For referral drafts, the check can be mechanical. Confirm that every name, date and role in the output appears in the brief. If one does not, discard and escalate to the strong model. That single check catches the most damaging failure mode and costs nothing.

Log the chosen model with every draft, alongside the shape and the brief. Without that trace, you cannot tell later whether a weak draft was a bad brief, a bad card or a bad route.

Run the arithmetic on a realistic volume before you build anything. Suppose your team produces 2,000 referral drafts a month and 55 percent of them fall into the three small-model shapes, so 1,100 drafts go cheap. Assume an average brief plus card plus output of about 900 tokens per draft, roughly two thirds input and one third output.

Using published list prices for a flagship and its cheaper sibling, both read on the OpenAI API pricing page, the strong tier at $2.00 input and $10.00 output per million tokens costs about $4.20 per thousand drafts. The cheap tier at $0.10 input and $0.50 output per million costs about $0.23 per thousand, a difference of roughly $3.97 per thousand OpenAI API pricing.

At 1,100 drafts, the saving is about $4.37 per month. That is the number you need to see plainly: for a referral drafting workflow, model choice is not a meaningful cost lever. The savings are real but small, and they are far smaller than the cost of one draft that misstates a fact and damages a relationship.

This is why routing here is a quality discipline first and a cost play second. If your volume is thousands per day, the arithmetic changes and routing is worth the engineering. At referral volumes, the reason to route is that a small model, given a tight card and a two-line brief, produces better follow-ups than a strong model left to improvise against a vague brief.

Token pricing also depends on which bucket you are billed for: uncached input, cache writes, cache reads and output are separate line items, and retries are billable attempts the token pricing guide. Style cards are identical on every call for a given shape, so caching them as a stable prefix is the obvious optimization if volume grows OpenAI's prompt caching guide.

Small language models are not simply weaker versions of large ones. They are designed to hit high performance on specific, narrow tasks with far lower compute and latency, and they can lose accuracy on broad, open-ended queries Microsoft's SLM comparison. That is exactly the profile of a re-send or a factual nudge: narrow, bounded, verifiable.

The evidence from adjacent tasks is encouraging. In an automated program repair study, the best small models fixed up to 38 of 40 bugs against 39 of 40 for the best large model, and int8 quantization had a minimal effect on accuracy while cutting memory use the quantized SLM study. That is a task with a checkable right answer, which is the same property that makes factual referral nudges safe to route down.

Where they break is the other side of the same coin. Microsoft's comparison puts open-ended tasks and teaching a model a specific voice or tone on the large-model side Microsoft's SLM comparison. A first cold ask to a senior contact is open-ended in exactly that way: the whole job is calibrating tone to a thin relationship.

Practical rule: if the draft has a right answer a reviewer could check against the brief, a small model is a candidate. If the draft's success depends on a judgment nobody could verify by reading a fact list, keep it on the strong model.

The subtle risk in routing is that quality drops invisibly. A cheap follow-up that is 10 percent flatter than your usual voice still passes review, still gets sent, and slowly shifts how your team sounds to the people who refer you. Nobody files a complaint about a draft that was merely fine.

That is why the regression set has to stay alive rather than being a one-time exercise. Two defenses keep it honest.

First, re-score a rolling sample monthly. Pull 10 routed drafts per shape, have the same two raters score them blind against the original set, and compare. If voice drifts below the threshold you set, the card has drifted or the model has changed, and you need to know which.

Second, separate the brief from the card when you debug. A weak draft has three possible causes: missing judgment in the brief, which means the wrong route; a contradictory card, which means a too-broad shape; or a model regression. Checking the brief first settles the first two cases, which are the common ones.

One more discipline: keep a small slice of strong-model drafts flowing through the small model's shapes every month, unrevealed to the raters. If the raters prefer the strong model's version consistently, the route was premature. This costs you a fraction of a month's drafts and it is the only clean way to know the line has not moved.