.NET: Discuss provider-agnostic conversation creation API

[eavanvalkenburg]

Summary

Issue #2931 is being addressed first with a Python FoundryAgent convenience method that mirrors the existing .NET FoundryAgent conversation-session API. A broader provider-agnostic conversation creation API should be designed separately and in sync across Python and .NET before implementation.

Problem

Some providers expose server-side conversation/session creation, but application code currently has to reach into provider SDKs to create those conversations. A framework-level abstraction could reduce provider coupling, but it would need to align across languages and avoid confusing local AgentSession.session_id with provider continuation state.

Scope to discuss

• Whether Agent Framework should expose a provider-agnostic conversation/session creation API.
• What the API shape should be in Python and .NET.
• How created provider conversation IDs should map onto AgentSession state.
• How this relates to service-managed history, A2A context_id/task_id, AG-UI thread_id/run_id, and telemetry correlation.

Non-goals for the first Python fix

• Do not block the direct Python FoundryAgent method for Python: Feature Request: Built‑in abstraction for conversation creation / IDs (remove need to directly use OpenAI client) #2931.
• Do not introduce a Python-only provider-agnostic facade before syncing with .NET.

Related: #2931, #4673, #4893.