mirror of https://github.com/microsoft/agent-framework.git synced 2026-06-16 21:04:09 +08:00

Files

T

Evan Mattson 4b0522d62d Python: Bump Python package versions for a release (#5964 )

* Bump Python package versions to 1.5.0 for a release

* Promote orchestrations to 1.0.0rc1

* ci(python-setup): merge dynamic exclude into existing workspace exclude

The python-setup action injected exclude = [...] verbatim into
[tool.uv.workspace], producing a duplicate 'exclude' key when the
section already had a static exclude. Scope the rewrite to the
[tool.uv.workspace] section and append the package to the existing
array when present; idempotent if the package is already excluded.

* Address Copilot review feedback: raise inter-package floors to 1.5.0

- foundry, foundry-local: agent-framework-openai >=1.4.0 -> >=1.5.0
- azure-contentunderstanding: agent-framework-foundry >=1.4.0 -> >=1.5.0
- azurefunctions: pin agent-framework-durabletask to >=1.0.0b260519,<2

Keeps lockstep cohort consistent and avoids mixed 1.4.x / 1.5.0 installs.

* Re-include azurefunctions and durabletask in the uv workspace

The pinned durabletask>=1.4.0 floor is enough to make resolution succeed;
the workspace exclude was over-correction and broke CI samples and pyright
type-checking (re-exports in agent_framework/azure/__init__.pyi plus
samples/04-hosting/{azure_functions,durabletask}/ could not resolve their
imports). Dropping them from agent-framework-core[all] still stands so the
metapackage does not pull them.

* Restore azurefunctions and durabletask in agent-framework-core[all]

The durabletask floor pin keeps users on the safe 1.4.0, so they are once
again included in the metapackage. Update CHANGELOG to reflect the pin
rather than an [all] removal.

* Raise uvicorn ceiling in ag-ui and devui to allow 0.42+

The root override-dependencies pins uvicorn[standard]>=0.34.0 (no upper)
and the workspace lock resolves to 0.47.0. The package ceiling <0.42.0
meant the workspace was no longer testing the declared supported range.
Bump to <1 so the lock fits within the declared bounds.

Also picked up by validate-dependency-bounds: refresh stale orchestrations
RC pin in devui dev deps.

4b0522d62d · 2026-05-20 09:20:53 +09:00

History

agent_framework_azure_cosmos

Python: Fix user agent prefix (#5455 )

2026-04-23 23:40:38 +00:00

tests

Python: Add allowed_checkpoint_types support to CosmosCheckpointStorage for parity with FileCheckpointStorage (#5202 )

2026-04-14 02:20:55 +00:00

AGENTS.md

Python: [BREAKING] Python: move Azure AI embeddings to Foundry (#5056 )

2026-04-02 11:26:35 +00:00

LICENSE

Python: Add Azure Cosmos history provider package (#4271 )

2026-03-03 12:29:32 +00:00

pyproject.toml

Python: Bump Python package versions for a release (#5964 )

2026-05-20 09:20:53 +09:00

README.md

Python: Add Cosmos DB NoSQL Checkpoint Storage for Python Workflows (#4916 )

2026-04-09 05:01:41 +00:00

README.md

Get Started with Microsoft Agent Framework Azure Cosmos DB

Please install this package via pip:

pip install agent-framework-azure-cosmos --pre

Azure Cosmos DB History Provider

The Azure Cosmos DB integration provides CosmosHistoryProvider for persistent conversation history storage.

Basic Usage Example

from azure.identity.aio import DefaultAzureCredential
from agent_framework_azure_cosmos import CosmosHistoryProvider

provider = CosmosHistoryProvider(
    endpoint="https://<account>.documents.azure.com:443/",
    credential=DefaultAzureCredential(),
    database_name="agent-framework",
    container_name="chat-history",
)

Credentials follow the same pattern used by other Azure connectors in the repository:

Pass a credential object (for example DefaultAzureCredential)
Or pass a key string directly
Or set AZURE_COSMOS_KEY in the environment

Container naming behavior:

Container name is configured on the provider (container_name or AZURE_COSMOS_CONTAINER_NAME)
session_id is used as the Cosmos partition key for reads/writes

See samples/02-agents/conversations/cosmos_history_provider.py for a runnable example.

Cosmos DB Workflow Checkpoint Storage

CosmosCheckpointStorage implements the CheckpointStorage protocol, enabling durable workflow checkpointing backed by Azure Cosmos DB NoSQL. Workflows can be paused and resumed across process restarts by persisting checkpoint state in Cosmos DB.

Basic Usage

Managed Identity / RBAC (recommended for production)

from azure.identity.aio import DefaultAzureCredential
from agent_framework import WorkflowBuilder
from agent_framework_azure_cosmos import CosmosCheckpointStorage

checkpoint_storage = CosmosCheckpointStorage(
    endpoint="https://<account>.documents.azure.com:443/",
    credential=DefaultAzureCredential(),
    database_name="agent-framework",
    container_name="workflow-checkpoints",
)

Account Key

from agent_framework_azure_cosmos import CosmosCheckpointStorage

checkpoint_storage = CosmosCheckpointStorage(
    endpoint="https://<account>.documents.azure.com:443/",
    credential="<your-account-key>",
    database_name="agent-framework",
    container_name="workflow-checkpoints",
)

Then use with a workflow

from agent_framework import WorkflowBuilder

# Build a workflow with checkpointing enabled
workflow = WorkflowBuilder(
    start_executor=start,
    checkpoint_storage=checkpoint_storage,
).build()

# Run the workflow — checkpoints are automatically saved after each superstep
result = await workflow.run(message="input data")

# Resume from a checkpoint
latest = await checkpoint_storage.get_latest(workflow_name=workflow.name)
if latest:
    resumed = await workflow.run(checkpoint_id=latest.checkpoint_id)

Authentication Options

CosmosCheckpointStorage supports the same authentication modes as CosmosHistoryProvider:

Managed identity / RBAC (recommended): Pass DefaultAzureCredential(), ManagedIdentityCredential(), or any Azure TokenCredential
Account key: Pass a key string via credential parameter
Environment variables: Set AZURE_COSMOS_ENDPOINT, AZURE_COSMOS_DATABASE_NAME, AZURE_COSMOS_CONTAINER_NAME, and AZURE_COSMOS_KEY (key not required when using Azure credentials)
Pre-created client: Pass an existing CosmosClient or ContainerProxy

Database and Container Setup

The database and container are created automatically on first use (via create_database_if_not_exists and create_container_if_not_exists). The container uses /workflow_name as the partition key. You can also pre-create them in the Azure portal with this partition key configuration.

Environment Variables

Variable	Description
`AZURE_COSMOS_ENDPOINT`	Cosmos DB account endpoint
`AZURE_COSMOS_DATABASE_NAME`	Database name
`AZURE_COSMOS_CONTAINER_NAME`	Container name
`AZURE_COSMOS_KEY`	Account key (optional if using Azure credentials)

See samples/03-workflows/checkpoint/cosmos_workflow_checkpointing.py for a standalone example, or samples/03-workflows/checkpoint/cosmos_workflow_checkpointing_foundry.py for an end-to-end example with Azure AI Foundry agents.