Problem
When Junior embeds prior Slack thread context, participant identity is not guaranteed to survive into the model-facing transcript. The bot can therefore treat prior messages as generic users and fail to know who reported something, who is asking now, or which person a follow-up refers to.
Observed concern: in multi-person Slack threads, Junior seems to never know people by username or display name when using prior thread context.
Current behavior to investigate
ConversationMessage.author can store userId, userName, and fullName.
- Prior thread context rendering prefers
fullName, then userName, then falls back to the role label.
- Backfilled and persisted prior messages appear to rely on whatever author fields the Chat SDK message already has.
- The current requester has a Slack profile lookup fallback, but older/prior thread participants are not clearly hydrated before the embedded transcript is built.
- When names are missing, the rendered context can collapse distinct humans into generic
user attribution instead of at least preserving a stable Slack user id.
Desired contract
Prior thread context should always preserve a stable person identity for every human-authored message.
- Prefer Slack display name or real name when available.
- Include username when available.
- Always include or fall back to Slack user id so distinct people do not collapse into
user.
- Hydrate missing names for prior participants through the existing Slack user lookup path, without refetching full Slack thread history on every turn.
- Preserve the distinction between the original reporter, later participants, and the current requester.
Suggested acceptance criteria
- A thread with Alice posting an earlier message and David later asking Junior to act embeds Alice as Alice or
U_ALICE, not as generic user.
- The current requester remains separately represented in the per-turn requester context.
- Stored conversation state remains the canonical source for prompt context, consistent with the Slack context sourcing contract.
- Add deterministic coverage for missing
userName and fullName fields in prior thread messages.
- Add or update an integration/eval scenario that proves reporter/requester attribution survives a multi-user Slack thread.
References
Relevant areas:
packages/junior/src/chat/services/conversation-memory.ts
packages/junior/src/chat/runtime/turn-preparation.ts
packages/junior/src/chat/runtime/reply-executor.ts
packages/junior/src/chat/slack/user.ts
specs/slack-agent-delivery-spec.md
Problem
When Junior embeds prior Slack thread context, participant identity is not guaranteed to survive into the model-facing transcript. The bot can therefore treat prior messages as generic users and fail to know who reported something, who is asking now, or which person a follow-up refers to.
Observed concern: in multi-person Slack threads, Junior seems to never know people by username or display name when using prior thread context.
Current behavior to investigate
ConversationMessage.authorcan storeuserId,userName, andfullName.fullName, thenuserName, then falls back to the role label.userattribution instead of at least preserving a stable Slack user id.Desired contract
Prior thread context should always preserve a stable person identity for every human-authored message.
user.Suggested acceptance criteria
U_ALICE, not as genericuser.userNameandfullNamefields in prior thread messages.References
Relevant areas:
packages/junior/src/chat/services/conversation-memory.tspackages/junior/src/chat/runtime/turn-preparation.tspackages/junior/src/chat/runtime/reply-executor.tspackages/junior/src/chat/slack/user.tsspecs/slack-agent-delivery-spec.md