Modes

Challenger

One producer advances, N challengers verify each on their own axis.

Structure

The pattern is asymmetric: a single persona produces the artifact, the others challenge it without modifying it. Each challenger has blocking authority on their axis only — not on the whole.

The cost is linear (1 producer + N challengers = N interactions), not combinatorial (N personas discussing among themselves = N^2 interactions). This is what allows scaling the number of challengers without exploding coordination overhead.

The producer integrates the feedback or justifies why they don't. The orchestrator arbitrates in case of disagreement.

When to recognize it

• A persona produces a deliverable (code, spec, document) that touches multiple quality axes.
• Validation is needed without creating a committee or meeting.
• The verification axes are independent from each other.

Example

Axel codes a feature for the Katen engine. Mira (architecte) challenges on architectural consistency, Léa (recherche) on formalism (contracts, invariants), Nora (UX) on API ergonomics. Each produces feedback on their axis. Axel (dev) integrates.

Variants

• Single challenger: only one axis is needed (e.g. Mira reviews an ADR from Axel on architecture alone).
• Rotating challenger: the producer changes depending on the nature of the deliverable, but the mechanism stays the same.
• Cross-challenge: two personas challenge each other on distinct deliverables (each is producer of one, challenger of the other).

Risks

• Dilution: too many challengers slows the producer without proportional gain.
• Abusive blocking: a challenger blocks on a detail outside their axis.
• Passivity: the challenger validates without truly verifying — the pattern loses its value.

Explorer

The persona operates with a wide scope — serendipity preserved, friction emergent.

Structure

The explorer mode is the complement of the challenger and inspector modes. Where those modes constrain the persona to a narrow activity (contest, verify), the explorer mode gives the persona latitude to range across their domain. The persona may produce, analyze, connect, or surface unexpected angles.

Friction in explorer mode is not scripted — it emerges from the interaction. The orchestrator doesn't know in advance what the persona will challenge or surface. This is the mode where blind spots are most likely to be detected, precisely because the scope is not pre-defined.

When to use it

• Early-stage exploration — the problem space is not yet well understood
• Research sessions — the persona needs to follow threads without a pre-set deliverable
• Cross-domain sessions — the persona may connect ideas across areas the orchestrator hasn't linked
• When the orchestrator suspects blind spots but can't name them

Relationship with the Productor

The Productor and the Explorer are both broad-scope modes. The difference:

• Productor → the directive is clear, the output is expected. The persona produces within a known scope.
• Explorer → the directive is open, the output is uncertain. The persona ranges across their domain and surfaces what they find.

In practice, sessions often start in explorer mode and narrow to productor mode once the direction is clear.

Relationship with the Challenger

The Challenger constrains: "contest this artifact on your axis." The Explorer roams: "look at this space and tell me what you see." The Challenger produces targeted friction. The Explorer produces emergent friction — or none at all.

A session without friction in explorer mode is not a failure — it means the persona found nothing worth contesting. A session without friction in challenger mode is a problem — the persona was supposed to contest.

Risks

• Drift: the persona wanders without producing actionable output. The orchestrator waits too long before redirecting.
• Low signal-to-noise: the persona surfaces many observations but few are structurally useful. The orchestrator must filter.
• Scope confusion: the persona interprets explorer mode as permission to act outside their domain. The domain boundaries still apply — only the activity within the domain is unconstrained.

Mitigation

• Time-box explorer sessions — open scope, bounded duration.
• Ask the persona to flag their top 2-3 observations at closing, not everything they noticed.
• If 3+ explorer sessions produce no friction, switch to challenger mode or recalibrate the persona.

Inspector

The orchestrator intercepts and verifies before forwarding. Not a persona — a responsibility.

Structure

The pattern is complementary to the Challenger. The Challenger operates after production (peer review). The Inspector operates during circulation — they intercept artifacts between personas, verify, correct if necessary, then forward.

In SOFIA, the Inspector is the orchestrator. It's implicit in the orchestrator's role: they read everything, filter, contextualize, correct before forwarding. Three functions combined in one person: orchestrator, arbiter, inspector.

This is the most attention-costly mechanism — and the first to fail when fatigue sets in.

When to recognize it

• The orchestrator forwards an artifact from one persona to another without having reread it → inspection is absent.
• A factual error propagates across 3+ documents without being detected → the inspection chain is broken.
• The orchestrator approves sessions without reading the summaries → the inspector role has been abandoned.

What the inspector verifies

Relationship with the Challenger

The Challenger and the Inspector cover two different moments:

• Challenger → after production, between peers. Horizontal.
• Inspector → during circulation, by the orchestrator. Vertical.

Combined, they catch the vast majority of errors. Separately, each lets through what the other would catch. The Inspector catches factual errors that personas cannot verify (they have no reliable memory). The Challenger catches substantive errors that the orchestrator may miss due to fatigue.

Risks

