Inside the Unified Persona System

Traditional AI assistants treat each conversation as isolated — a fresh start with no memory, no context, and no awareness of who they're talking to. Meggy takes a fundamentally different approach with its Unified Persona System: a single identity model that spans every channel, every agent, and every person.

This article explores the architecture behind it.

The Core Model: One Identity, Six Types

At the database level, every entity in Meggy — whether a person, the main bot, an autonomous agent, or an organization mentioned in a conversation — is stored in the same identities table with a unified schema:

Field Purpose
type human, bot, agent, org, place, or project
name / full_name Display and real-world names
role Trust tier (admin, family, friend, stranger, agent, etc.)
agent_id Links agent identities to their agent definition
confidence_score Identity match confidence (0–1.0)
OCEAN traits Five personality dimensions (0.0–1.0 each)
Communication style Seven communication sliders (0.0–1.0 each)
attributes Extensible JSON — includes channelPersonas for per-channel prompts

This unification means the same infrastructure that manages your family's knowledge graph also manages agent personas, with identical memory, search, and persona compilation pipelines. The non-person types (org, place, project) are created by the background learner to anchor relationships — so when Meggy hears "I work at NannerTech" it creates a NannerTech identity and connects you to it via a typed works_at edge, rather than flattening "NannerTech" into a bullet point.

Cross-Channel Identity Resolution

When someone sends a message to Meggy on any channel, the Persona Resolver runs a multi-step algorithm:

  1. Desktop shortcut — If the message arrives on desktop, it's immediately mapped to the admin identity.
  2. Direct match — Look up the sender's channel-specific ID (e.g., Telegram user ID) in the identity_channels table.
  3. Agent lookup — Search for an agent with a matching channel binding.
  4. Name fallback — If no channel match exists, try matching the display name against known identities.
  5. Auto-link — If a single name match is found, the new channel is automatically linked.
  6. Stub creation — If nothing matches, create a new identity with role unknown and notify the owner.

This layered approach means Meggy can handle the first message from a new number gracefully while avoiding duplicates for known contacts.

The Agent Identity Bridge

When you create an agent in Meggy — say, a Telegram community manager — the system automatically creates a corresponding identity row in the identities table. This is handled by the Agent Identity Bridge:

On first boot after updating to the unified system, two migrations run in sequence: migrateExistingAgents() creates identity rows for any pre-existing agents that don't have one, and migrateAgentPersonalityToIdentity() then copies each agent's legacy personalityMarkdown field into the linked identity (only when the identity has no real persona content yet). Once migrated, every persona edit flows through the identity store directly via the unified editor on the agent's Configure tab.

Per-Deployment Personas

Once you start deploying an agent — running multiple copies of the same blueprint, each with its own channel binding (e.g. one Telegram bot for NannerTech, a second for AcmeCo) — every deployment also gets its own identity row. The agent's "Default persona" on the Configure tab is the template new deployments inherit when they're created; once cloned, each deployment has an independent persona you edit from Deployments → Settings → Personality. The Personality card autosaves and is wired through a parallel migration (migrateInstancesToIdentities) so existing deployments are seeded from their blueprint on first boot.

At runtime, persona resolution prefers the deployment's identity over the blueprint's, so JoJo on Telegram can sound friendly while Steve on Telegram (same blueprint) sounds formal — without forking the blueprint itself. Editing the Default persona only affects future deployments, never the ones that already exist.

Per-Channel Personas

Agents can have different "personalities" per channel. This is stored in the identity's attributes.channelPersonas map:

{
  "telegram": "You are a friendly community manager. Keep it casual.",
  "email": "You are a professional assistant. Use formal language.",
  "discord": "You are a helpful Discord bot. Use markdown."
}

During prompt assembly, the generation service injects the matching persona based on the incoming channel.

Memory Provenance

Every fact that Meggy learns carries a source object with channel provenance:

{
  "tool": "deep_pass",
  "channel": "telegram",
  "speakerId": "abc-123-def"
}

This means you can trace exactly where each piece of knowledge came from. Tell Meggy on Telegram that you love Chinese food, and the memory records that it was learned on Telegram. The value of this goes beyond transparency:

Identity Merge & Conflict Detection

Over time, the same person might end up with two identity records — perhaps they texted from a new phone number, or their name was spelled differently. The system handles this in two ways:

Heartbeat Conflict Detection

During regular maintenance sweeps (the "heartbeat"), detectIdentityConflicts() scans for:

Detected conflicts are stored and surfaced as notifications for the admin to review.

Identity Merge

When a merge is confirmed (manually or via auto-detection), mergeIdentities():

  1. Reassigns all memories from the secondary identity to the primary
  2. Moves all channel bindings to the primary identity
  3. Deletes the secondary identity record

All operations are transactional — either the merge completes fully or nothing changes.

Persona Compilation Pipeline

When Meggy generates a response, the Persona Compiler assembles the system prompt through a 4-layer pipeline:

  1. Directives — Base system instructions and behavioral rules
  2. Bot Persona — The bot's personality markdown (name, traits, constitution)
  3. Channel Persona — Per-channel personality overlay (if configured)
  4. Memory Context — Relevant facts, relationships, and episodes retrieved via hybrid search

Each layer has a configurable token budget, ensuring the system prompt stays within model context limits even as the knowledge graph grows large.

Unified Memory Engine

Agents, bots, and humans all share the same memory infrastructure:

What Makes This Different

Most AI platforms treat identity as an afterthought — a user ID attached to a chat session. Meggy's approach is different:

Traditional AI Meggy
One identity per session One identity per entity, across all sessions and channels
No agent identity Agents are first-class citizens with their own personas
Memory is session-scoped Memory is identity-scoped with channel provenance
No identity resolution Multi-step resolution with auto-linking
No conflict handling Heartbeat-driven conflict detection and merge

The result is an AI that genuinely knows who it's talking to — and remembers what it learned, no matter where the conversation happened.