← Notes from the workbench

Designing prompts for outbound conversations

Outbound calls invert the usual agent contract: the agent wants something and the human didn't ask for the call. That changes how you write the prompt.

· 2 min read

Most prompt-engineering advice assumes an inbound world: a user shows up with intent, and the agent helps. Outbound flips the contract. The agent initiates, the human is mildly inconvenienced, and every sentence spends goodwill. Prompts that work beautifully for support bots fail on outbound calls, and the failure modes are predictable.

The three failure modes

The monologue. LLMs love to front-load context. On an outbound call, a 30-second opening paragraph gets you hung up on. The prompt has to enforce brutal brevity: one sentence of identity, one sentence of purpose, then stop and listen.

The pushover. Overcorrect for politeness and the agent abandons its goal the moment the human hesitates. A good outbound prompt separates goal persistence from social compliance: be flexible about path, inflexible about purpose, and know the difference between “not now” and “no”.

The improviser. Outbound calls usually exist for a business reason — scheduling, confirmation, collection of a specific datum. Leave the flow implicit and the model will happily follow the human into unrelated territory. Structure beats vibes: give the model an explicit state machine (greet → verify identity → state purpose → handle objection → close) and let it improvise the sentences, not the sequence.

What a working structure looks like

The outbound prompts that survived production contact all converged on the same skeleton:

  1. Identity and constraint block — who the agent is, what it may never do (quote prices, give medical advice, keep someone who asked to leave).
  2. A goal with an explicit fallback ladder — ideal outcome, acceptable outcome, and the graceful exit, so “failure” is still a designed path.
  3. Conversation states with entry and exit conditions — the state machine above, written as short imperative rules rather than prose.
  4. Objection handling as data, not instructions — a small table of common pushbacks and approved responses. Easier to review, easier to update, and it keeps legal happy.

Evaluate the transcript, not the feeling

The real unlock was treating every outbound conversation as an evaluable artifact. Structured checks over transcripts — did the agent verify identity before disclosing anything? did it respect a “stop calling” request? — catch regressions that no amount of prompt-reading will. The prompt is the hypothesis; the eval suite is the experiment.