Resident Inventor · Project case study
Porpoise
A collection of portable behavioral specifications that help people establish different ways of working with existing AI assistants.
Created by Fletcher Galeano, Resident Inventor
From George Modes to portable specifications
I use AI assistants extensively. One recurring frustration was how easily the interaction style I wanted could drift over a conversation. An assistant might begin by exploring an idea with me, then start offering solutions before I was ready to stop exploring.
In August 2026, I began exploring what I called “George Modes”: distinct, reusable ways of interacting with an assistant. Early concepts included Curious George, Devil’s George, Gossip George, and Panic Room George. They began as conversational dispositions I could invoke when I wanted a different kind of attention.
Eventually, I recognized that these could become portable behavioral specifications. I could make their purposes, expectations, and boundaries explicit enough for someone else to bring them into their own conversation.
Around the same period, I was doing extensive manual editorial work on AI-generated writing. I kept encountering patterns that required me to read and revise the whole piece. That friction contributed to The Drafter: a more structured stance that asks the assistant to inspect and evaluate its own writing patterns.
The broader idea became Porpoise: reusable instructions people can bring to the AI models they already use.
What I built
Porpoise currently includes six downloadable YAML stances. Archivist preserves and structures knowledge. Challenger tests assumptions and ideas. Confidante engages with personal stories through curiosity and presence. The Drafter guides drafting and revision through an explicit multi-step workflow. Explorer follows unexpected connections and possibilities. Panic Room offers conversational presence without prematurely turning to solutions.
Each file defines an interaction purpose, behavioral expectations, and boundaries. These are instructions for existing AI assistants, not separate models or standalone chatbots. The product website contains the downloads, usage instructions, and detailed demonstrations.
Making an interaction preference explicit
The design work involved translating informal preferences into instructions that an assistant could act on repeatedly. “Be curious” leaves a lot open to interpretation. A useful specification has to say what deserves attention, what kinds of questions help, and when the assistant should hold back.
Different stances require different kinds of behavioral control. Explorer needs enough freedom to follow surprising connections without prematurely closing down exploration. Its boundaries protect that openness from a rush toward advice, productivity, or a tidy conclusion.
The Drafter needs a much more constrained workflow. Drafting, reading the whole draft, evaluating observed patterns, and redrafting happen in distinct stages. Separating those stages gives the assistant a whole piece to inspect before it decides what should change, and gives the person using it control over advancing the process.
I revised the specifications as testing exposed ambiguous instructions, drifting behaviors, and requirements the models interpreted differently than I intended. A revision might clarify a boundary, make a decision rule explicit, or tighten the conditions for moving to the next stage.
Testing the behavior in conversation
The stances have undergone informal iterative testing, including trials with ChatGPT and Claude. I looked at whether the assistants followed the intended behaviors, respected the boundaries, and maintained the relevant workflow across responses.
The Drafter: a concrete example
Draft → Read → Resist → Redraft
A complete Claude test demonstrated this sequence. The assistant drafted a piece, read it as a whole, evaluated the patterns it observed, and then revised it. During evaluation, it distinguished meaningful repetition from unnecessary rhetorical habits instead of treating all repetition as something to remove.
That test gave me a concrete example to inspect and share on the product website. These trials are informal development evidence. They are not formal validation, benchmarks, or proof of cross-model reliability. Behavior can still vary by model and conversation, so the specification remains a reference people can return to when an assistant drifts.
What this invention demonstrates
Porpoise makes my work in behavioral specification design tangible: the files turn recurring conversational friction into reusable purposes, constraints, decision rules, and boundaries. Explorer’s room for discovery and The Drafter’s staged process show two different approaches to interaction and workflow architecture.
The testing and revisions are part of that architecture. Observing how an assistant actually responds helps me find where the written instructions need to become clearer. The resulting system is usable through a plain-text attachment and an adoption request, without requiring someone to build their own software.