@bastirehm I agree - this is primarily an audit/compliance requirement, not a real-time observability need. For most debugging scenarios, developers care about what the agent did and why it failed, not which prompt template version was used. But for compliance teams under FCA/PRA/DORA/EU AI Act, this traceability is critical - they need to prove which exact prompt and model governed a specific output.

Recommendation:

1. Audit events first - Include prompt version + model version in audit events and SIEM streaming logs. This addresses the core compliance need for regulated customers (NatWest, Eurafric, etc.). @khornergit does this fit with the AI governance SKU direction?
2. Session view later - We can incorporate prompt/model version in session metadata as a follow-up. It's occasionally useful for regression debugging ("it worked yesterday, why not today?"), but not critical for day-to-day troubleshooting.

cc: @fsieverding

thanks @Sam_Reiss LGTM - clean hierarchy and the suggestion actions as cards is a nice tough. We do need to validate technical feasibility on the mapping between error taxonomy (if we can do it) with UX CTA. Based on that input, we can iterate on the UX as we planned. cc: @bastirehm

Frances Wang (6f83e236) at 13 Mar 20:19

Frances Wang (b31be7f9) at 13 Mar 20:18

thank you Fiona. @bastirehm can you review and approve on your end before Monday 11am ET?

this is a good callout. we'll likely require a holistic documentation review/update for DAP free tier launch. cc: @amandarueda @cersoz

cc: @fneill FYI as this will be the Gitlab doc link for gitlab-com/www-gitlab-com!142859 (merged)

cc: @romaneisner for visibility

cc: @rcarter3 @karishmakumar headsup about this release note for 18.10

Hey @igor.drozdov @bastirehm - thanks for the discussion - very helpful. Before we align on the UX, I want to make sure we're on the same page about the setting scope.

My understanding: The MCP setting (ON/OFF) on the Duo Settings page is at instance/TLG level. When OFF, MCP is disabled for that entire scope.

Clarifying question: @igor.drozdov - you mentioned "groups may have MCP enabled or disabled" - does this mean MCP settings can vary at the group level within a TLG? Or were you referring to different TLGs having different settings? If the former, does it mean we want to expand this setting to subgroup/project level as well?

I agree that hiding at creation isn't the best approach - settings can change after creation regardless of scope as per @bastirehm 's callout, so we need to surface status at BOTH creation and runtime to provide users the visibility. The UX approach will depend on the answer above, so want to confirm our shared understanding first.

cc: @amandarueda