Python: AG-UI snapshot replay with service sessions blocks Foundry Hosted Agents

[djw-bsn]

AgentFrameworkAgent currently accepts both use_service_session=True and a
snapshot_store.

The basic service-session path works correctly when the Foundry-generated
conv_* ID is used as threadId, snapshots are disabled, and the client sends
only incremental input. The issue is specifically introduced by combining that
working service-session path with AG-UI snapshot persistence.

On the second request, the AG-UI runner:

1. reconstructs the complete stored transcript from the thread snapshot, and
2. creates AgentSession(service_session_id=threadId).

The wrapped agent therefore receives both a provider continuation handle and
explicit prior conversation history. Some providers may tolerate this. Foundry
Hosted Agents do not accept the replayed assistant input, so this combination
breaks hosted-agent continuation through AG-UI.

This appears inconsistent with the package's documented “one State Authority”
model and is analogous to #4292, where AgentExecutor retaining
service_session_id during full-history replay creates competing continuation
sources. PR #7682 does not cover AG-UI because AG-UI invokes the agent through
agent_framework_ag_ui._agent_run.run_agent_stream.

Could the intended contract for this option combination be clarified? If
service-session mode is authoritative, AG-UI should likely pass only incremental
input to the provider while retaining complete snapshot messages for client
hydration. If snapshot replay is authoritative, AG-UI should clear the service
session ID or reject the ambiguous configuration.

Blocking integration scenario

This blocks multi-turn applications using this public integration stack:

AG-UI client
    -> Agent Framework Python AgentFrameworkAgent
    -> Agent Framework FoundryAgent
    -> Foundry Hosted Agent using the Responses protocol

It does not block applications that can use the Foundry-generated conv_* as
their public AG-UI thread ID, send only incremental turns, and do not require
Agent Framework snapshot persistence. Those applications can use
use_service_session=True without the snapshot store.

The blocked case needs both:

• Foundry service-managed conversation history for hosted-agent provider calls;
• Agent Framework AG-UI snapshots for backend-owned UI hydration, approvals, or
  other replayable thread state.

Foundry documents different responsibilities for hosted-agent conversations and
sessions:

• a conversation ID is the durable conversation-history record;
• a session ID identifies hosted compute and persisted filesystem state;
• under the Responses protocol, conversation ID is the primary continuation
  concept and the platform associates compute session state with it.

The application therefore needs AG-UI to retain complete messages for UI
hydration while invoking the hosted agent incrementally through its Foundry
conversation. With use_service_session=True and snapshots enabled, the current
runner instead sends the conversation ID together with reconstructed prior
assistant history.

Observed compatibility differs by Foundry agent type:

• Prompt-based Foundry agents accept replayed conversation messages and can
  continue under snapshot-authoritative history.
• Hosted Foundry agents using Responses reject the reconstructed assistant
  message input with HTTP 400 schema validation.
• Hosted continuation succeeds when a Foundry conversation is used with only
  incremental input.

No incorrect prompt-agent behavior was observed in these tests. The actionable
failure reported here is the hosted-agent integration; the framework-only spy
reproduction explains the AG-UI request shape that triggers it.

These results were repeated with the direct Azure AI Projects/OpenAI Responses
client using get_openai_client(agent_name=...), with no Agent Framework client
or message transformation. Direct prompt replay passed; direct hosted replay
failed. Therefore, the hosted replay limitation is not caused by
agent-framework-foundry.

Direct tests against the hosted-agent Responses endpoint showed:

• as expected, agent_session_id alone reuses hosted compute/filesystem state
  without continuing conversation history, so it can be used for a fresh
  conversation on the same compute session;
• previous_response_id and conversation=conv_* both continue history;
• successful response/conversation continuation automatically preserves the
  same hosted session ID without explicitly resending it.

Consequently, replay authority is not a usable fallback for this hosted-agent
integration. Rejecting the snapshot/service option combination would make the
incompatibility clearer but would still leave the integration unsupported. A
service-authoritative mode that separates provider input from UI snapshot
history is needed for this use case.

This section describes integration impact, not proof that the hosted service is
defective. The framework-only reproduction above remains the issue's minimal
reproduction.

Temporary workaround

Hosted-agent continuation works when the application:

1. creates a Foundry conversation and uses its conv_* ID as the AG-UI
   threadId;
2. sets use_service_session=True;
3. does not configure an Agent Framework snapshot store; and
4. sends only the incremental user/tool input for each continuation request.

This uses the Foundry conversation as the sole provider-history authority. The
tradeoff is that Agent Framework cannot provide snapshot-backed message
hydration or related persisted thread state in this configuration. Applications
that require both currently need a custom boundary that retains complete
snapshots for the UI but passes only incremental input to the wrapped agent.

Removing assistant messages alone is not a complete workaround when no service
conversation is present, because information contained only in prior assistant
responses is then lost.

Package versions

• agent-framework-core==1.14.0
• agent-framework-ag-ui==1.1.0
• Python 3.12
• Linux

Minimal framework-only reproduction

from __future__ import annotations

from typing import Any

import pytest
from agent_framework import AgentResponseUpdate
from agent_framework.ag_ui import (
    AgentFrameworkAgent,
    InMemoryAGUIThreadSnapshotStore,
)


class InputSpyAgent:
    name = "spy"
    description = ""
    default_options: dict[str, Any] = {}
    context_providers: list[Any] = []

    def __init__(self) -> None:
        self.calls: list[dict[str, Any]] = []

    def run(self, messages, *, session, stream=False, **kwargs):
        async def updates():
            self.calls.append(
                {
                    "roles": [message.role for message in messages],
                    "service_session_id": session.service_session_id,
                }
            )
            yield AgentResponseUpdate(
                contents=["ACK"],
                role="assistant",
                response_id=f"response-{len(self.calls)}",
            )

        return updates()


async def drain(runner, body):
    return [event async for event in runner.run(body)]


@pytest.mark.asyncio
async def test_service_session_has_one_history_authority():
    agent = InputSpyAgent()
    runner = AgentFrameworkAgent(
        agent=agent,
        use_service_session=True,
        snapshot_store=InMemoryAGUIThreadSnapshotStore(),
    )

    first = {
        "threadId": "conv_PROVIDER_SESSION",
        "__ag_ui_snapshot_scope": "test-scope",
        "messages": [{"id": "u1", "role": "user", "content": "first"}],
    }
    second = {
        "threadId": "conv_PROVIDER_SESSION",
        "__ag_ui_snapshot_scope": "test-scope",
        "messages": [{"id": "u2", "role": "user", "content": "second"}],
    }

    await drain(runner, first)
    await drain(runner, second)

    assert agent.calls[1] == {
        "roles": ["user"],
        "service_session_id": "conv_PROVIDER_SESSION",
    }

Actual behavior

{
    "roles": ["user", "assistant", "user"],
    "service_session_id": "conv_PROVIDER_SESSION",
}

Expected contract

The invocation should have one conversation-history authority. If
use_service_session=True selects provider history, the likely expected shape
is:

{
    "roles": ["user"],
    "service_session_id": "conv_PROVIDER_SESSION",
}

If that is not the intended policy, the option combination should be rejected or
documented as replay-authoritative with service_session_id cleared.

Relevant Agent Framework code

agent_framework_ag_ui/_agent_run.py:

• calls _reconstruct_messages_from_thread_snapshot() whenever a snapshot is
  present;
• creates AgentSession(session_id=thread_id, service_session_id=supplied_thread_id) when use_service_session=True;
• does not condition reconstruction on use_service_session.

agent_framework_ag_ui/_run_common.py:

• _reconstruct_messages_from_thread_snapshot() prepends stored messages to
  the new request suffix.

agent_framework/_workflows/_agent_executor.py:

• Python: AgentExecutor keeps service_session_id when replaying full conversation #4292 and PR Python: clear service_session_id on full-history replay #7682 address the analogous mutual-exclusion problem in the
  workflow executor, but not in AG-UI.

Questions for maintainers

1. Is snapshot_store supported together with use_service_session=True?
2. If supported, which source owns provider conversation history: snapshot
   messages or service_session_id?
3. Should snapshot messages remain UI/hydration state only in service mode?
4. How should incremental tool results, approval responses, and interrupt resumes
   be selected without replaying server-owned history?
5. Should the API expose an explicit replay versus service continuation
   policy?

It would be helpful to document whether snapshots and service sessions are
intended to be used together and, if so, how prior history should be supplied to
the wrapped agent. Regression coverage for ordinary turns and tool/resume flows
would help keep that contract stable.

[djw-bsn]

Related to #7503 and its fix in #7608: that change correctly separates and persists agent_session_id for hosted compute while retaining service_session_id for conversation continuation.

We confirmed that behavior works in direct Agent Framework tests. The remaining issue is in AG-UI: with use_service_session=True and snapshots enabled, it passes the correct service session ID but also replays stored assistant history, which Foundry Hosted Agents reject. Service-session mode should ideally retain snapshots for UI hydration while sending only incremental input to the agent.

[djw-bsn]

Additional workaround note: reducing the AG-UI request to incremental provider input before invoking AgentFrameworkAgent also reduces the MESSAGES_SNAPSHOT it emits. Because clients treat that snapshot as authoritative, UI history can collapse to the latest turn.

We worked around this by retaining the complete inbound transcript separately, forwarding only the incremental suffix to the Hosted Agent, and restoring the retained history in the outbound MESSAGES_SNAPSHOT. This reinforces the need to separate provider input history from UI hydration history in service-session mode.

[djw-bsn]

