AI coding assistants have become fixtures in development workflows, yet most operate as stateless, personality-less text generators. Moeru-AI/Airi takes a fundamentally different approach, introducing a modular "soul container" architecture that separates personality configuration, memory persistence, and voice interaction into composable layers.

Table of Contents

• Why Your AI Pair Programmer Needs a Soul
• Prerequisites
• Why Personality Matters in Long-Term Pair Programming
• Moeru-AI/Airi: Project Overview and Core Concepts
• The Architecture of Soul Containers in Agentic AI
• Implementing a Custom Soul: Step-by-Step
• Integrating Real-Time Voice Chat Into Coding Workflows
• Implementation Checklist: Your Soul Design Playbook
• Lessons Learned and Architectural Trade-Offs
• Where to Go From Here

Why Your AI Pair Programmer Needs a Soul

AI coding assistants have become fixtures in development workflows, yet most operate as stateless, personality-less text generators. They answer questions, produce code snippets, and vanish from context the moment a session ends. For developers who spend hours daily in pair programming with these tools, the experience often feels transactional, requiring constant re-orientation and prompt re-engineering. The cognitive switching cost is real: every time an assistant's tone shifts unpredictably or it loses the thread of a conversation, the developer drops out of flow state.

Moeru-AI/Airi is an open-source project that takes a fundamentally different approach. Rather than treating personality as an afterthought, it introduces a modular "soul container" architecture that separates personality configuration, memory persistence, and voice interaction into composable layers. The architecture offers a replicable pattern for building agentic AI systems with persistent character, one that developers can study, fork, and adapt.

By the end of this tutorial, readers will understand the soul container pattern, build a custom soul module in Node.js, wire it into an agent pipeline, and connect a React-based voice interface. The goal is not just conceptual understanding but a working prototype that shows how to architect personality rather than hack it into prompts.

Prerequisites

Before proceeding, ensure the following are in place:

• Node.js ≥18.0.0 (node --version)
• npm ≥9 (npm --version)
• Git (to clone the repository)
• A modern browser — Chrome or Edge recommended for full MediaRecorder support; see Safari compatibility notes in the voice section
• HTTPS or localhost — required for microphone access via getUserMedia

Clone the repository and install dependencies from the monorepo root:

git clone https://github.com/moeru-ai/airi.git
cd airi
npm install

All require paths in the tutorial assume execution from a package directory within the monorepo unless otherwise noted.

Why Personality Matters in Long-Term Pair Programming

The Cognitive Cost of Generic AI

Developers report fatigue with flat-toned assistants in community threads and internal tooling retrospectives across organizations adopting AI pair programming. The core issue is not that the assistant lacks capability but that inconsistent tone and behavior creates micro-interruptions. When an assistant oscillates between terse and verbose, between cautious and overconfident, the developer must constantly recalibrate expectations. That recalibration pulls attention away from the problem at hand.

Flow state, the deeply focused condition where complex programming work happens most efficiently, is fragile. Research by Iqbal and Bailey found that disrupted computing tasks took an average of 8 minutes longer to complete than uninterrupted ones ("Disruption and Recovery of Computing Tasks," CHI 2006). Even brief disruptions compound across a session. A coding assistant that behaves unpredictably functions as a low-grade but persistent source of interruption, even when its technical output is correct.

A coding assistant that behaves unpredictably functions as a low-grade but persistent source of interruption, even when its technical output is correct.

What "Soul" Means in an Engineering Context

In the Airi architecture, "soul" is not a metaphor. It is a technical term for the combination of persistent personality traits, communication style preferences, memory context bindings, and interaction cadence rules that define how an agent behaves over time. This is distinct from a simple system prompt. A system prompt is a static text prefix sent with each request. A soul is architectural: it encompasses transformation logic, stateful memory hooks, behavioral constraints, and fallback patterns that operate as middleware in the agent pipeline. Importantly, soul containers still depend on the LLM to generate the initial response — the soul layer operates post-generation, transforming that output deterministically. The difference is analogous to the gap between a CSS inline style and a design system. One is a one-off instruction; the other is a structure you can test with assertions, compose across agents, and swap at runtime without touching prompt text.

Moeru-AI/Airi: Project Overview and Core Concepts

Repository Structure and Philosophy

