Python: Feature Request: Built‑in abstraction for conversation creation / IDs (remove need to directly use OpenAI client)

[sebafo]

Summary
When using the framework with Azure AI (or any provider via AzureAIClient), devs still need to reach for a raw OpenAI client just to create a conversation and obtain an ID. Everything else then routes through AzureAIClient. This creates an unnecessary provider coupling and extra boilerplate.

Current (boilerplate) pattern

# Create a conversation using OpenAI client only to get an ID
openai_client = project_client.get_openai_client()
conversation = await openai_client.conversations.create()
conversation_id = conversation.id

# Then do all subsequent work via AzureAIClient
azure_client = project_client.get_azure_ai_client()
# ... use conversation_id in downstream calls ...

Pain Points

• Requires pulling in the OpenAI client even when the app otherwise standardizes on AzureAIClient.
• Leaks provider specifics into app code and complicates dependency injection/testing.
• Extra initialization paths (auth/config) just to mint a conversation ID.

---

✅ Proposal

Introduce a provider-agnostic conversation service in the framework that:

1. Creates and returns a conversation (ID + metadata) without the app needing a provider-specific SDK.
2. Normalizes conversation identity (ID format, TTL/metadata) across providers.
3. Works via the project’s configured client (AzureAIClient, OpenAI, etc.), but exposes a single framework API.

API Sketch (Python)

Option A: extend project_client

conversation = await project_client.conversations.create()  # provider-agnostic
conversation_id = conversation.id

Option B: a dedicated facade

from agent_framework.conversations import Conversations

convs = Conversations(project_client)
conversation = await convs.create()
conversation_id = conversation.id

---

🧭 Behavior & Routing

• The framework reads the active provider from the project/client configuration and calls the right backend (OpenAI/Azure OpenAI/Azure AI Foundry, etc.).
• If the provider supports server-side conversation objects, it creates one remotely and returns the ID.
• If the provider does not have first-class conversations, the framework emulates via a framework-scoped ID and optional storage adapter (e.g., pluggable persistence).

---

[markwallace-microsoft]

Adding @westey-m so we have consistent behaviour between .Net and Python

[eavanvalkenburg]

This touches on ChatClients so would need to be synced into MEAI as well, and I think was already discussed there @markwallace-microsoft @westey-m @stephentoub

Having said that, I think it makes sense to do some abstraction around service side thread creation.