It seems like #7084 might address AG-UI state/snapshot continuity (I will test as soon as its released)? But I guess there is still an independent hosted-agent contract question. Do I need to reach out to the Foundry Team to clarify that?

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: In agent_framework_ag_ui/_agent_run.py, the run_agent_stream function at line 2269 unconditionally calls _reconstruct_messages_from_thread_snapshot() when a stored snapshot exists, without checking config.use_service_session; then at line 2399 it sets service_session_id on the session, creating two competing history authorities. Minimal repro: construct AgentFrameworkAgent(agent=spy, use_service_session=True, snapshot_store=InMemoryAGUIThreadSnapshotStore()), send two sequential requests to the same threadId, and assert the second call receives only the incremental user message (see test_repro_7710.py).

• Failing test: python/packages/ag-ui/tests/ag_ui/test_repro_7710.py
• Files examined: python/packages/ag-ui/agent_framework_ag_ui/_agent_run.py, python/packages/ag-ui/agent_framework_ag_ui/_run_common.py, python/packages/ag-ui/agent_framework_ag_ui/_agent.py, python/packages/ag-ui/agent_framework_ag_ui/init.py, python/packages/core/agent_framework/ag_ui/init.py
• Tests run: python/packages/ag-ui/tests/ag_ui/test_repro_7710.py
• Reported version: agent-framework-ag-ui==1.1.0, agent-framework-core==1.14.0
• Current version: agent-framework-ag-ui==1.1.0, agent-framework-core==1.14.0

[safal207]

I think the “one State Authority” framing here is exactly the right direction.
The important distinction is that two individually valid persistence mechanisms do not automatically compose into one valid continuation contract:
snapshot persistence + service-session persistence ≠ correct replay semantics
We recently wrote about this broader problem while comparing several agent runtimes:
https://safal207.github.io/RESONANCE/conformance-is-a-vector-not-a-verdict.ru.html⁠�
The main lesson was that conformance has to be represented as independent capability axes rather than one overall verdict.
For this issue I would separate at least:
UI hydration authority
provider conversation authority
execution/resume authority
evidence/replay authority
The failure mode appears when two of those authorities are allowed to represent the same history simultaneously:
snapshot says:
replay these previous messages

service session says:
I already own those previous messages

result:
duplicate / conflicting history authority
So a useful invariant might be:
For every model invocation there must be exactly one authoritative source for prior conversation history.
Other persisted representations may exist, but they must be projections for UI, audit, or recovery rather than competing inputs to the provider.
In other words:
persisted copy
≠
replay authority
That distinction also makes the configuration much easier to test: declare the authority for each boundary, then fail closed if two active mechanisms claim the same continuation responsibility.

[djw-bsn]

I have a prompt agent variant that looks like the same AG-UI service-session authority issue, but it fails through historical tool replay rather than hosted-agent assistant-message replay.

Environment:

• agent-framework-core==1.15.0
• agent-framework-ag-ui==1.2.0
• agent-framework-foundry==1.11.0
• Foundry prompt agent
• AgentFrameworkAgent(..., use_service_session=True)
• threadId set to a persisted Foundry conv_*

What passed:

• The same conv_* is reused across HTTP turns.
• Text-only AG-UI service-conversation continuation passes.
• Text-only AG-UI service-conversation plus snapshot replay passes.
• The follow-up AG-UI replay is balanced: assistant_tool_call_id_count == 3, tool_result_call_id_count == 3, assistant_only_count == 0, tool_only_count == 0.

Failing shape:

[
  {"role": "user", "content": "..."},
  {
    "role": "assistant",
    "toolCalls": [
      {
        "id": "call_1",
        "type": "function",
        "function": {"name": "tool_a", "arguments": "{}"}
      }
    ]
  },
  {"role": "tool", "toolCallId": "call_1", "content": "..."},
  {"role": "assistant", "content": "..."},
  {"role": "user", "content": "follow-up"}
]

Agent Framework converts that balanced AG-UI replay into Responses input with a historical function_call_output, but without the matching historical function_call:

{
  "conversation": "conv_...",
  "input": [
    {"type": "message", "role": "user", "content": [...]},
    {"type": "function_call_output", "call_id": "call_1", "output": "..."},
    {"type": "message", "role": "assistant", "content": [...]},
    {"type": "message", "role": "user", "content": [...]}
  ]
}

The provider then rejects the request:

No tool call found for function call output with call_id ...

This looks like the same root contract as #7710: in use_service_session=True mode, AG-UI should retain full replay/snapshot history for UI hydration, but provider input should be service-authoritative and incremental. In this prompt case, replaying historical tool outputs into the provider conversation creates orphaned function_call_output items.

I checked #7770 and it sounds like it should cover this if the new service-session split applies to all AG-UI provider input, not only the hosted assistant-message case: raw_messages should contain only incremental input, while snapshot_messages retains the full replay transcript. Could you confirm whether #7770 also covers prompt agent tool-result replay like the shape above? If not, I can open a separate issue for this prompt tool-history variant.