Summary:

1. Yes — result retrieval is tied to the query’s credential/delegation model. Your 404/500 messages point to missing or unresolved permission delegation for those stored results, not missing CAN MANAGE on the space. If you need a monitoring service principal to read results consistently, the safest pattern is to run the Genie/API workload under a shared service-principal identity rather than per-end-user delegated credentials.

2. Genie Chat Sharing matters. When enabled, and when a conversation is set to Reviewable by space managers, users with CAN MANAGE can review the full conversation/results; if the conversation is Private, managers can see prompts but not results. Existing conversations created before the feature was enabled stay Private; new ones default to Reviewable by space managers after enablement.

3. The 500 DATA_LOSS / “permission delegation name” looks like a backend issue or mis-propagated sharing/delegation state. The wording matches internal delegation plumbing, where the delegation name must be persisted and later assumed; if it is missing, retrieval can fail exactly this way.

Recommendation:

• Turn on Workspace Admin → Previews → Genie Chat Sharing.
• Ensure the conversations you want monitored are Reviewable by space managers (or All account users), not Private.
• For reliable machine monitoring, prefer a shared SP-run integration that creates/reads the conversations itself.
• For the failing 500/404 cases, open a support/engineering ticket with the request_ids — this likely needs server-side investigation of missing delegation metadata.

Most likely root cause in your case: those conversations/results were created without a retrievable delegation context for the monitoring SP. Enabling Chat Sharing helps manager visibility, but if the stored delegation metadata is missing, you’ll still need a backend fix for those affected conversations.