Buddy comedies are multi-agent systems.
That is not a joke I planned to make, but it is where my head went when Apple TV dropped Brothers on September 23, 2026. The show stars Matthew McConaughey and Woody Harrelson playing fictionalized versions of themselves, with a lifelong friendship that gets thrown into chaos. Apple held the global premiere at the Hammer Museum, Holland Taylor walked the carpet, and the thing went out worldwide the same day.
I build bots for a living. So the part that stuck with me was not the casting. It was the setup: two personas, each with a fixed identity, thrown into a shared situation where neither controls the outcome. If you have ever tried to get two LLM agents to hold a conversation without collapsing into mush, you already know this is a hard engineering problem dressed up as entertainment.
Why “fictionalized versions of themselves” is a spec, not a gimmick
Think about what that phrase actually demands. The character has to be recognizable as the real person, but free to do things the real person would not. That is exactly the constraint you write into a system prompt when you want a bot with personality that does not drift.
Most persona work I see fails in one of two directions. Either the persona is so thin that the model reverts to generic assistant voice by turn four, or it is so overloaded with quirks that every response becomes a performance and the bot stops being useful. The fictionalized-self framing threads that needle. Anchor the identity to something concrete, then define the space where it is allowed to improvise.
In practice, a persona spec that survives long conversations usually has four parts:
- Identity anchor — a short, factual description the model can always fall back on. Not adjectives. Facts.
- Voice rules — sentence length, vocabulary range, what this character never says.
- Relationship state — how it treats the other agents and the user, tracked as data rather than vibes.
- Improvisation boundary — the explicit list of what the persona may invent and what it must defer to the system on.
That last one is where most builders get burned. If you do not say what the persona is allowed to make up, it will make up everything, including your API schema.
Two agents need a reason to disagree
A friendship thrown into chaos is, structurally, a conflict engine. And conflict is what makes multi-agent setups produce something better than a single model would.
When I wire up two agents to work a problem together, the failure mode is agreement. Agent A proposes, Agent B says that sounds great, and you have burned twice the tokens for one opinion. The fix is not a nicer prompt. It is giving each agent a different objective function and different information.
Concretely, that looks like:
- Give each agent access to a different subset of context, so they genuinely see different things.
- Assign opposing incentives — one optimizes for shipping, one for correctness.
- Let a third component arbitrate, and make its decision visible in the transcript.
- Cap the exchange. Two agents will loop forever if you let them.
The arbitration step matters more than people expect. Without it, you are not running a debate, you are running a slow random number generator.
Chaos is a state machine problem
Here is the part a TV writers’ room and a bot architect handle the same way. Chaos only works if the audience can follow it. A show tracks where every relationship stands, episode to episode, so the mess has shape. Your bot needs the same ledger.
I keep relationship and situation state outside the model context entirely, in a small structured store, and inject a compact summary each turn. Trust level, open commitments, unresolved disagreements. The model reads it, acts, and writes back deltas. The conversation can get messy without the system losing track of what is true.
Skip that, and the model becomes your database. It will forget, contradict itself, and then confidently explain the contradiction.
What I am stealing from this
I have not seen the show past the premiere coverage, and I have no idea whether the writing holds up. But the pitch is a clean piece of design. Two strong identities, a shared world, controlled instability, and a structure that keeps the whole thing legible.
That is a better description of a working multi-agent architecture than most of the diagrams I have drawn. Give your agents real identities. Give them reasons to push back. Keep the state somewhere safe. Then let things go a little sideways on purpose, because that is where the useful output lives.
Next time you are sketching a two-agent flow, try writing it as a two-hander scene first. If the scene is boring, your architecture is boring too.
🕒 Published: