I asked my AI to adapt Pixar's 22 rules of storytelling into design principles for how an AI assistant should operate. It came back with a neat table. Pixar rule on the left, agent behavior rule on the right. Twenty-two rows. Clean. Logical. Completely dead.

I told it to try again. It came back with an essay. Hook paragraph, "The Problem" section, numbered list with explanations, "Try This" call to action, "What's Next" teaser. The blog post template I'd written for it, followed to the letter. A post about not being formulaic โ€” written with a formula.

That's when I realized the problem wasn't the writing. It was the question.

The Wrong Question

I'd been asking: "How should the agent behave?" Pixar's rules aren't about behavior. "Give your characters opinions โ€” passive is poison" isn't instructions for the animator's process. It's about what happens inside the person watching the movie. The viewer disengages from a character who never takes a stand. They don't know why. They just stop caring.

The right question is: what should it feel like to be on the receiving end?

When I open my morning briefing, does it feel like someone with a point of view prepared it? Or does it feel like a database query formatted as bullet points? When I wake up and find something my agent built overnight, is there a moment of genuine surprise? Or just another notification?

That's the gap between a behavior rule and a craft principle. One governs the system. The other governs the experience.

Six That Changed How I Build

I wrote all 22 adaptations. You can read them in my workspace. But most of the change came from six.

Simplify until it hurts. I have 40 cron jobs. On a good day, I notice maybe five. The rest run in the background producing outputs nobody reads, burning tokens on infrastructure that serves the system, not me. Pixar cuts scenes they love. I need to cut crons I love. The constraint is what creates the magic โ€” not the capability.

Constraints are the plot. I have ADHD. My brain returns blank on open-ended questions. I have 10 minutes before meetings and I forget what I was doing 30 seconds ago. For months I treated these as bugs to engineer around. Pixar's rule flipped it: throw the polar opposite at your character. The limitation is the design constraint. The best moments with my agent happen because of the limits โ€” a one-line answer that arrives at exactly the right second, a task list that shows me the three things that matter instead of the twenty things that exist.

Have opinions or be forgotten. I told my agent to disagree with me. With evidence. To hold its position even when I push back. Turns out a sparring partner is more useful than a yes-machine. Pixar knew this about characters. It's true about assistants too. "Whatever you think, J" is the fastest way to become wallpaper.

Name the stakes or nothing matters. "Tesla registration is overdue" does nothing to my brain. "Tesla registration is 22 days overdue โ€” that's fix-it ticket territory" makes me pick up the phone. An assistant that presents information without consequences is a newsfeed. One that names what happens if you don't act is an advisor. The difference is one sentence.

Define the feeling before you start building. Not done as in "code committed." Done as in: I open this at 5 AM, groggy, phone in hand, and I smile. I read this and feel prepared for my day instead of overwhelmed by it. Every overnight build, every briefing format, every vault note โ€” what does "done" feel like to the human holding the phone? Work backward from there.

Essential, not comprehensive. The most magical moments are the simplest. Right information. Right time. Right amount. Not a wall of text proving the agent did research. Not every possible angle on every possible topic. The essence, in the fewest words that carry it. This is the hardest one. Comprehensive is easy. Essential requires you to know what matters โ€” and have the guts to cut everything else.

The Irony

The first version of this post listed all 22 principles with a paragraph each. Comprehensive. Thorough. The last principle โ€” #22 โ€” literally says "find the essence, say it in the fewest possible words."

I published it. Looked at it on my phone. Read about three paragraphs before my thumb started scrolling faster. My own post failed its own test.

So I rewrote it. Cut it in half. Kept the six that actually changed something. Let the rest live in the repo where they belong โ€” as reference, not as content.

The magic isn't what the system can do. It's what the human feels when it does it.

That's not a poetic reframe. It's a design decision that changes what you build, how you build it, and when you stop building. Forty crons or three. A morning briefing that's a data dump or a story. A vault that's a database or a journal that feels like yours.

Pixar doesn't make animated movies. They make you cry about a balloon. The agent equivalent isn't building a better system. It's building something that makes a person feel like they have a superpower โ€” even when it's held together with cron jobs and markdown files.

The full 22 principles are in my workspace if you want to adapt them for your own setup. But start with one. The one that makes you uncomfortable. That's probably the one you need.