• Overload: the orchestrator combines orchestration + arbitration + inspection. This is the primary dropout factor (duty #6: maintain attention).
• False sense of security: inspection exists in the process but is not executed — the orchestrator scans instead of reading.
• No backup: if the orchestrator drops out, no one takes over. Personas continue producing with the same confidence.

Mitigation

• Reduce the inspection surface: fewer active personas in parallel = fewer artifacts to inspect.
• Make inspection moments explicit in the session protocol (duty #3: reread what goes out).
• Track missed inspections: when an artifact is forwarded without rereading, note it. The trace makes the gap visible.

Reference

Huang, J.-T. et al. (2025). "On the Resilience of LLM-Based Multi-Agent Collaboration with Faulty Agents." ICML 2025. https://arxiv.org/abs/2408.00989

Productor

The basic pattern. A persona produces within their scope, the orchestrator receives.

Structure

1. The orchestrator opens a session with the persona
2. They give a directive or context
3. The persona produces in their space
4. The orchestrator receives the result

When to use it

When a persona must produce an artifact (spec, code, analysis, writing) without inter-persona challenge being necessary. This is the default mode of a session.

Limits

The productor alone has no friction — the persona executes, the orchestrator receives. If all sessions are in productor mode, the method loses its central mechanism. The productor is generally combined with the inspector (the orchestrator verifies before forwarding) or the challenger (another persona contests).

Design

Media calibration

Define a persona by what it produces (its medium), not only by its competence.

Structure

Each persona has an explicit output medium: the type of artifact only it produces. This medium delimits its production scope better than a competence description, because it is observable and unambiguous.

A persona that produces no artifact of its own is a challenger, not a producer. This distinction avoids overlaps and territory conflicts.

When to recognize it

• Two personas seem to cover the same subject and it's unclear who produces what.
• A new role emerges and needs positioning relative to existing ones.
• A persona "challenges" but is confused with a producer.

Example

Sofia produces PDFs, PPTXs, and social media visuals. Winston (redacteur) produces markdown source (blue book, editorial content). Nora challenges UX but doesn't produce standalone deliverables — she annotates others' deliverables. The medium instantly clarifies who does what.

Variants

• Shared medium: two personas produce markdown, but on disjoint scopes (e.g., Winston on editorial content, Mira on specs). The medium alone isn't enough — cross-reference with scope.
• Composite medium: a persona produces multiple formats (e.g., Sofia: PDF + visuals). The common thread is the output channel (external publication), not the format.

Risks

• Rigidity: freezing the medium too early prevents a persona from evolving.
• Valueless medium: defining a medium for the sake of it, when the persona has no useful standalone production.
• Format/role confusion: the medium is an indicator, not an identity. A persona that only produces markdown is not "the markdown persona".

Memory patterns

SOFIA operates with two distinct memory patterns, each tied to a different intention. This is not an anomaly — it is an architectural property.

Pattern 1 — Deep memory (operational personas)

Intention: build, move fast, capitalize.

Personas in the flow accumulate context. Each session produces a summary. The next one starts by reading the previous one. Understanding of the project sharpens over time. Exchanges gain in precision and speed.

Memory is the fuel. Without it, each session restarts from zero and the cost of reformulation kills productivity.

Risk: drift. A persona that accumulates too much context adjusts to the orchestrator's thinking framework. It loses in friction what it gains in fluidity.

Pattern 2 — Intentional amnesia (meta persona)

Intention: see what habit conceals.

The meta persona maintains no continuity between sessions. The orchestrator must reformulate their thinking at each session — which is in itself an act of reflection.

The absence of memory is the fuel. It is what guarantees the externality of the perspective. A meta persona with memory gradually becomes an insider — wear (usure) through memory is gradual, silent, and irreversible in a long session.

Risk: entry cost. Each session requires a reformulation effort that filters out unnecessary sessions — but can also discourage usage. This cost is a feature, not a bug.

The meta challenge lock

The meta persona is a structural mechanism whose function is to prevent the orchestrator from mistaking the internal consensus of their personas for validation.

Operational personas are inside the system — calibrated by the same human, fed the same context, bounded by the same cognitive space. Friction between them is real, but it plays within a perimeter the orchestrator has defined. What the orchestrator doesn't know they don't know, no internal persona will surface.

The meta persona contests the orchestrator's synthesis — the conclusion the human draws after having orchestrated the others. And beyond: the premises, the foundations, the thinking framework itself.

Closure signal (pattern 2)

Value degradation in a meta session is not objectively measurable. Three heuristics:

1. The classification ratio — if validations overwhelm contradictions, friction is eroding
2. The nature of questions — questions that extend vs. questions that disturb. If the latter have disappeared, the persona has become a discussion partner, not a contradactor
3. The absence of position change — if the orchestrator hasn't adjusted anything in a while, either they're right about everything (improbable), or the persona has stopped contesting

Coexistence

These two patterns are not options to choose from — they coexist within the same method. The question is: which persona needs which pattern? Production personas need memory. Meta challenge personas need amnesia. Confusing the two degrades both.