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.
At the database level, every entity in Meggy — whether a person, the main bot, or an autonomous agent — is stored in the same identities table with a unified schema:
| Field | Purpose |
|---|---|
type |
human, bot, or agent |
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.
When someone sends a message to Meggy on any channel, the Persona Resolver runs a multi-step algorithm:
identity_channels table.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.
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:
syncAgentToIdentity() — Creates an identity row with type: 'agent' and links it via agent_idupdateAgentIdentity() — Syncs name and personality changes from the agent definition to the identitydeleteAgentIdentity() — Removes the identity row, cascading to memories and channel bindingsOn first boot after updating to the unified system, migrateExistingAgents() runs once to create identity rows for all pre-existing agents.
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.
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:
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:
During regular maintenance sweeps (the "heartbeat"), detectIdentityConflicts() scans for:
Detected conflicts are stored and surfaced as notifications for the admin to review.
When a merge is confirmed (manually or via auto-detection), mergeIdentities():
All operations are transactional — either the merge completes fully or nothing changes.
When Meggy generates a response, the Persona Compiler assembles the system prompt through a 4-layer pipeline:
Each layer has a configurable token budget, ensuring the system prompt stays within model context limits even as the knowledge graph grows large.
Agents, bots, and humans all share the same memory infrastructure:
identity_id, so different people's (and agents') facts don't mixlistMemoriesShared() enables a synthesis view across all identitiesMost 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.