Skip to content

feat(backend): include identified people's names in conversation titles (#3602)#8497

Open
ZachL111 wants to merge 4 commits into
BasedHardware:mainfrom
ZachL111:zach/conversation-title-names
Open

feat(backend): include identified people's names in conversation titles (#3602)#8497
ZachL111 wants to merge 4 commits into
BasedHardware:mainfrom
ZachL111:zach/conversation-title-names

Conversation

@ZachL111

@ZachL111 ZachL111 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Conversation titles now reliably include the names of the people identified in the conversation, not just for scheduled calendar meetings. This addresses #3602, where titles should contain the correct participant names (Granola style, for example "Sarah and John Discuss Q2 Budget") so the conversation list is scannable.

What was missing

The two structuring functions in utils/llm/conversation_processing.py (get_transcript_structure and get_reprocess_transcript_structure) already render identified speakers by name in the transcript they pass to the model. The instruction to put participant names in the title, however, was gated entirely on CALENDAR MEETING CONTEXT ("If CALENDAR MEETING CONTEXT is provided with participant names ... naturally mention them in the title").

For an ordinary conversation that was not a scheduled calendar meeting but does have identified speakers (a segment person_id resolved to a saved person), the model saw the names in the transcript but was only told to write a generic headline. There was also no explicit, authoritative list of the known names, so the model had nothing to anchor on and no instruction against guessing a name.

Fix

  • Added a small helper identified_participant_names(people) that returns an ordered, de-duplicated list of the names of the people identified in the conversation.
  • _build_conversation_context now injects an IDENTIFIED PARTICIPANTS line listing those names, so the model gets an explicit roster ahead of the transcript.
  • Generalized the title and overview instructions in both structuring functions so the name guidance fires whenever participant names are known (from the identified participants or from calendar context), not only for calendar meetings.
  • Added an explicit correctness guard: use only names that were actually provided, never invent or guess a name, and never use "Speaker 0" or "Speaker 1" in the title. This covers the "and they are correct" half of the issue.
  • process_conversation._get_structured derives the roster from the people it already fetches and threads it through the normal, reprocess, and external audio paths. The reprocess path leaves a user set title unchanged and only name enriches a fresh title.

The new instruction text is static, so it stays in the cached system prefix; the per conversation roster goes in the dynamic context message, so OpenAI prompt caching is unaffected. The new parameter is optional on every function, so existing callers are unchanged.

Testing

  • New tests/unit/test_conversation_title_names.py (12 tests): the roster helper (ordering, de-duplication, blank and missing name handling), the IDENTIFIED PARTICIPANTS injection in _build_conversation_context, the name in title instruction being present without calendar context, and the roster actually reaching the model for both structuring functions. Registered in test.sh.
  • Proven red against the pre change version (11 of 12 fail without the change), green after.
  • tests/unit/test_conversation_structure_timezone.py and tests/unit/test_prompt_caching.py still pass (36 tests), confirming no regression to timezone handling or prompt cache determinism.

Refs #3602.

Review in cubic

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 4 files

Confidence score: 5/5

  • Automated review surfaced no issues in the provided summaries.
  • No files require special attention.

Re-trigger cubic

@Git-on-my-level

Copy link
Copy Markdown
Collaborator

Thanks @ZachL111 — this is a nicely scoped take on #3602. Quick review notes:

What I like

  • Directly addresses the issue: conversation titles now include the names of identified participants (not just for calendar meetings), Granola-style.
  • Clean, minimal change: one small identified_participant_names() helper, threaded through the two structuring functions and the shared context builder.
  • Good correctness guard: the prompt is explicitly told to use only names that were actually provided and never to invent or guess (no "Speaker 0" in titles). That's the right instinct for "and they are correct".
  • Tests are thorough — roster de-dup/whitespace/empty handling, context injection order, prompt wording is not calendar-gated, and an end-to-end check that the roster actually reaches the model invocation in both get_transcript_structure and get_reprocess_transcript_structure.

Observations for a human maintainer

  • This changes LLM prompt behavior for every structured conversation, not just the name feature. Worth a quick product check that the generalized title/overview wording still produces good headlines when there are no identified participants (the common case), and that the new instruction block doesn't dilute other guidance.
  • identified_participant_names relies on person.name already being populated upstream by speaker-to-person matching; if that matching is unreliable, names in titles will inherit that unreliability. Not a blocker for this PR — just noting the dependency.
  • No new data leaves the system: these names already reach the model via the transcript today; this just provides an explicit, authoritative roster ahead of it.

I'm leaving this for a maintainer to approve/merge rather than approving myself, since it's a user-facing prompt/product behavior change. Labeling for feature-fit and maintainer review.

@Git-on-my-level Git-on-my-level added feature-fit-review PR touches feature direction; qualitative fit assessed needs-maintainer-review Needs a human maintainer to review/approve (e.g. stacked, product, or architecture judgment) labels Jun 28, 2026

@kodjima33 kodjima33 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backend feature: include identified people's names in conversation titles — approve only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature-fit-review PR touches feature direction; qualitative fit assessed needs-maintainer-review Needs a human maintainer to review/approve (e.g. stacked, product, or architecture judgment)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants