Tao Chen
ee27065359
* Update agentserver to 2.1.0 * Update agentserver responses and invocations to x.1.0b1 * Pass platform context to state store provider * Pass user id * Correct requirements.txt * Fix unit tests * Fix unit tests
Custom session storage provider
This sample shows how to provide custom session storage to ResponsesHostServer.
The CustomSessionStoreProvider selects storage based on the resolved hosting
configuration:
- Local runs use the in-memory
SessionStoreand do not require Cosmos DB. - Foundry-hosted runs use the custom
CosmosSessionStoreimplementation.
The sample customizes agent-session persistence only. The host's default providers continue to manage workflow checkpoints and function approvals.
Azure Cosmos DB setup
Before deploying the sample, create an Azure Cosmos DB database and container. The
container must use /user_id as its partition key. Each session document includes
the Foundry platform user ID, so session IDs and data are isolated between users.
Set these environment variables to
the existing resources:
COSMOS_CONNECTION_STRINGCOSMOS_DATABASE_NAMECOSMOS_CONTAINER_NAME
See main.py for the complete provider and store implementations.
Running locally
Copy .env.example to .env, set the Foundry project and model values, and leave
the Cosmos values unset. The provider creates one in-memory store for the lifetime
of the local server process.
Follow Running the Agent Host Locally in the parent README, then send a request:
curl -X POST http://localhost:8088/responses -H "Content-Type: application/json" -d '{"input": "Hi"}'
Local session data is lost when the process exits.
Deploying to Foundry
Set all variables in .env.example, including the Cosmos settings, and follow
Deploying the Agent to Foundry
in the parent README. The hosted provider initializes Cosmos DB lazily on its first
request and reuses the client and container for later requests. Each request receives
a session store scoped to the non-empty user ID supplied by Foundry.