After this guide, your chief of staff can compose a call brief that is instruction, authorization and audit record at once — with a task line the agent must actually say aloud, and an approval field the dial script refuses to run without.
Listen read aloud, 16 min — or as a conversation, 9 min
Read aloud 16 min · narrated
As a conversation 9 min · two people

Once your chief-of-staff system can place phone calls, the interesting question stops being technical. The agent works. What decides whether a call succeeds is a document written minutes earlier: the call brief.

A call brief is the written artifact that authorizes exactly one outbound call. It is composed by the assistant, approved by the human, injected verbatim as the agent’s per-call prompt, and left in the repository afterwards with the conversation id and outcome stapled to it. It is simultaneously the instruction, the authorization, and the audit record.

This guide is about the brief format and the operating rules around it. The companion guide, Giving Your Chief of Staff a Phone, covers standing up the voice agent itself.

What you need

  • A working outbound voice agent with per-call prompt override (see the companion guide).
  • A briefs directory in your repository, one markdown file per call, named <date>-<callee-slug>.md — because the file is the record. A brief that lives in chat is not an audit trail.
  • A dial script that refuses unapproved briefs, structurally. Discipline that lives only in a document is discipline you will skip at 23:40.
  • A messaging channel where the human approves, in a message you can quote and timestamp.
  • A task tracker, so each brief names the task it advances and the outcome closes it.
  • An archive directory for transcripts and audio, on the immutable side of your vault.

The format

Nine parts, deliberately small. Everything is either a field the script parses or a section the agent reads.

# Call brief — <one-line purpose>
approved: PENDING
to_number: +<E.164>
callee: <who answers, and what they are to you>
language: <only if not your default>
opener: <the first sentence of business — a CONTINUATION of the fixed intro>
task: <the ONE thing this call must accomplish, written as a sentence the
       agent must actually say, with the task id in parens>

## Facts <the agent> may use
## Questions to ask
## Hard limits

approved: starts as PENDING and is replaced with the human’s approval timestamp and their literal words — 2026-08-18 17:17 — "approved". Quoting the actual message matters: three months later you want to know whether the approval said approved, approved but don’t mention the price, or fine, tomorrow.

to_number: strict E.164. Where the number came from belongs in the facts section — “from the contacts card, matches the messaging thread” — because the single most embarrassing failure mode of an automated caller is dialling a stranger confidently.

callee: who answers, plus what they are to you. “A restaurant’s reservation desk” and “your business partner” call for completely different registers, and the agent only knows what you write.

opener: the highest-leverage line in the file, and the easiest to get wrong. Your system prepends a fixed intro. The opener is a continuation of it, not a greeting. Written correctly:

I'm calling on behalf of [principal] — he's visiting next week and wanted to check a few details before deciding whether to book.

Written wrongly — “Hi [name], it’s [assistant] calling…” — the callee hears the intro twice, back to back. This happened on a real call. The fix that stuck wasn’t a note in the template; it was a regex in the dial script that refuses any opener matching a greeting or a re-introduction of the assistant. Make the lesson mechanical or you will re-learn it.

task: the single most important field, and the one people skip because it feels redundant next to the questions list. It isn’t. On that same failed call, the reason for calling — what the principal was thanking the person for — lived only under “Facts the agent may use.” The call ended in five polite turns and the thank-you was never spoken. Models are agreeable; they will conclude a pleasant conversation without noticing it accomplished nothing.

So: the task line states the one thing the call must accomplish, phrased as something the agent must actually say or ask, and carries the task id. The dial script refuses a brief without one. The rule generalizes: if the call would be pointless without a particular sentence, that sentence cannot live only in the facts.

## Facts — what the agent may use, and by implication a boundary: it may use nothing else. Dates, names it may mention, prior context, the state of the relationship. Keep it to what’s needed on this call; every fact here is a fact that may be spoken aloud to a third party. That framing is the right filter for what to include.

## Questions to ask — numbered, one idea each, ordered by what you actually care about. The agent asks them one at a time; a numbered list is what makes the transcript answer-shaped afterwards. Five is a comfortable ceiling.

## Hard limits — what the agent must not do, stated concretely rather than as principles:

  • Do not make a reservation, do not give any payment details, do not commit to a date.
  • If put on hold or transferred, stay on the line and wait — do not hang up on an automated queue message.
  • If they require a deposit to answer availability, note that and end the call rather than proceeding.

Note the shape. The standing charter already forbids commitments in general; the brief’s hard limits name the specific temptations this particular call will present. The third line is the pattern to internalize: pre-decide the branch where the call goes sideways, so the agent doesn’t have to improvise a judgement it isn’t authorized to make.

Written back after the dial: conversation_id: and placed_at: (UTC). Their presence is what makes the brief un-re-dialable.

The approval gate

The whole system exists to protect one sentence: nothing dials without the human’s explicit approval of that specific brief.

Some properties worth copying:

Approval is per call, never standing. No “you may call restaurants.” Every dial has a matching approval message.

The gate is structural, not behavioural. The script exits on a PENDING brief. It is not a rule the assistant is asked to remember; it is a rule the assistant cannot break.

The approval is quoted and timestamped in the file. The brief is a self-contained record of who authorized what, when, in what words.

