[FEATURE] Add omnichannel support to Agent Kernel - unified customer identity and conversation context across channels

[ishands]

Feature Description

Add omnichannel support to Agent Kernel — unified customer identity and conversation context across channels. Today AK is multi-channel (many channels, each siloed). This feature makes it omnichannel: an agent on any channel can see what happened on any other channel for the same user, without the customer repeating themselves.

Problem Statement

The term omnichannel emerged around 2010–2011 to describe a shift from multi-channel (independent, siloed channels) to a model where all channels are integrated into a single, cohesive experience. The Latin prefix omni- ("all", "universal") is deliberate — customer identity and conversation context are universally available regardless of which channel the customer arrives through.

Leading CX platforms — Zendesk, Genesys, Zoho Desk — all define omnichannel by one test: can an agent on channel B see what happened on channel A, without the customer repeating themselves?

AK currently fails this test. Sessions are keyed by a conversation-scoped UUID, not by user identity. A user contacting via WhatsApp and then calling the next day are two unrelated session threads — the second agent has no memory of the first conversation.

Concrete example (telco contact centre):

1. Sub (Subscriber) X contacts via WhatsApp → agent raises service ticket #1234, stored in session
2. Sub X calls the contact centre next day → voice agent has zero context of ticket #1234
3. Sub X must repeat themselves — the omnichannel promise is broken

Root causes:

• No user identity layer — channel-specific IDs (WhatsApp sender, phone number, Slack user ID) are never resolved to a canonical customer ID
• SessionStore is keyed by session_id — no user_id concept exists in the session model
• No cross-channel session lookup — even when deployments share a Redis backend, there is no API to load "the session for user X across channels"
• Channel handlers (AgentWhatsAppRequestHandler, etc.) do not carry or resolve user identity before invoking the runtime

Proposed Solution

1. Pluggable Identity Resolver

An optional interface in channel handlers that maps a channel-specific identifier to a canonical user_id before session lookup. AK provides the interface; implementation is left to the integrator (CRM lookup, customer DB, etc.):

class IdentityResolver(ABC):
    @abstractmethod
    def resolve(self, channel: str, channel_user_id: str) -> str:
        """Map a channel-specific ID to a canonical customer/user ID."""
        ...

Channel handlers call this before AgentService.select(), using the resolved user_id to drive session lookup instead of a fresh UUID.

2. User-Scoped Session Lookup

Extend SessionStore with a user-scoped lookup:

class SessionStore(ABC):
    def load_by_user(self, user_id: str) -> Session | None:
        """Load the most recent session for a given user, across all channels."""
        ...

3. Cross-Channel Context

No structural change to the session model is required. The non-volatile KV cache already supports arbitrary data. Once sessions are user-scoped and identity is resolved, conversation context (e.g. ticket #1234) is naturally available to any channel loading the same session.

Alternative Solutions

• External session coordination — integrators can today build cross-channel context by using a shared Redis backend and managing session IDs externally. This works but requires every AK deployer to solve the same problem themselves, with no AK-level support or convention.

• Middleware pre-hook — identity resolution could be implemented as a PreHook rather than a channel handler concern. This is more flexible but puts the burden entirely on the developer with no guidance from the framework.

The proposed solution is preferred because it establishes a clear, reusable interface at the right layer (channel handler) and keeps the session model
consistent.

Use Case

Primary: Contact centre / customer support
A customer raises an issue via WhatsApp. The next day they call in. The voice agent immediately sees the WhatsApp conversation, the ticket raised, and the current status — without the customer repeating a word. This is the baseline expectation of any platform marketed as omnichannel.

Secondary: Any multi-channel bot deployment
A user configures a Telegram bot for daily updates and also interacts via Slack at work. Preferences set on one channel (watchlist, notification settings, prior recommendations) are available on the other.

Who benefits: Any AK deployment where the same end-user may contact through more than one channel — contact centres, customer support bots, personal assistant bots, financial advisory agents.

Additional Context

This feature closes the gap between AK's current multi-channel capability and the omnichannel standard defined by the CX industry. Without it, AK cannot be accurately described as omnichannel in product or sales material.

Scope clarification:

• This is not a CRM. Identity resolution logic (WhatsApp phone ↔ customer ID) is an integration concern — AK provides the interface, not the implementation.
• This is not a replacement for LangGraph-style HITL or graph-level memory. Scope is strictly session continuity across AK channel handlers.

References:

• Zendesk: What is an omnichannel contact center?
• Genesys: What is Omnichannel Customer Experience?
• Genesys: Omnichannel vs Multichannel — improving customer journeys
• Zoho Desk: Omnichannel Customer Service

[manoj-alpaca]

@ishands if we implement IdentityResolver then the session is loaded from the returned value (common identity) from the resolver no?

i dont understand the second change you have proposed under "User-Scoped Session Lookup"

[ishands]

IdentityResolver answers: "who is this user?" — maps (whatsapp, +6512345678) → customer-42

But today's SessionStore only has: load(session_id: str) — keyed by UUID, not user_id.

So after the resolver gives you customer-42, you still have no way to ask the session store: "give me the session for customer-42". The store only understands session UUIDs, not user IDs.

load_by_user(user_id) is the missing bridge — it lets the store answer: "here's the most recent session associated with this user, regardless of which channel created it."

The flow would be:

WhatsApp webhook arrives with sender +6512345678
  → IdentityResolver.resolve("whatsapp", "+6512345678") → "customer-42"
  → SessionStore.load_by_user("customer-42") → Session (may have been created via Telegram yesterday)
  → Runtime.run(agent, session, requests)

Without load_by_user, the resolver gives you an identity, but the session store can't do anything with it — you'd still end up creating a fresh session every time.

Hope this makes sense.