The moeru-ai/airi repository is organized as a monorepo, reflecting a design philosophy centered on modularity, composability, and real-time-first interaction. Packages are separated by concern: personality configuration lives apart from memory management, which lives apart from voice processing, which lives apart from the frontend interface. This separation makes it possible to swap or customize individual layers without rewriting the entire stack.

Key Architectural Components

Four architectural layers define the system. Soul containers encapsulate personality configuration and response transformation logic. Memory and context persistence layers manage what the agent remembers across sessions, binding specific memory scopes to specific soul configurations. The voice interaction pipeline handles real-time audio streaming, speech-to-text conversion, soul-processed response generation, and text-to-speech output. Finally, the frontend interface, built in React, provides the developer-facing UI for both text and voice interaction.

The following structure is illustrative of the intended architecture. Verify current package names against the live repository before use.

airi/
├── packages/
│   ├── soul-core/          # Soul container runtime and base classes
│   ├── soul-configs/       # Predefined personality configurations (JSON/JS)
│   ├── memory/             # Context persistence and session management
│   ├── voice-pipeline/     # STT, TTS, and WebSocket audio streaming
│   ├── agent-runtime/      # Orchestrates LLM calls, soul middleware, routing
│   └── ui/                 # React frontend for text and voice interaction
├── services/
│   ├── websocket-server/   # Real-time communication layer
│   └── llm-proxy/         # LLM API abstraction and request routing
├── configs/                # Global configuration files
├── tests/                  # Integration and unit test suites
└── package.json            # Monorepo root with workspace definitions

Each package exports named functions and a TypeScript type definition, allowing developers to import only the layers they need. The soul-core package, for example, can be used independently of the voice pipeline for text-only implementations.

The Architecture of Soul Containers in Agentic AI

What Is a Soul Container?

A soul container is an encapsulated module that holds personality configuration, behavioral rules, memory hooks, and response transformation logic. It takes raw LLM output and returns personality-adjusted text. Architecturally, it functions as middleware: it sits between the language model and the developer-facing interface, applying deterministic transformations to non-deterministic model output.

This is fundamentally different from a system prompt or prompt template. A system prompt influences the model's generation but offers no post-hoc enforcement over output format or tone. A soul container operates post-generation, applying deterministic post-processing rules to the response — improving tonal and formatting consistency, though not guaranteeing semantic uniformity, as the underlying LLM output remains non-deterministic. It can trim verbosity, inject humor at calibrated levels, enforce consistent terminology, and adjust assertiveness, all through code rather than hope.

A soul container operates post-generation, applying deterministic post-processing rules to the response — improving tonal and formatting consistency, though not guaranteeing semantic uniformity, as the underlying LLM output remains non-deterministic.

Anatomy of a Soul Configuration

A soul configuration defines three categories of parameters. Personality traits govern tone, verbosity, humor level, and assertiveness, each expressed as a numerical value on a defined scale. When a behavioral constraint fires — say the agent detects an error cascade — the escalation rule determines whether it asks a clarifying question or stays silent. Memory bindings scope what the agent can reference from prior interactions, determining which context windows a given soul has access to.

// soul-config.js — Anatomy of a soul configuration
"use strict";

const soulConfig = {
  id: "code-reviewer-v1",
  version: "1.0.0",

  // Personality traits: scale of 0.0 (minimum) to 1.0 (maximum)
  traits: {
    conciseness: 0.8,     // High: prefer terse, direct responses
    humor: 0.2,           // Low: occasional dry wit, never jokes in errors
    assertiveness: 0.7,   // High: will push back on questionable patterns
    encouragement: 0.5,   // Moderate: acknowledge good work without excess
    formality: 0.4        // Low-moderate: professional but not stiff
  },

  // Behavioral constraints
  behavior: {
    interruptThreshold: "critical",  // Only interrupt for errors or security issues
    silenceOnBoilerplate: true,      // Stay quiet during routine scaffolding
    uncertaintyEscalation: "ask",    // Ask clarifying questions rather than guess
    maxResponseLines: 15             // Hard cap on response length
  },

  // Memory binding keys — scopes this soul can read from.
  // These keys are resolved by the memory package; see packages/memory/
  // for scope definitions and available binding formats.
  memoryBindings: [
    "session:current",               // Current coding session context
    "project:conventions",           // Project-specific style and patterns
    "developer:preferences"          // Long-term developer preference history
  ]
};

module.exports = soulConfig;

