.NET: [Bug]: Foundry-backed Agent sessions surface `resp_*` history IDs instead of Foundry `conv_*` conversation IDs

[brandonh-msft]

Description

• What happened?
  When using Azure AI Foundry-defined server-side agents through the .NET Agent Framework AzureAI adapter (AIProjectClient.AsAIAgent(...)), ChatClientAgent.CreateSessionAsync(...) yields a ChatClientAgentSession whose ConversationId is a resp_* value. In the Foundry UI playground, the same backing agent produces conversation records with conv_* identifiers. Attempting to resume or interoperate with a conv_* copied from the Foundry UI fails because the Agent Framework path expects or returns resp_* semantics instead.

• What did you expect to happen?
  For Foundry-backed agents, either:

1. ChatClientAgentSession.ConversationId should represent the same durable Foundry conversation identifier exposed by the Foundry UI (conv_*), or
2. The SDK should expose a separate, documented API for the true Foundry conversation ID and clearly document that ConversationId is actually a Responses/history continuation handle.

• Steps to reproduce the issue

1. Create or use an existing Foundry-defined agent in Azure AI Foundry.
2. Open the agent in the Foundry playground and send a message. Observe a conversation record with a conv_* identifier in the UI.
3. From .NET, create an AIProjectClient and wrap the same server-side agent with AIProjectClient.AsAIAgent(...).
4. Call CreateSessionAsync(cancellationToken) or CreateSessionAsync(existingId, cancellationToken) on the resulting ChatClientAgent.
5. Send a message via RunStreamingAsync(...).
6. Inspect ChatClientAgentSession.ConversationId. It is a resp_* value rather than the conv_* style conversation identifier shown by the Foundry UI.
7. Attempt to pass the Foundry UI conv_* identifier back into the Agent Framework session creation path. The backend rejects it or otherwise expects resp_* continuation semantics instead.

Code Sample

using Azure.AI.Projects;
using Azure.AI.Projects.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.AzureAI;

TokenCredential credential = new DefaultAzureCredential();
var projectClient = new AIProjectClient(new Uri(projectEndpoint), credential);

AgentReference agentReference = new(name: agentName, version: agentVersion);
ChatClientAgent agent = projectClient.AsAIAgent(agentReference, tools: [], clientFactory: null, services: null);

AgentSession session = await agent.CreateSessionAsync(cancellationToken);
ChatClientAgentSession chatSession = (ChatClientAgentSession)session;

Console.WriteLine($"ConversationId: {chatSession.ConversationId}");

await foreach (AgentResponseUpdate update in agent.RunStreamingAsync("hello", chatSession, cancellationToken: cancellationToken))
{
    Console.Write(update.ToString());
}

Error Messages / Stack Traces

When a conv_* identifier copied from the Foundry UI is used as the continuation identifier for Agent Framework session creation, the backend rejects it and effectively expects a resp_* identifier.

Separately, when creating a new session and inspecting ChatClientAgentSession.ConversationId, the returned value is resp_* instead of conv_*.

Package Versions

Microsoft.Agents.AI: 1.0.0-rc4, Microsoft.Agents.AI.AzureAI: 1.0.0-rc4, Azure.AI.Projects: 2.0.0-beta.1

.NET Version

.NET 10.0

Additional Context

Additional context:

• This was observed against a Foundry-defined server-side agent, not a locally implemented custom agent.
• The Agent Framework docs say ChatClientAgent.CreateSessionAsync(string) continues an existing conversation and that ChatClientAgentSession.ConversationId is the ID of the underlying service chat history.
• The AzureAI adapter docs for AIProjectClient.AsAIAgent(...) explicitly describe it as wrapping an existing server-side agent as a ChatClientAgent.
• What is missing is clarity or API support for the Foundry UI-style durable conversation object (conv_*) when using the .NET Agent Framework adapter.
• This gap makes it hard to interoperate between Foundry UI conversations and Agent Framework-based clients, and it makes the meaning of ConversationId ambiguous.
• If this is intentional, the docs should say explicitly that the AzureAI adapter surfaces a Responses/history identifier rather than a Foundry conversation-object identifier.
• If it is not intentional, the SDK needs a way to retrieve and resume the actual Foundry conversation ID used by the Foundry playground.
• I can attach a screenshot showing the Foundry UI creating a conv_* record while the same agent accessed through Agent Framework surfaces resp_* as the session history identifier."

[brandonh-msft]

In this screenshot, the only trace with a conversation id was created by the Foundry Agent Playground. All others, done via Agent Framework, have no conversation ID associated with them.