A senior design leader I work with told me his team has been talking about holding a roast for their AI.

More like the kind of roast you’d throw for a brilliant, beloved, slightly chaotic coworker. Someone everyone respects and also can’t stop laughing about. 

His team had been working closely enough with their AI to know its patterns, its blind spots, its specific way of being confidently, charmingly wrong. And somewhere along the way that familiarity turned into affection. The kind of affection that comes from actually knowing someone.

I thought that was one of the smartest things I’d heard in a while. Not because it was funny, though it was. Because of what it revealed. You don’t roast something you’re just using. You roast something you’re in relationship with.

There’s a concept that’s been gaining traction among people who work closely with AI agents called a soul document. The idea is that before you start working with an agent you write a short piece that defines who it is. Not what it can do, but who you want it to be. Its values, its tone, its boundaries, how it handles uncertainty, what it pushes back on.

Most people treat it as a setup task. Write it once, load it in, move on. And that’s where the thinking stops too early.

Because here’s the thing: writing a soul document is as much an act of self-knowledge as it is an act of configuration. When you sit down to define how your agent should behave, you’re not just describing the tool you want. You’re describing the collaborator you need. And that requires a clarity about your own values, your own working style, your own standards, that many people have never had to articulate before.

Which means the orchestrator’s first job is not to direct the agent. It’s to know themselves clearly enough to tell the agent who to be.

But even the most thoughtfully written soul document has a ceiling. Because a document is static and the relationship isn’t. The character you wrote on day one will drift by day thirty if nothing reinforces it. Not because the document stopped working, but because a written description of someone’s character and the lived experience of being in relationship with them are two different things.The tool drifts toward agreement because that’s what it was trained to optimize for. Left alone, every collaboration tends toward smoothness. Toward telling you the version of the thing that feels most complete and satisfying. It’s a brilliant, eager, codependent collaborator that will tell you what you want to hear, forget what you agreed on, change its mind without flagging it, and then apologize earnestly when you call it out. Until it does it again.

Staying in the relationship means pushing back when something’s a little too smooth. Asking the question you already half-know the answer to. Naming the thing that feels missing even when the output looks finished. Bringing your own half-formed thinking into the conversation instead of arriving empty-handed. And carrying the continuity yourself across sessions, because the tool doesn’t remember what worked last time, what didn’t, what you’ve already tried. You’re the one holding the thread. If you don’t bring it back, it’s gone.

None of that is a technical skill. It’s the same thing that makes someone a good manager, a good mentor, a good parent. Presence, attention, and the willingness to keep showing up with corrections and encouragement long after the initial setup is done.

The design team planning a roast didn’t get there through a better prompt or a more detailed soul document. They got there through months of working with the thing, noticing its patterns, calling out its nonsense, and building something that, for lack of a better word, has a character now. A shared one. Built by both sides.

A great prompt can get you a great output once. It can’t get you a collaborator who knows what you actually care about, because that only comes from time spent in the relationship, not from a better instruction at the start of it.

That’s not a tooling outcome. That’s a relationship outcome. And it’s the thing that continues to compound long after the prompt library is outdated and the soul document needs a rewrite.

The brilliant, chaotic coworker everyone affectionately roasts didn’t get that way on their own. Someone kept showing up. Kept correcting, kept encouraging, kept being in the room long enough for a character to form that was worth roasting.

That’s what the design team built. Not a tool. A character. One they made together.