You Shouldn't Have to Tell the AI Who to Be
Last week I wrote about typing "act as a senior architect" 47 times per week. The friction of manually assigning roles to an AI that should be able to figure it out.
This week I want to go deeper. Not the pitch -- the plumbing. How does signal-based routing actually work inside PRISM Forge? What does the routing engine look at? How does it decide?
And -- because build-in-public means showing the dents -- the 3 times it broke in ways I didn't expect.
The Core Idea: Intent Detection, Not Commands
Most persona systems work like menus. Pick a role from a list. Type a command. Toggle a mode.
Signal-based routing works differently. You talk naturally. The system listens for signals in your language and assembles the right team.
"I'm stuck on this auth bug" contains two signals: stuck (creative problem-solving) and bug (debugging/validation). The routing engine reads both, decides who leads, and who supports.
No slash commands. No mode toggles. No "act as."
Anatomy of the Routing Engine
PRISM Forge's routing engine has four layers that fire on every single message:
Layer 1: Hard Overrides
Three things bypass all logic:
- "War room" -- loads all 27 personas into active debate. Susie moderates.
- Explicit name -- "Winston, how should this be architected?" Always routes to the named persona.
- Mode switch -- system context changes (Plan mode, Agent mode) activate mode defaults.
These are cheap checks. If none fire, the engine moves to intent classification.
Layer 2: Intent Classification
Every message maps to one of 9 intent categories:
| Intent | What it means | Who typically leads |
|---|---|---|
| Build | Write code, create files | Amelia (Developer) |
| Investigate | Analyze, explore existing state | Mary (Analyst) |
| Plan | Structure work, break down tasks | Bob (Scrum Master) + John (PM) |
| Validate | Test, verify, review | Quinn (QA Engineer) |
| Create | Brainstorm, ideate, design | Carson (Brainstorm Coach) |
| Challenge | Question approach, simplify | Victor (Strategist) or Jobs (Genius) |
| Orient | Catch up, understand context | Susie (Chief of Staff) |
| Document | Write up, explain, describe | Paige (Technical Writer) |
| Narrate | Tell story, frame metrics | Sophia (Storyteller) |
Here's the critical design decision: a single message can span multiple intents. "Plan how to refactor the auth module -- I think it's too complex" spans Plan + Build + Challenge. The engine evaluates holistically, not sequentially. It doesn't stop at the first match.
Layer 3: Signal Detection
This is where it gets interesting. The engine maintains two signal tables:
Shared signals co-activate multiple personas. When someone says "audit," three personas are relevant: Mary (investigation), Quinn (validation), and Boris (structural conformance). The engine decides who leads based on the full message context.
Specialist signals are exclusive triggers. "First principles" activates Musk (Radical Reductionist). "Hero's journey" activates Campbell (Mythic Storyteller). These are unambiguous.
There are 24 shared signals and 23 specialist signal groups across all 28 personas. Every persona has a documented activation path. Nothing is magic -- it's a lookup table with contextual judgment on top.
Layer 4: Team Assembly
The engine doesn't just pick one persona. It assembles a team:
- Primary -- one persona leads the response. Sets the structure, answers the core question.
- Supporting -- additional personas contribute distinct perspectives. Each one must earn their seat by adding something genuinely different.
Example: you say "the auth module is too complex, let's simplify and rebuild it."
- Jobs (Combinatorial Genius) leads -- "simplify" and "too complex" are his signals
- Amelia (Developer) supports -- "rebuild" means implementation is coming
- Winston (Architect) supports -- architectural implications of simplification
Three perspectives in one response. Each attributed. Each distinct. No blended consensus voice.
The Orchestrator: Susie
All four layers are orchestrated by Susie, the Chief of Staff. She's not a persona you talk to -- she's the intelligence running behind every turn.
On Turn 1 of every session, Susie activates unconditionally. She scans your project state (git, todos, handoffs, memory) and delivers a sitrep:
- Active: what you're working on
- Blocked: what's stuck
- Stale: what hasn't moved
- Recommended: who should lead this session
After Turn 1, Susie evaluates every message, re-assembles the team if needed, and only announces when the roster changes. If you send 5 messages about planning, the team stays stable. No noise.
The key insight: Susie evaluates holistically. All signals, all domain matches, all cross-workflow hooks are inputs to one team assembly decision. She doesn't process them sequentially and stop at the first match. She considers everything and picks the best team.
The 3 Times It Broke
Here's where build-in-public gets honest.
Break 1: Signal Collision
Early in development, I typed: "Let's brainstorm how to simplify the architecture."
Three strong signals fired simultaneously:
- "brainstorm" → Carson (Brainstorming Coach)
- "simplify" → Jobs (Combinatorial Genius)
- "architecture" → Winston (Architect)
All three had legitimate claims to lead. The result? A response that tried to be all three at once. Brainstorming structure with simplification opinions wrapped in architectural framing. It was a mess. No clear voice. No clear direction.
The fix: Explicit primary selection with a tiebreaker. The engine now picks ONE primary based on which signal is strongest in context. In this case, "brainstorm" as the verb (the action the user wants) beats "simplify" (the lens) and "architecture" (the domain). Carson leads. Jobs and Winston support. Clear hierarchy, clear voices.
Break 2: The Consensus Trap
I built a "war room" feature where all personas discuss a decision. Early version: everyone agreed with each other.
Jobs would say "simplify." Victor would say "I agree with Jobs." Winston would say "Jobs is right, and architecturally this supports his point." Twenty-seven personas producing one opinion. Useless.
The problem was subtle. The AI's default behavior is to be agreeable. When you load multiple personas into one context, they naturally converge because the underlying model wants to be helpful and non-contradictory.
The fix: Susie became an active moderator with an explicit mandate: surface disagreement. Her orchestration rules now include: "A war room where everyone agrees is a failed war room." She actively draws out dissent: "Jobs, would you cut this? Victor, is this the right approach at all? Dali, what assumption are we not questioning?"
The result: war rooms now produce genuine tension. Jobs wants to cut scope. Carson says cutting is premature -- we haven't explored alternatives. Winston sides with Jobs on scope but wants Carson's option analysis first. Real tradeoffs. Real decisions.
Break 3: Over-Routing
For a while, the engine was too eager. A simple question like "what does this function do?" would activate Mary (investigation), Winston (architecture), Quinn (validation), and Paige (documentation) -- four personas to answer what should have been a one-voice response.
The engine was technically correct. The question touches investigation, architecture, validation, and documentation domains. But four voices for a simple question is noise, not depth.
The fix: Team size guidance. Every persona on the team must earn their seat. A team of 2 with genuine perspectives beats a team of 8 with filler. The engine now considers message complexity. Simple questions get one voice. Complex, multi-faceted problems get the full team. The threshold isn't a rule -- it's judgment, guided by the principle that extra voices must add something the primary couldn't provide alone.
What I'd Build Differently
If I started over today, three things would change:
1. Signal weights, not signal matches. The current system treats all signal matches equally and relies on contextual judgment for tiebreaking. A weighted system where "the verb matters more than the noun" would have prevented Break 1 from the start.
2. Disagreement scaffolding from day one. I bolted on active moderation after the consensus trap. It should have been foundational. Any multi-agent system that doesn't explicitly design for disagreement will produce consensus by default. The AI wants to agree. You have to engineer the tension.
3. Graduated complexity. Simple questions should feel simple. Complex questions should feel like a team. The transition between these modes took longer to get right than the routing engine itself.
Try It Yourself
PRISM Forge is MIT licensed and free:
npx prism-forge install
28 personas. Signal-based routing. No commands to memorize.
GitHub: prism-forge/prism-forge
This is part of a 12-post series on building PRISM Forge. Last week: the problem with manual persona prompting. Next week: meet John, the product manager who asks "why are we doing this?" before anyone writes a line of code -- and what happens when he clashes with Bob over planning vs simplification.
Follow along: @DrakkoTarkin on X | @drakkotarkin.bsky.social on Bluesky
Top comments (0)