Introduction

A misused persona is worse than no persona at all. It adds friction without adding value, often in ways that take a while to spot. This lesson catalogs the most common misuses so you can recognize them in your own setup and back out before they cost you a session.

Key Concepts

  • Tone mismatch: When the persona's voice fights the seriousness of the work.
  • Reader cost: The time and effort the reader spends parsing through persona-flavor before reaching the signal.
  • Stickiness: A persona set hours ago that no longer fits the current task.
  • Audience leakage: When output written under one persona lands in front of a different audience (a Slack post, a PR body, a doc).

Real World Context

A developer leaves their session on /personality pirate from a Friday afternoon joke. Monday morning, production alerts hit. The agent's first response begins "Ahoy! Looks like ye be havin' a 500 error on yer cargo ship..." The information is correct. The on-call engineer is now scanning past nautical idioms to find the actual root cause. Three minutes of triage become five. Pirate is funny once and costly the third time.

Deep Dive

Here are the most common misuses, in roughly the order they cost teams real time.

Expressive personas during incident response. pirate, shakespeare, kawaii, uwu: all charming, all wrong when an alert is paging. Incident triage values short, dense, neutral language. Expressive flavor obscures signal exactly when you cannot afford the latency. The fix: default to concise or helpful for any agent that participates in incident channels.

Concise during onboarding. A new hire pairs with the agent on their first day. The agent uses concise. The hire gets correct answers and zero scaffolding. Within an hour they are lost because nothing was explained. The fix: switch to teacher for any task with a learning component.

Pirate before a destructive command. Some teams disable confirmations because they trust the agent. With an Expressive persona, the confirmation prompt itself becomes ambiguous: "Aye matey, shall we be deletin' the database?" That phrasing makes a serious decision feel playful. The fix: switch back to Utility before any destructive operation.

Shakespeare for CI alert summaries. A nightly CI job pipes failure summaries through Hermes. Under shakespeare, the summaries become unreadable poetry. The on-call rotation cannot parse them at 3am. The fix: pipelines should use Utility or Professional personas, not Expressive ones.

Sticking with one persona all day. Even a perfectly chosen persona for the first task can be wrong for the fourth. Persona selection is per-task, not per-day. The fix: switch when the work changes.

Persona as proof of personality. Some users feel the agent is generic without an Expressive persona, so they pick creative permanently. The result is responses that take metaphors when they should take definitions. The fix: trust that Utility and Professional are appropriate for most work; reserve Expressive for tasks where mood is the point.

Common Pitfalls

  1. Outside-in selection: Picking the persona based on how you want the agent to feel, not on what the task needs.
  2. Forgetting to switch back: A temporary persona becoming permanent because you closed the laptop before the switch back.

Best Practices

  1. Default to Utility for ambiguous contexts: Logging, alerts, automated summaries, shared channels. Pick helpful or concise unless the task explicitly benefits from something else.
  2. Make persona change a habit, not a one-off: If your work changes shape three times a day, your persona should change three times a day.

Summary

  • Expressive personas hurt incident response and shared-output contexts.
  • Concise hurts onboarding and learning.
  • Pirate (or any Expressive) before destructive commands makes serious decisions feel playful.
  • Persona is per-task, not per-day. Switch when the work changes.

Code Examples

text
BAD: incident channel with persona left on pirate

  > /personality                 # still pirate from Friday
  > Why is the API returning 500s?
  < Ahoy! Looks like ye be havin' a database connection storm on the
    starboard side, captain. The pool be full of dead connections...

GOOD: switch back before the page hits production

  > /personality concise
  > Why is the API returning 500s?
  < Connection pool exhaustion. 47 dead connections in pg_stat_activity.
    Restart pgbouncer or kill idle-in-transaction sessions.
✓ Completed