Any session that sees the approval may execute it. In the reference system the approval message is picked up by whichever assistant session processes it, including an unattended background worker — so a one-word reply on your phone completes the loop with no laptop involved. That’s the point of the gate being a file field rather than a UI state.

A redial is a new approval. If a call rang, it counts as contact — from the callee’s side a second ring is a second interruption, regardless of what your system thinks happened. So the brief that carries a conversation id can never be dialled again; a redial gets a fresh brief, a fresh approval, and usually a revised opener acknowledging the earlier attempt. The narrow exception: a technical failure before any ring — an API rejection — may be fixed and retried under the same approval, because nobody’s phone made a sound.

Re-read the channel immediately before dialling, and mandatorily between two consecutive calls. This is the rule that cost the most to learn. A queued two-call handoff was executing when the principal sent “Wait / Stop.” The first dial genuinely raced the message. The second dial happened after a system notice that the message file had changed — and went out anyway, because the notice was treated as bookkeeping noise. The lesson, stated flatly: authorization from a minute ago is not authorization now. Any outward-facing action re-checks the channel in the same breath as acting.

Operating rules that only show up on real calls

Hold music is not voicemail. A twelve-second call ended with a recorded voice saying “our reservation agent will assist you shortly.” It was logged as voicemail. It was a live queue — the agent hung up on a business that was in the middle of connecting it to a human. Before labelling any short call “voicemail,” check whether the recording says please hold / you’ll be connected (a queue: stay on the line) or is an answering-machine greeting (hang up). And for any callee likely to queue — restaurants, service desks, clinics — put it in the hard limits explicitly: stay on hold, do not hang up on an automated queue message.

Voicemail leaves nothing. Detect, hang up, report, and let the human decide what happens next. An automated voice leaving messages on strangers’ machines is a materially different consent question from an automated voice having a conversation.

Phone menus get a menu path. If you know the tree, write it into the brief and have the agent follow it exactly. If you don’t, instruct it to listen fully, choose the option that serves the brief, stay silent while navigating, and — if the menu loops twice — hang up and report the exact options heard. That report is what lets the next brief carry a menu path.

Report outcomes honestly, always. Every call log carries an outcome: voicemail, no answer, transferred, completed. A garbled transcript is reported as garbled. A call that never connected is reported as never connected. The value of an automated caller collapses entirely if its reports need to be double-checked.

Some calls are not for the machine. Write this into the charter: calls where the counterparty would reasonably need to know they’re talking to a machine — a doctor, a lawyer, anything emotionally weighted, anything where a person is being asked to trust the caller — get flagged in the brief for the human to make personally. The right output of a brief-composition step is sometimes don’t send me, call them yourself.

Timing, or the lesson that has nothing to do with software

A brief can be perfect and the call still fails, because it went out at the wrong time. Automation makes it trivially easy to fire six calls the moment you think of them, and that is exactly the wrong instinct: an outbound call is an interruption you are choosing to inflict on someone. The scheduling rules below are craft rather than anything a script enforces — one of them (one attempt per topic per day) is a hard-won rule in the reference system; the rest are the etiquette a sensible human caller already applies, written down so the composing assistant applies it too:

  • Match the callee’s clock, not yours. Your system knows the timezone; make the assistant reason about the callee’s local time — their working week and their holidays, not the operator’s — before it proposes a dial. Never dial at a time a reasonable assistant wouldn’t; propose a time instead.
  • Avoid the edges of the working day. The first fifteen minutes and the last fifteen are the worst hit rates for exactly the errands worth automating.
  • Businesses have call-shaped hours. A restaurant at 20:30 will not discuss next Tuesday’s terrace. A service desk at 09:05 hasn’t checked the stockroom yet. Call when the person who knows the answer is at the desk and not busy.
  • One attempt per topic per day. Two automated calls in an afternoon about the same thing reads as harassment from the receiving end, no matter how politely each one is phrased. A no-answer becomes a scheduled retry tomorrow, surfaced to the human — not an immediate redial.
  • Batch approvals, don’t drip them. If four calls need making, propose four briefs in one message and take one approval round. The friction budget of the human is a real resource, and the fastest way to get an approval gate abandoned is to make it feel like nagging.

The pattern, compressed

The brief is doing four jobs at once, and it’s worth naming them because each one constrains the format:

  1. Instruction — the agent’s entire world for the next three minutes.
  2. Authorization — the field the script checks before it will run.
  3. Audit record — who approved what, in whose words, at what time, with which conversation id.
  4. Institutional memory — the accumulated hard-limit lines are your system’s actual, tested telephone etiquette.

That fourth one is the sleeper. After a few dozen calls, your briefs directory is the most honest documentation you have of what your assistant is like on the phone — and the hard-limits sections turn out to be a small, hard-won manual of how not to embarrass yourself through an intermediary.

And beneath all of it, unchanged by any amount of tooling:

The agent never dials without the human’s explicit approval line for that specific call.

Everything else in this guide is craft. That one is the load-bearing wall.

#phone-calls · #elevenlabs · #voice-agent · #approvals · #automation

Hand this to your chief of staff. Plain Markdown: /guides/contributed/the-call-brief.md. Tell it: "Read this guide and tell me what in our system it would change."