## Summary Agents show up in a lot of places now, not just discussions. MR creation, pipeline fixes, vulnerability resolution, issue comments, sessions triggered from Chat. Each of these grew its own pattern for showing "an agent did this" or "an agent is doing this." Users have no consistent way to recognize agent activity, tell if it's still running, or trace a result back to the session that produced it. This epic extends the discussion-trigger work into a general pattern in #22699, any place an agent can act needs a consistent way to show state (thinking, done, failed, needs input) and a consistent way to link back to the originating session. ## Problem Right now agent visibility is different everywhere: - Discussions have thread-level and inline triggers with different visual treatments (see original exploration) - MRs created by agents have no clear "an agent made this" marker - Pipeline fixes don't show session linkage in the pipeline UI - Vulnerability resolution flows link out inconsistently - Session badges on issue boards exist but aren't reused elsewhere - Attribution is inconsistent too, and it's visible in the UI. Chat/local changes only credit the user. Flow-created issues and comments credit the service account. Flow commits split attribution between user and service account (committer vs. author). MRs credit the user for compliance reasons. Users see different attribution logic depending on which surface they're on, with no shared rationale. Without a shared pattern, every team building an agent touchpoint reinvents this, and users have to relearn the signal each time. ## Goal One consistent visual language for: - Agent is working (thinking/running state) - Agent finished (success, failure, needs input) - Traceability back to the session (a link/badge that's recognizable wherever it shows up) - Attribution: a consistent answer to "who/what made this change" across surfaces, reconciled with compliance requirements where they apply (e.g. MR authorship) ## Design Discussion-trigger pattern #22699 is the starting reference point: - New thread trigger: appended button mimicking collapsed-replies header, opens session panel - In-thread trigger: inset button mimicking message structure - Completed response: low-visibility "Session" link on hover/focus, promotable to ellipsis menu or more prominent placement depending on usage data This epic asks: does this pattern (or a variant of it) hold up when applied to: - MR headers/descriptions created by agents - Pipeline job/stage views for agent-triggered fixes - Vulnerability dashboard and MR-linked resolution flows - Any future touchpoint ## Open questions - Do all touchpoints need the same visual weight, or does a pipeline fix warrant something different from an inline chat response? - Is the "Session" link/badge itself a reusable component, or does it need surface-specific variants? - How do failure and needs-input states get represented consistently across surfaces that have very different existing UI (chat thread vs. pipeline job list)? - Can attribution and traceability share one visual pattern, or are they separate signals that happen to show up in the same spot? - Where compliance requires user attribution (MRs), how do we still surface the agent's role without conflicting with that? ## Scope for this epic - Audit existing agent touchpoints and their current visual treatment - Audit current attribution logic per surface (chat/local, flow-created issues/comments, flow commits, MRs) alongside the visual-treatment audit - Define the shared component/pattern (states + traceability link) - Roll out to at least 2-3 non-discussion surfaces as validation (MR creation, pipeline fix, one more TBD) - Document the pattern so future touchpoints inherit it by default instead of reinventing