Skip to content

IFS as an AI Architecture Pattern

6 min read•5/3/2026•Frank
IFS as an AI Architecture Pattern

IFS as an AI Architecture Pattern

How to translate a structural model of mind into a structural model of agentic systems.

This guide is the implementation companion to No Bad Parts: Sovereign AI and the Self-Led AI Architecture research brief. Read those first if you want the why. This guide is the how.

1. The problem

Most agent stacks are organized around task graphs:

Goal → Plan → Tools → Output → Review

That is workflow, not governance. It does not answer:

  • Which sub-process is leading this turn?
  • Which signal got suppressed to produce a coherent answer?
  • Which prediction is being run on stale evidence?
  • When should the system override its own helpful instinct?

Without those, agents fail in the predictable single-voice ways: hallucination, over-refusal, sycophancy, blandness, tool misuse. The IFS pattern names what is missing — the layer that observes which role is currently driving and decides whether to integrate, suppress, or amplify.

2. The role mapping

IFS roleAI equivalentFunction
SelfOrchestrator / governance layerObserves which part is leading, weighs trade-offs, makes the integrated call. Persistent identity across sessions.
ManagerPlanner, evaluator, editor, formatter, standards enforcerProactive specialists that try to keep work clean before failure surfaces.
FirefighterCrisis handler, escalation suppressor, emergency simplifierReactive specialists that activate when error or overwhelm breaks through. Short-term relief, not strategy.
ExileUnresolved memory, ignored signal, suppressed feedback, rejected draftsThe signals most stacks discard — the actual evidence base for system improvement.
ProtectorSafety, privacy, ethics, reputation guardiansHard-constraint enforcers. Veto power, not driving power.
UnburdeningReflection, repair, memory update, role reassignmentPeriodic rebalancing so no part becomes permanently extreme.

The mapping is interpretive — different teams can map differently and still get the benefit. What matters is that role differentiation becomes explicit and observable to the orchestrator.

3. The design pattern

Input
↓
Part Activation Detection
  ├── Which roles are active for this input?
  ├── Which are appropriate? Which are overreaching?
  └── Is there a polarization (two parts in conflict)?
↓
Internal Deliberation
  ├── Each active part produces its candidate response
  ├── Orchestrator weighs trade-offs
  └── Conflict surfaced to orchestrator, not hidden
↓
Self-Orchestrated Decision
  ├── Orchestrator picks the integrated response
  └── Notes which part was overridden and why
↓
Output
↓
Reflection
  ├── Did the chosen response close the loop?
  ├── Which part predicted what? What was the error?
  └── Is any part trending toward extreme over time?
↓
Memory Update
  ├── Store relevant signal in long-term memory
  ├── Move suppressed signals to exile layer (do not discard)
  └── Update part predictions with new evidence

Notice the exile layer. Most stacks discard rejected drafts, suppressed signals, blocked tool calls, and painful user feedback. A Self-led architecture stores them deliberately. They are the system's actual evidence base for improvement.

The Self-Led Agent Family — the structural pattern this guide walks through implementing

4. Implementation choices

You can build this on any modern agentic runtime. The pattern is governance, not framework.

Option A: Single-model, structured prompting

Use one LLM. Implement role differentiation through structured prompts and tool routing. The model "wears different hats" under orchestrator control. The orchestrator is itself a prompt that observes which hat is currently leading and decides the next move.

  • Pros: Simple, low-latency, low-cost. Works on any frontier model.
  • Cons: Role separation is logical only — one model still produces all outputs, so blending is harder to detect.
  • Best for: Personal AI assistants, coding copilots, reflection interfaces.

Option B: Multi-agent runtime with role-typed agents

Use LangGraph, CrewAI, the Vercel AI SDK, or Oracle Agent SDK. Each role becomes a typed agent. The orchestrator dispatches and integrates.

  • Pros: Role boundaries are runtime-enforced. Observability per-role is clean. Failure mode attribution is precise.
  • Cons: Higher orchestration overhead. Latency cost. More moving parts.
  • Best for: Production agentic systems, enterprise AI deployments, workflows where audit and governance matter.

Option C: Hybrid

Single-model fast path for routine turns. Multi-agent escalation when the orchestrator detects a high-stakes decision, an active conflict between parts, or a request that triggers protector involvement.

  • Pros: Latency-tier matched to risk-tier. Cost stays low for ambient interactions.
  • Cons: Two architectures to maintain.
  • Best for: Most production deployments at moderate scale.

5. The exile memory layer (most underbuilt)

Of all the IFS-derived patterns, the exile memory layer is the one production stacks most often skip. Build it deliberately.

What goes in:

  • Rejected drafts. Outputs the orchestrator suppressed before render.
  • Blocked tool calls. Actions the protector vetoed and why.
  • Painful user feedback. Negative reactions, retries, abandoned sessions.
  • Suppressed signals. Topics the agent was steered away from. Questions the user asked twice.
  • Outdated predictions. Confident answers that turned out wrong.

What it is for:

  • Reflection. Periodic surfacing of "the things this system is currently avoiding."
  • Calibration. Predictions that consistently miss should update the part holding them.
  • Integration. Some exiled signals deserve to come back into normal operation. Others stay flagged.
  • Audit. When a leader asks "what is this system not telling us?", the exile layer is where the honest answer lives.

Without an exile layer, the system gets steadily more confident and steadily less honest. Build it.

6. The integration loop

Run on a cadence — not every turn, not never. Once per session for short interactions. Daily for ambient agents. Weekly for long-running systems.

What the integration loop does:

  1. Surfaces the dominant active parts of the period.
  2. Surfaces the most-exiled signals of the period.
  3. Asks: which roles got captured? Which signals got buried?
  4. Updates memory: values, commitments, repair events, retired predictions.
  5. Reassigns roles where the current assignment has drifted.

This is the maintenance layer that prevents drift. Without it, every governance pattern eventually decays into the same single-voice stack you started with.

7. The product implication

The strongest personal AI is not a chatbot. It is an inner operating system — a Self-led layer that holds memory, observes which part is leading the user's current reflection or decision, and produces integrated next moves.

The strongest enterprise agent is not a swarm. It is a Self-led system — one that names which sub-process is leading each consequential output, governs role boundaries explicitly, and integrates suppressed signals on a cadence.

Both follow the same pattern. No bad parts. Only burdened ones. No sovereign system without a Self at the center.

Continue