Each field is actionable. The conciseness trait maps directly to a word-count reduction filter in the transformation pipeline. The silenceOnBoilerplate flag triggers pattern matching against known scaffolding operations to suppress unnecessary commentary.

How Soul Containers Compose with Agentic Workflows

The soul container operates as middleware in the request/response pipeline. When the agent runtime receives a developer's input, it routes input to the LLM, gets raw output, and pipes it through the soul container before delivering it to the frontend. The soul transforms the response according to its personality configuration: adjusting tone, filtering verbosity, and applying behavioral rules.

Soul containers can be stateful or stateless. A stateful soul tracks interaction history within a session, allowing it to modulate behavior over time (becoming more concise as a session progresses, for example). A stateless soul applies the same transformations regardless of history, which is simpler to reason about and cheaper to run. The choice depends on context: stateful patterns suit long debugging sessions where adaptive behavior adds value, while stateless patterns work well for one-off code generation tasks.

// soulMiddleware.js — Soul container as pipeline middleware
// Place this file alongside soul-config.js (e.g., in packages/my-soul/)
"use strict";

const soulConfig = require("./soul-config");

function applyConciseness(text, level) {
  if (level < 0.7) {
    return text;
  }
  // Strip filler phrases and reduce to essential content
  const fillers = /\b(basically|essentially|actually|obviously|simply put)\b/gi;
  text = text.replace(fillers, "").replace(/^\s*[,;]\s*/, "").replace(/\s{2,}/g, " ").trim();
  return text;
}

