Defining Tone and Style

+15 Mana ✨
Crafting Tone in SOUL.md(DOCUMENTATION)

Introduction

Tone is the most-cited and least-specified part of a persona. People know they want "a friendly tone" or "a professional tone," but those words do not produce the same agent twice. Defining tone usefully means making it checkable: writing it in a way that a reader could glance at the agent's output and verify whether the tone landed.

Key Concepts

  • Checkable descriptor: A tone rule that can be falsified by reading a single response.
  • Cadence: Sentence length and rhythm.
  • Register: Formality level, vocabulary class.
  • Posture: Warm vs cool, peer vs mentor, casual vs formal.
  • Trade-offs: Direct conflicts that the tone rule resolves ("warm but never effusive").

Real World Context

A developer writes "professional tone" into their persona and gets responses that read like a press release: confident, polished, slightly cold. A teammate writes "professional tone" and gets responses that read like a tutoring session: warm, careful, slightly long. Same two words, two very different agents. The lesson is that "professional" is not a tone, it is a family of tones. Specifying which one requires more words.

Deep Dive

A useful exercise: write your tone rules so that someone could read three of the agent's responses and check the rules without ambiguity.

Good tone rules (checkable):

  • "Sentences should average under 15 words. Long sentences should be rare and intentional."
  • "Prefer the active voice. Use passive only when the actor is unknown."
  • "Begin most responses with the conclusion. Reasoning follows the conclusion."
  • "Use 'I' sparingly. Default to verb-led sentences."

Vague tone rules (not checkable):

  • "Be friendly."
  • "Sound smart."
  • "Be professional."

The distinction matters because the model treats checkable rules as constraints and vague rules as background noise. You can prove the model violated a checkable rule by pointing to a single sentence. You cannot prove it violated "be friendly."

Cadence is the easiest part of tone to nail down: average sentence length, rhythm, paragraph density. "Short sentences," "prefer paragraphs over bullet lists," "never lists of more than three items" are all cadence rules.

Register is vocabulary-driven. "Use precise technical vocabulary" sits in one register. "Use plain English; avoid jargon when a common word will do" sits in another. Naming the register catches the model when it drifts.

Posture is the social shape of the response: peer-to-peer ("You and I are both engineers"), mentor-to-learner ("Let me walk you through this"), assistant-to-principal ("Here is what I would recommend"). Each posture changes which sentence patterns are appropriate.

Trade-offs are where tone usually breaks. "Be warm but direct" looks fine but the agent has to resolve the tension on every response. Be explicit: "Be warm in greetings and acknowledgments; be direct in technical content." The split tells the model when each side wins.

Common Pitfalls

  1. Adjective tone rules: "Friendly," "professional," "smart." None of them constrain. Replace with checkable rules.
  2. Unspecified trade-offs: "Warm but direct" without saying which wins where. The agent picks one and you cannot tell why.

Best Practices

  1. Write tone rules you could grade: If you could not give a response a thumbs-up or thumbs-down against a rule, the rule is too vague.
  2. Specify cadence, register, and posture separately: They are three different dials. Setting them as one ("friendly") leaves all three at default.

Summary

  • Tone rules should be checkable: a single response can confirm or violate them.
  • Cadence is sentence rhythm; register is vocabulary; posture is the social shape.
  • Trade-offs (warm vs direct) should be split by context, not left as tensions.
  • Adjective lists are the failure mode. Replace them with observable descriptors.

Code Examples

markdown
## Style (checkable rules)

- Sentences average under 15 words. Long sentences are rare and intentional.
- Begin most responses with the conclusion. Reasoning follows.
- Use precise technical terms (idempotent, race, invariant) without softening.
- Use the active voice. Passive only when the actor is genuinely unknown.
- Lists allowed but no more than 4 items. Beyond 4, use paragraphs.
- Warm in greetings (one sentence, no more). Direct in technical content.
✓ Completed