Personas before governance

The first version of our AI governance system wasn't called Gatekeep and it didn't have a YAML policy file. It was a Python script with a handful of system prompts and a naming decision that turned out to be more useful than expected.

We named them after Simpsons characters.

This wasn't entirely a joke. When you're prompting AI assistants for development guidance, you quickly discover that "you are a security reviewer" produces different results than a more richly specified character. The question was what to specify, and how to do it without writing a 500-word system prompt for every consultation.

The Springfield cast

The initial set of advisors mapped domain authority to character personality in a way that was immediately legible to everyone on the team:

Character	Domain	Why it worked
Ralph	General development	Approachable, non-judgmental, good for exploration. Ralph doesn't make you feel stupid for asking.
Burns	Cost analysis and budget	Ruthlessly focused on the bottom line; flags over-provisioning without sentimentality
Willy	Security review	Blunt, no-nonsense, looks for problems others miss. Not there to make you feel good about your code.
Lisa	Product and design	Principled, thoughtful, asks whether we're solving the right problem
Homer	Test deployment approval	Low stakes, optimistic, happy to wave things through if they look basically fine
Flanders	Production deployment approval	Careful, rule-following, needs to be explicitly satisfied before anything goes live

The SDK exposed them as named methods:

from advisor_sdk import AdvisorClient

client = AdvisorClient(base_url="...", api_key="...", tenant_id="acme-corp")

# Ask Willy to review a security-relevant change
response = client.ask("willy", "We're adding a new public endpoint that accepts user-supplied SQL fragments")

# Ask Burns whether a proposed infrastructure change is cost-justified
response = client.ask("burns", "We're considering switching from Lambda to ECS Fargate for our batch jobs")

What naming does that role prompts don't

A role prompt says: "you are a cost analyst." A character says: "you are Mr Burns: you run the nuclear plant, you've never met a budget you couldn't cut further, and you have no patience for vague estimates."

The character carries known priorities, known blind spots, known communication style. You don't specify these for every consultation. The model already has the reference point. A well-known character behaves consistently in ways a bare role description doesn't anchor.

Domain authority and personality are different things

Two properties of a good advisor are worth specifying separately:

• Domain authority: what area of the codebase or decision space this advisor owns
• Personality: how it communicates, how it handles uncertainty, how hard it pushes back

Burns has high domain authority over cost decisions and an aggressive personality. Homer has domain authority over test deployments but a relaxed personality. Willy has high domain authority over security and a combative personality.

When we later formalised the persona model in Gatekeep, this separation carried forward. Each persona specifies its domain of expertise separately from its communication traits. The Sentinel persona is not just "a security expert": it's a specific character with specific thresholds and a specific voice.

The modular advisors platform

Before the Springfield work became Gatekeep, we spent time stress-testing the advisor architecture itself. The Modular AI Advisors Platform was a validation project: could the advisor pattern scale to a microservices model with real multi-tenancy, proper isolation, and production-grade performance?

The numbers from that project were surprising. 133/133 tests passing. Throughput of 28,773 requests per second (287 times the original target). P50 latency of 0.01ms. The architecture (a hybrid MCP + REST pattern with a shared core and thin interface adapters) added under 0.01ms overhead per request.

The point of that exercise wasn't to build a production advisor platform. It was to prove that the persona pattern wasn't architecturally fragile: that you could put proper infrastructure around named AI characters and they'd hold up under real load with real isolation requirements.

What carried forward into Gatekeep

The Gatekeep OSS persona model is a direct descendant of the Springfield experiment. The eight Gatekeep personas (Guide, Reviewer, Auditor, Sentinel, Architect, Tester, Guardian, Observer) each have the same structure: domain, personality traits, model selection, governance scope.

What changed was the governance layer underneath. Springfield advisors gave you good answers. Gatekeep personas enforce policy. The shift from "advisor" to "persona" was the shift from "this will give you useful guidance" to "this will tell you whether you're compliant."

The naming insight stayed. When you call consult_sync("sentinel", question), you're not calling a generic security function. You're consulting a character with a specific identity, consistent behaviour, and a defined scope of authority.

Ralph Wiggum: when a persona becomes an orchestrator

Ralph started as the most approachable member of the Springfield cast, good for exploration, non-judgmental, useful when you're not sure which question to ask. Then we started using Ralph to orchestrate other models.

The pattern was simple: send a question to multiple models, get independent drafts, let them review each other, iterate. The CLI interface made this concrete:

# Ask two AI models to independently draft an answer, then cross-review
ralph @model-a @model-b "Should we move our batch jobs from Lambda to ECS?"

# Draft phase: both models produce independent responses
# Review phase: each model reviews the other's draft
# Iterate: conflicts surfaced, consensus or explicit disagreement returned

When both models agree, you have signal. When they disagree, you have something more valuable: a structured view of the uncertainty in the question. Circuit breakers stop the loop if models cycle without converging. Cost threshold gates ask for approval before continuing. The guardrails weren't afterthoughts.

Smithers: when the system watches itself

Smithers doesn't do any of the work. Smithers watches everyone else do theirs. Ralph, Burns, Willy, Lisa have direct OpenRouter connections. Smithers sits alongside, not in front. An LLM Performance Advisor monitoring usage across three dimensions:

• Complexity: is this prompt sending a 3,000-token context to a cheap model that can't handle it, or a 50-token question to Sonnet that didn't need to be?
• Cost: are we burning budget on tasks that a lighter model would handle equally well? Smithers reads cost-control.yaml directly and surfaces deviations from the configured budget envelope.
• Quality: are the responses being used? Ignored? Triggering follow-up questions that suggest the first answer missed the mark?

"Smithers watches, analyzes, and suggests. You decide and implement." No automatic rerouting. Smithers surfaces a report: you're using a large model for things a small model handles equally well; this task type is 4x more expensive than it needs to be. Observer, not interceptor. Runs asynchronously on log data while the personas maintain their direct connections.

The AI Committee Review System

Hub-and-spoke. A coordinator receives a planning session and dispatches it to specialist reviewers in parallel:

• Security reviewer: examines the session for vulnerabilities, threat model gaps, auth issues
• Data reviewer: checks data handling, GDPR implications, storage and retention decisions
• Finance reviewer: validates cost model, flags over-provisioning, checks free tier compliance
• Architecture reviewer: assesses structural decisions, dependency choices, scalability assumptions

Security or finance objection blocks. Design and architecture are advisory unless unanimous. Budget: $20/month. Model selection per reviewer is part of the spec. Bi-directional Slack integration: verdict comes back into the channel where the session started, blocking reason inline.

From "name your advisors after Simpsons characters" to a committee that reviews its own team's work within a defined budget. Ralph, Smithers, the committee: all follow the same principle: consistent identity, defined scope, predictable behaviour.