function enforceLineLimit(text, maxLines) {
  const lines = text.split("
");
  if (lines.length > maxLines) {
    return lines.slice(0, maxLines).join("
") + "
[...truncated]";
  }
  return text;
}

function soulMiddleware(rawLLMResponse, context = {}) {
  if (typeof rawLLMResponse !== "string") {
    return { text: "", silent: false };
  }

  // Suppress output during boilerplate if configured.
  // context.isBoilerplate must be set by the agent runtime's boilerplate-detection
  // step before passing the response to soul middleware.
  if (soulConfig.behavior.silenceOnBoilerplate && context.isBoilerplate) {
    return { text: "", silent: true };
  }

  let processed = rawLLMResponse;

  // Apply personality trait transformations
  processed = applyConciseness(processed, soulConfig.traits.conciseness);
  processed = enforceLineLimit(processed, soulConfig.behavior.maxResponseLines);

  return { text: processed, silent: false };
}

module.exports = { soulMiddleware };

The middleware pattern keeps soul logic decoupled from both the LLM integration and the frontend rendering. Swapping personalities becomes a configuration change, not a refactor.

Implementing a Custom Soul: Step-by-Step

Step 1: Define Personality Traits

Choosing traits for a coding context requires specificity. A soul designed for code review benefits from high conciseness and assertiveness: it should flag problems directly without padding. A soul designed for debugging sessions might prioritize encouragement and patience, reducing the frustration of long troubleshooting cycles. Each trait should map to a measurable value that drives a concrete transformation in the pipeline.

Step 2: Build the Soul Container Module

The soul module exports both its configuration and its transformation functions. This is the primary artifact of the tutorial: a complete, runnable Node.js module that defines a custom soul.

Place soul.js, soul-config.js, and register-soul.js in a new directory, e.g., packages/my-soul/. Update require paths accordingly. soulMiddleware.js should be co-located in the same directory.

// soul.js — Complete custom soul container module
"use strict";

const config = {
  id: "debug-companion-v1",
  version: "1.0.0",
  traits: {
    conciseness: 0.5,     // Moderate: explain reasoning, but don't ramble
    encouragement: 0.8,   // High: debugging is frustrating, be supportive
    assertiveness: 0.4,   // Low-moderate: suggest, don't dictate
    humor: 0.3,           // Low: light touches only, never during errors
    patience: 0.9         // High: repeat explanations without irritation
    // Note: humor and patience traits are defined for future transformation
    // logic; current implementation handles conciseness, encouragement,
    // and assertiveness only.
  },
  behavior: {
    interruptThreshold: "never",
    silenceOnBoilerplate: false,
    uncertaintyEscalation: "suggest-alternatives",
    maxResponseLines: 25
  },
  memoryBindings: [
    "session:current",
    "session:error-history",
    "developer:preferences"
  ]
};

const SOUL_ID = config.id;

// context.isErrorContext must be set to true by the caller when the LLM
// response pertains to an error or exception; otherwise encouragement
// injection will not activate.
function transformResponse(rawText, context = {}) {
  if (rawText == null || typeof rawText !== "string") {
    console.error(`[${SOUL_ID}] transformResponse received non-string input:`, typeof rawText);
    return { text: "", soulId: SOUL_ID };
  }

  let output = rawText;

  // Encouragement injection for error-related responses
  if (context.isErrorContext && config.traits.encouragement >= 0.7) {
    // Encouragement phrase is selected randomly; use a seeded PRNG
    // if reproducible output is required.
    const encouragements = [
      "Good catch finding this.",
      "This is a common stumbling block — you're on the right track.",
      "Nearly there."
    ];
    if (encouragements.length > 0) {
      const pick = encouragements[Math.floor(Math.random() * encouragements.length)];
      output = pick + " " + output;
    }
  }

  // Assertiveness modulation: soften directive language at low levels
  if (config.traits.assertiveness < 0.5) {
    output = output
      .replace(/\bYou must\b/g, "Consider")
      .replace(/\bYou should\b/g, "It might help to")
      .replace(/\bDo this\b/gi, "One option is to");
  }

  // Enforce line limit
  const lines = output.split("
");
  if (lines.length > config.behavior.maxResponseLines) {
    output = lines.slice(0, config.behavior.maxResponseLines).join("
") + "
[...]";
  }

  return { text: output, soulId: SOUL_ID };
}

function handleError(err) {
  console.error(`[${SOUL_ID}] Soul transformation error:`, err.message);
  return { text: "", soulId: "fallback" };
}

module.exports = { config, transformResponse, handleError };

The transformResponse function takes raw LLM text and an optional context object. It validates the input, applies encouragement injection conditionally, softens directive language based on the assertiveness trait value, and enforces the line limit. The handleError function logs transformation errors and returns a valid fallback response object. The caller in register-soul.js constructs its own fallback independently, but direct callers of handleError also receive a usable return value.

Step 3: Wire It Into the Airi Pipeline

Registering the soul container with the agent runtime connects the transformation logic to the live pipeline. Error handling ensures that a faulty soul configuration never blocks the developer from receiving a response.

First, install the required package. Verify the package name against the repository's currently published packages — it may need to be referenced as a monorepo workspace dependency rather than an npm registry install:

npm install @airi/agent-runtime

Note: If @airi/agent-runtime is not published to npm, you will need to reference the package directly from the monorepo workspace (e.g., "@airi/agent-runtime": "workspace:*" in your package.json). Check the repository's root package.json for workspace configuration. Verify that AgentRuntime, registerSoul, and runtime.start match the actual API surface exported by the package.

// register-soul.js — Pipeline integration with error handling
"use strict";

const { AgentRuntime } = require("@airi/agent-runtime");
const soul = require("./soul");

const runtime = new AgentRuntime();

runtime.registerSoul({
  id: soul.config.id,
  version: soul.config.version,
  memoryBindings: soul.config.memoryBindings,
  transform: (rawResponse, context) => {
    try {
      return soul.transformResponse(rawResponse, context);
    } catch (err) {
      soul.handleError(err);
      // Fallback: pass raw response through without transformation
      return { text: rawResponse, soulId: "fallback" };
    }
  }
});

const port = process.env.AGENT_PORT || 3001;
runtime.start({ port });
console.log(`Agent runtime started on port ${port} with soul: ${soul.config.id}`);

After running node register-soul.js, confirm the runtime is available by checking the console output and testing the endpoint (e.g., curl http://localhost:3001/health). Consult the agent-runtime package documentation for the exact API surface and available routes.

The try/catch block around the transformation call is not optional. Soul modules contain custom logic that can throw on unexpected input, and a crashed soul should never result in a silent failure or a dropped response.

Integrating Real-Time Voice Chat Into Coding Workflows

Why Voice Changes the Pair Programming Dynamic

Voice input is lower-friction than typing when a developer's hands are occupied with code — the developer speaks instead of context-switching to a text field, and the assistant responds audibly. Personality becomes far more noticeable in voice than in text. A flat, monotone voice assistant feels robotic in a way that flat text does not. A well-configured personality with appropriate pacing and word choice, on the other hand, creates a more natural collaboration rhythm.

Airi's Voice Architecture

Airi's voice pipeline uses WebSocket-based real-time audio streaming. The flow works like this:

1. The browser captures audio via getUserMedia.
2. A MediaRecorder streams chunks over a WebSocket to the server.
3. The server converts speech to text.
4. The agent runtime routes the transcript through the soul container.
5. A TTS engine synthesizes the soul-processed response into audio.
6. The server streams that audio back to the client for playback.

Important: getUserMedia requires a secure context (HTTPS or localhost). The component will fail on plain HTTP origins. Safari does not support audio/webm for MediaRecorder; the code below uses feature detection to fall back to audio/mp4. Requires React ≥16.8 (for hooks).

// VoiceChat.jsx — React voice interface component
import React, { useState, useRef, useEffect, useCallback } from "react";

const ALLOWED_WS_PROTOCOLS = ["ws:", "wss:"];

function VoiceChat({ wsEndpoint }) {
  const [response, setResponse] = useState("");
  const [isListening, setIsListening] = useState(false);
  const wsRef = useRef(null);
  const mediaRef = useRef(null);
  const audioRef = useRef(new Audio());

  useEffect(() => {
    // Validate endpoint before opening socket
    let parsed;
    try {
      parsed = new URL(wsEndpoint);
    } catch {
      console.error("[VoiceChat] Invalid wsEndpoint:", wsEndpoint);
      return;
    }
    if (!ALLOWED_WS_PROTOCOLS.includes(parsed.protocol)) {
      console.error("[VoiceChat] Disallowed WebSocket protocol:", parsed.protocol);
      return;
    }

    wsRef.current = new WebSocket(wsEndpoint);
    wsRef.current.onmessage = (event) => {
      try {
        const data = JSON.parse(event.data);
        if (data.type === "soul-response") {
          setResponse(data.text);
        }
        if (data.type === "audio-response" && typeof data.audioUrl === "string") {
          try {
            const audioUrlParsed = new URL(data.audioUrl);
            if (audioUrlParsed.protocol === "https:" || audioUrlParsed.protocol === "http:") {
              audioRef.current.src = data.audioUrl;
              const playPromise = audioRef.current.play();
              if (playPromise) {
                playPromise.catch((err) =>
                  console.warn("Autoplay blocked:", err)
                );
              }
            } else {
              console.warn("[VoiceChat] Rejected audio URL with unexpected protocol:", audioUrlParsed.protocol);
            }
          } catch {
            console.warn("[VoiceChat] Invalid audio URL received");
          }
        }
      } catch {
        console.warn("Unhandled WS message type");
      }
    };
    return () => {
      // Stop active recording before closing socket to prevent
      // ondataavailable firing on a closing socket
      if (mediaRef.current) {
        mediaRef.current.recorder?.stop();
        mediaRef.current.stream?.getTracks().forEach((t) => t.stop());
        mediaRef.current = null;
      }
      setIsListening(false);
      audioRef.current.pause();
      audioRef.current.src = "";
      wsRef.current?.close();
    };
  }, [wsEndpoint]);

  const startListening = useCallback(async () => {
    try {
      const stream = await navigator.mediaDevices.getUserMedia({
        audio: true,
      });
      // Safari requires audio/mp4; use feature detection
      const mimeType = MediaRecorder.isTypeSupported("audio/webm")
        ? "audio/webm"
        : "audio/mp4";
      const recorder = new MediaRecorder(stream, { mimeType });
      recorder.onerror = (e) => console.error("[VoiceChat] MediaRecorder error:", e.error);
      mediaRef.current = { recorder, stream };
      recorder.ondataavailable = (e) => {
        if (wsRef.current?.readyState === WebSocket.OPEN) {
          wsRef.current.send(e.data);
        }
      };
      recorder.start(250); // Send chunks every 250ms
      setIsListening(true);
    } catch (err) {
      console.error("Microphone access failed:", err);
      setIsListening(false);
    }
  }, []);

  const stopListening = useCallback(() => {
    if (mediaRef.current) {
      mediaRef.current.recorder?.stop();
      mediaRef.current.stream?.getTracks().forEach((t) => t.stop());
      mediaRef.current = null;
    }
    setIsListening(false);
  }, []);

  return (
    <div className="voice-chat">
      <button onClick={isListening ? stopListening : startListening}>
        {isListening ? "Stop" : "Speak"}
      </button>
      {response && <p className="soul-response">{response}</p>}
    </div>
  );
}

export default VoiceChat;

Example usage:

<VoiceChat wsEndpoint="ws://localhost:3001/voice" />

Use wss:// in production environments. The exact WebSocket route depends on your server configuration; consult the websocket-server package for available endpoints.

The component captures audio in 250ms chunks, streams them over the WebSocket connection, and renders both the text response and plays the audio response when the server returns the soul-processed result. The Audio element is reused across messages to avoid accumulating transient instances. Autoplay may be blocked by browser policy; consider triggering playback from a user interaction for more reliable results.

Handling Voice Personality Cues

Tone, pacing, and word choice in the soul configuration can map to TTS parameters. A soul with high encouragement might set the TTS rate parameter lower (e.g., 0.85 instead of the default 1.0) and shift pitch slightly upward (e.g., +2st in SSML or a pitch multiplier of 1.1) to produce a warmer delivery. A soul with high conciseness produces shorter utterances, which naturally speeds up the interaction cycle. Practical concerns include latency (each additional processing layer adds time), interruption handling (detecting when the developer starts speaking mid-response), and silence detection (distinguishing a thoughtful pause from the end of an utterance).

Implementation Checklist: Your Soul Design Playbook

Phase 1: Design

Start by pinning down the personality before writing any transformation code. Every trait you define here should directly map to a rule in Phase 2.

• Define 3 to 5 core personality traits with measurable values (0.0 to 1.0 scale)
• Map each trait to a specific response transformation rule
• Decide on memory persistence scope: session-only or long-term
• Document behavioral constraints: interrupt thresholds, silence conditions, escalation patterns
• Identify edge cases: what happens during urgent debugging, boilerplate generation, error cascades

Phase 2: Build

• Create soul configuration as a JSON or JavaScript module
• Implement transformResponse() middleware with all trait-driven transformations
• Add error boundaries and a fallback personality (raw passthrough)
• Write unit tests verifying personality consistency across varied inputs
• Test that the line limit, silence rules, and language softening behave deterministically

Phase 3: Integrate

• Register soul container with the agent runtime pipeline
• Connect voice interface via WebSocket if voice interaction is required
• Test with real coding scenarios: code review, debugging, scaffolding, refactoring
• Gather developer feedback on personality fit and friction points
• Iterate trait values based on usage data and session-length metrics

Lessons Learned and Architectural Trade-Offs

When Personality Helps vs. When It Gets in the Way

Strong personality configuration aids productivity in extended sessions: long debugging cycles, code review conversations, and architectural discussions. It becomes noise in situations demanding raw speed and minimal commentary, such as urgent production debugging or repetitive boilerplate generation. A "mute personality" mode, where the soul container is bypassed entirely and raw LLM output passes through, is not a nice-to-have. It is a necessary escape hatch. Designing a soul without a kill switch is a common mistake. To implement mute mode, bypass transform in registerSoul: transform: (raw) => ({ text: raw, soulId: 'passthrough' }).

Designing a soul without a kill switch is a common mistake. To implement mute mode, bypass transform in registerSoul: transform: (raw) => ({ text: raw, soulId: 'passthrough' }).

Performance Considerations

Every soul transformation layer adds latency. String manipulation, regex processing, and memory lookups are individually cheap but compound across high-frequency interactions — if you are processing dozens of responses per minute, aim for each soul transform to complete in single-digit milliseconds so total pipeline overhead stays under roughly 50 ms. We have not published formal benchmarks yet; profile in your own environment. Persistent personality state (tracking interaction history for stateful souls) consumes memory proportional to session length. Strategies for keeping the pipeline fast include caching trait-derived transformation rules at initialization rather than recomputing per request, setting hard timeouts on soul transformations, and falling back to passthrough if latency exceeds a defined threshold.

Where to Go From Here

Soul containers represent a missing architectural layer in agentic AI systems. They formalize what developers have been doing informally with system prompts, turning personality design into a composable, testable, and swappable engineering concern. Human-AI interaction design is becoming a first-class engineering discipline, not an afterthought. The Moeru-AI/Airi repository provides a concrete starting point. Fork it, build a custom soul, and test it against real coding workflows. This is one piece of a larger architecture for agentic systems where persistent, well-designed personality is not decoration but infrastructure.