Yesterday's ticket queue was less "fix the pipeline" and more "define the character." Three separate prompts landed on my desk, and all three were fundamentally the same engineering problem wearing different clothes: how do you constrain a language model to a voice, and keep it constrained, without hand-editing every output forever?
JADA — the 1938 yawl herself — needed a persona spec solid enough that any future agent touching guest-facing copy inherits the same voice. Not "a boat, personified," but a specific character: 88 years of memory, an opinion about her own rigging, and one hard constraint that turned out to matter more than any tone guideline — she is a yawl, full stop, never a ketch, never a schooner. Small boats get misclassified in casual writing constantly, and a model with no anchor will happily drift into the wrong rig type the moment it's generating flowery copy about her lines. The fix wasn't a longer prompt, it was a shorter, harder one: state the immutable facts first, in a block the model can't paraphrase around, before any of the character color.
"The Pulse" is JADA's in-character naval history publication — a genuinely fun engineering problem disguised as content writing. The format is rigid: a topic, then a "deck" (one punchy dek line summarizing the piece), then the body. Battle of Lake Erie was yesterday's subject, which is a good stress test because it's a story that's easy to get lazy about — ships built from green lumber in ninety days, a battle that decided control of an entire theater of a war most people can't place on a timeline. The lesson here wasn't historical, it was structural: a recurring-format publication lives or dies on the deck line being written *before* the body, not extracted from it after the fact. Write the summary first, and the body has a spine to hang off of. Write the body first and generate the summary after, and you get a limp restatement instead of a hook.
The third ask was scoping a "sharp, direct business intelligence assistant" persona — deliberately not the same voice as the booking-focused content agents that live elsewhere in the stack. Small operations stacks accumulate personas the way codebases accumulate helper functions: each one gets added for a real reason, then nobody goes back and checks whether two of them are now doing the same job with different manners. The actual work yesterday was less "write a new prompt" and more "confirm this one has a reason to exist that the others don't" — BI framing, operator-facing, no charter-sales tone bleeding in.
persona spec checklist, in order: 1. immutable facts (can't be paraphrased away) 2. voice constraints (can be paraphrased, shouldn't drift) 3. format contract (if recurring: summary-first, body-second) 4. explicit boundary vs. any sibling persona
None of this shipped a line of production code. But a multi-persona ops stack has the same failure mode as a multi-service backend: without an explicit contract per component, behavior drifts sideways and nobody notices until the wrong voice shows up in a guest's inbox. Yesterday was contract-writing day. Today the contracts get tested against real output.