Eduard van Valkenburg
28389df805
* Python: Move session persistence into core Move SessionStore and durable msgspec-backed storage into core, restore sessions in Foundry Responses hosting with per-user isolation, and document the serialization design. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Address session persistence review feedback Harden scoped file paths and corruption recovery, preserve session serialization compatibility, clarify dependency placement, and add reproducible benchmark evidence. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Preserve session snapshot compatibility Deep-copy in-memory session writes and retain existing Telegram session keys so stored conversations continue resolving. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Simplify Foundry session isolation Add experimental FoundrySessionStore backed by Agent Server request context, remove resolver plumbing, and centralize v2 user isolation for sessions, checkpoints, and approvals. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Reduce Foundry session helper layering Inline the single-use request user accessor while keeping separate context validation, fingerprint, and directory helpers for their distinct callers. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Clarify Foundry request context validation Separate fail-fast request validation from context retrieval so Responses no longer appears to discard a returned context. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Python: Share Foundry request context helpers Move protocol validation and user-scope derivation into a dedicated request-context module, leaving the session-store module focused on storage. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Restore Foundry checkpoint storage paths Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Simplify Foundry session storage paths Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Persist Foundry sessions under hosted home Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Make hosted path test platform independent Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Address session persistence review feedback Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Isolate Foundry session path handling Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Clarify Foundry session path terminology Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Align Foundry sessions with Responses continuity Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Finalize Foundry Responses session persistence Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Add session store feature usage telemetry Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c * Fix hosted per-call history persistence Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c --------- Copilot-Session: 3e5c81ad-75e8-4e92-a883-8bbd676c6c8c
3.1 KiB
Foundry Hosting
This package provides the integration of Agent Framework agents and workflows with the Foundry Agent Server, which can be hosted on Foundry infrastructure.
ResponsesHostServer persists the Agent Framework AgentSession used by regular
agents in addition to the Responses provider's message history. By default it
uses the experimental FoundrySessionStore under /.sessions when hosted and
an in-memory SessionStore locally. Hosted snapshots are partitioned by the
Agent Server request context's platform user ID. Snapshot filenames use the
Responses conversation_id or response_id, depending on the continuation
mode.
Foundry's session file API exposes the hosted $HOME directory as /, so the
API path /.sessions is stored on disk at $HOME/.sessions.
Workflow agents continue to use their existing checkpoint storage layout.
Foundry session isolation
FoundrySessionStore currently subclasses core's FileSessionStore. It reads
the active request through azure.ai.agentserver.core.get_request_context() and
validates the platform user_id (the same x-agent-user-id value exposed as
ResponseContext.platform_context.user_id_key) before selecting its on-disk
directory.
Regular-agent session snapshots use the platform user ID and a Responses key:
/.sessions/<user-id>/<conversation-id-or-response-id>.json
A Foundry session controls hosted compute and filesystem lifetime and may host multiple users and Responses conversations. The Foundry session ID is not used as the MAF session identifier.
When conversation_id is used, the host reads and writes the same snapshot
under that ID. When previous_response_id is used, the host reads that response
snapshot, runs the loaded MAF session, and writes the updated snapshot under the
current response's response_id. Multiple responses can therefore branch from
one prior response without overwriting its snapshot.
Foundry does not infer the hosted agent_session_id from
previous_response_id. Callers using response chains must also reuse the
agent_session_id returned by the previous response so the request reaches the
same sandbox and $HOME/.sessions filesystem. Conversation objects bind to a
stable hosted session automatically.
Workflow checkpoints and function approvals preserve the existing Foundry Hosting layout. Hosted paths insert the validated raw platform user ID:
/.checkpoints/<user-id>/<context-id>/
/.function_approvals/<user-id>/approval_requests.json
Local workflow checkpoints use {cwd}/.checkpoints/<context-id>/, and local
function approvals remain in memory.
Hosted requests require container protocol 2.0.0. The v2-only request
call_id is checked before session, checkpoint, or approval storage is used,
and a missing platform user ID fails closed. Regular agents also require the
normal Responses continuation ID for restoration. Local requests may remain
unscoped.
The Foundry-specific store type intentionally hides the current filesystem
implementation from ResponsesHostServer setup. A future version may move
FoundrySessionStore to a Foundry storage API without changing the host's
default configuration.