Skip to content

CONCEPT Cited by 1 source

Clear-text name resolution

Definition

The bidirectional translation between a messaging platform's opaque identifiers (U07ABCDEF, #C04DEFGHI) and human-readable names (@alice, #engineering), applied automatically at the adapter boundary so that:

  1. Inbound — agent prompts contain clear text ("Alice mentioned you in #engineering"), giving the LLM context it can reason about.
  2. Outbound — when the agent emits clear text ("@alice please check"), the adapter rewrites it back to the raw platform ID so the platform actually fires the mention notification.

From Vercel's Chat SDK launch:

"Channel and user names are automatically converted to clear text so your agent understands the context of the conversation. This translation works in both directions. When the agent at-mentions somebody using clear text, Chat SDK ensures the notification actually triggers in Slack."

(Source: sources/2026-04-21-vercel-chat-sdk-brings-agents-to-your-users.)

Why this is load-bearing, not cosmetic

Chat platforms emit events containing raw IDs and require outbound messages to contain raw IDs for notifications to fire. But LLMs reason best about human-readable text. The failure modes if you skip the translation:

  • Inbound failure mode. Agent prompt reads "<@U07ABCDEF> said: are you there?". The model has no idea who U07ABCDEF is, can't distinguish U07ABCDEF from U09QWERTY in reasoning, confuses them, or hallucinates demographics. Prompt engineering can help (dumping a user-directory at the top of the prompt) but at the cost of context tokens and still loses the inline-ID readability.

  • Outbound failure mode. Agent emits "@alice please check". Slack renders the string literally — Alice does not get a notification. The message looks fine to the agent and the sender, but the person who needs to respond never finds out. This is a particularly insidious failure mode because the agent thinks it pinged Alice; there's no error to log.

Why this justifies the SDK even for single-platform bots

Even a Slack-only bot needs name resolution on both sides. The Chat SDK post uses this as a first-class justification:

"Even if your agent only targets Slack, Chat SDK still solves real problems. Channel and user names are automatically converted to clear text so your agent understands the context of the conversation."

This positions clear-text name resolution as the minimum-viable adapter benefit — the baseline reason to adopt Chat SDK even when the cross-platform story doesn't apply.

Resolution mechanics (inferred — not fully disclosed in post)

The post doesn't detail the implementation, but typical approaches:

  1. Inbound parse-and-lookup. On receiving a Slack event, scan the message text for <@UXXX> and <#CXXX> patterns; look up each ID against the workspace's user and channel tables; substitute the clear-text form in the normalised event.
  2. Outbound rewrite-and-resolve. On thread.post("@alice ..."), parse @alice tokens; look up the user by display name or email; rewrite to <@U07ABCDEF> on the wire.
  3. Caching. User and channel directories are large; production adapters cache lookups in the state layer (see patterns/pluggable-state-backend) with TTL-based invalidation.

Open questions the post doesn't address: - Disambiguation when two users share a display name — likely resolves by email or ID priority, but unspecified. - Cross-workspace federation — Slack Enterprise Grid has shared channels with users from multiple workspaces; how the adapter handles scope is unspecified. - Deleted / deactivated users — a <@U07ABCDEF> event from an inactive user: does resolution return the last-known name, a synthetic "deleted user" marker, or the raw ID?

Relation to context engineering

The inbound side of clear-text resolution is a basic form of concepts/context-engineering — reshaping what the LLM sees so it can reason well. The outbound side is a contract with the platform's notification system — the clear-text-to-ID rewrite is the bridge between LLM output and platform-level user-reach semantics.

Seen in

Last updated · 476 distilled / 1,218 read