Ahmed Muhsin
148f57020a
* feat(durabletask): host MAF workflows on a standalone Durable Task worker
Add a host-agnostic workflow execution engine to agent-framework-durabletask so a MAF Workflow can run as a durable orchestration outside Azure Functions:
- WorkflowOrchestrationContext protocol + DurableTaskWorkflowContext adapter, the superstep orchestrator, serialization helpers, capturing runner context, and the shared non-agent activity body (including the yield-output classifier so intermediate executors are not surfaced as final outputs).
- DurableAIAgentWorker.configure_workflow auto-registers agent executors as entities, non-agent executors as activities, and the workflow orchestrator.
- plan_workflow_registration centralizes the 'what to register' decision so it can be shared across hosts.
- run_agent_coroutine runs all agent coroutines on one persistent event loop, fixing a cross-loop hang when shared chat clients/credentials bind their asyncio primitives to a dead loop.
- DurableWorkflowClient (start/await workflow + HITL discover/respond); DurableAIAgentClient stays agent-only.
* refactor(azurefunctions): delegate workflow execution to agent-framework-durabletask
AgentFunctionApp now reuses the shared orchestrator, activity body, and registration planner from agent_framework_durabletask instead of maintaining its own copies; _workflow.py becomes a thin host-specific adapter (AzureFunctionsWorkflowContext).
- Run agent entity coroutines on the shared persistent event loop, fixing the cross-loop hang.
- Relocate state-diff unit tests to the durabletask package; update entity loop tests.
* feat(core): expose durabletask workflow symbols via agent_framework.azure
Lazily re-export WORKFLOW_ORCHESTRATOR_NAME and DurableWorkflowClient from the agent_framework.azure namespace so standalone hosts can import them without depending on internal module paths.
* docs(samples): add standalone durabletask workflow and HITL samples
Add two samples under samples/04-hosting/durabletask demonstrating MAF workflows on a standalone Durable Task worker (no Azure Functions):
- 08_workflow: conditional spam-detection workflow started via DurableWorkflowClient.start_workflow / await_workflow_output.
- 09_workflow_hitl: content-moderation workflow that pauses with ctx.request_info and is resumed via DurableWorkflowClient.get_pending_hitl_requests / send_hitl_response.
Also add the durabletask workflow integration test (test_08_dt_workflow).
* fix: address PR review feedback
- Sanitize HITL external-event responses with strip_pickle_markers in the orchestrator (defense-in-depth for callers that bypass DurableWorkflowClient).
- Raise WorkflowConvergenceException when max_iterations is reached with pending messages, matching the core WorkflowRunner instead of silently returning partial output.
- Route falsy 'sent' messages (use 'is not None' instead of truthiness).
- Normalize None shared_state_snapshot/source_executor_ids in execute_workflow_activity.
- Cast Any returns in AzureFunctionsWorkflowContext to satisfy mypy/pyright.
- Fix sample docstrings to reference DurableWorkflowClient.
* fix: resolve pyright Package Checks errors
- Use typed locals instead of cast in AzureFunctionsWorkflowContext (mypy sees Any, pyright sees concrete types -> avoid reportUnnecessaryCast).
- Annotate shared_state_snapshot and cast partially-typed durabletask SDK returns / HITL custom-status parsing to satisfy reportUnknownVariableType/reportUnknownMemberType.
- Drop the dead deserialize/serialize re-export in _workflow.py and mark the intentional private _extract_message_content re-export.
* fix(durabletask): agent-executor identity and typed workflow input
Register each workflow agent entity under the executor id that the orchestrator dispatches to (instead of the agent name), so AgentExecutor(agent, id=...) works when the id differs from agent.name. The azure-functions host mirrors this.
Reconstruct the start executor declared input type from the workflow initial JSON payload in the shared engine (mirroring in-process delivery) instead of string-coercing it per host. Untrusted input is stripped of pickle markers before reconstruction to prevent deserialization RCE.
* fix(samples): type durable workflow start executors for reconstructed input
The HITL and parallel workflow samples no longer hand-parse a JSON string. Their start executors now declare their real input type (ContentSubmission / DocumentInput), which the durable engine reconstructs from the client payload before delivery.
* test(durabletask): unit coverage for registration, client, worker, and input coercion
Add unit tests for plan_workflow_registration, DurableWorkflowClient, the agent-executor identity registration (entity keyed by executor id), and the typed initial-input coercion including pickle-marker neutralization.
* test(durabletask): HITL and parallel durable workflow integration tests
Add an integration test for the standalone durabletask HITL workflow sample via a new workflow_client fixture. Re-enable the Azure Functions parallel workflow test, consolidated into one end-to-end case so the work-stealing xdist scheduler cannot spawn multiple func hosts for this sample.
* refactor(durabletask): group workflow modules into a _workflows subpackage
Move the eight workflow modules into a private _workflows/ subpackage and drop the redundant _workflow_ prefix (orchestrator.py, registration.py, activity.py, client.py, context.py, dt_context.py, runner_context.py, serialization.py). The public API and __all__ are unchanged; only direct internal-module imports were repointed (package __init__, the worker, the azure-functions shared shim, and the affected unit tests).
* fix(durabletask): harden workflow type resolution and HITL response handling
- resolve_type returns only real classes (avoids issubclass TypeError in reconstruct_to_type)
- re-wait on HITL responses rejected by pickle-marker sanitization instead of dropping the request and losing the run
- American spelling in strip_pickle_markers docstring
- unit tests for resolve_type
* fix(durabletask): treat async edge conditions as not-matched on the synchronous host
The durabletask orchestrator evaluates edge conditions synchronously and does not support async edge conditions. Such an edge is now treated as not matched (the edge is not traversed) rather than assuming a result. Adds unit coverage; full async-condition support will be handled separately.
* fix(durabletask): reconstruct typed workflow outputs at the host boundary
await_workflow_output and the Azure Functions status endpoint now decode the checkpoint-encoded outputs the shared activity produces, via a shared deserialize_workflow_output helper. The client returns the original objects; the AF endpoint emits clean domain JSON instead of checkpoint-marker dicts, keeping the two hosts consistent.
* fix(durabletask): address review findings on workflow hosting
- AF: register workflow agents through add_agent(entity_id=...) so they remain tracked in app.agents / get_agent() (restores documented behavior) while keying by the executor id the orchestrator dispatches to; mirrors DurableAIAgentWorker.add_agent.
- async bridge: treat the shared loop as reusable only while its backing thread is alive, so a dead loop thread is replaced instead of hanging future.result() forever.
- client: add get_runtime_status; the standalone HITL sample now stops polling and reports the real terminal state instead of a generic timeout.
- tests: guard send_hitl_response pickle-marker stripping and add get_runtime_status coverage.
* fix(durabletask): wait indefinitely for HITL responses, matching core
The durable workflow host previously raced HITL responses against a 72h timer and failed the orchestration on elapse. MAF core's request_info has no timeout concept (it waits for the response), and the .NET durable host waits too, so the durable Python host now does the same: it stays paused until a response arrives. Removes the hitl_timeout_hours parameter and DEFAULT_HITL_TIMEOUT_HOURS constant from both hosts. A configurable timeout can be added later once core defines the contract (what happens on elapse).
* feat(durabletask): typed workflow event streaming and async client API
Add a brokerless workflow event stream to the durable host. Each non-agent executor runs inside a durable activity that captures its real WorkflowEvents (with data payloads); the orchestrator replays them into the orchestration custom status after each superstep, and the client streams them back as typed WorkflowEvent objects with reconstructed data. Agent executors contribute synthesized invoked/completed lifecycle events.
Add async client methods run_workflow (start with optional wait) and stream_workflow (typed event iterator), plus is_replaying plumbing through the orchestration context protocol and both host adapters so live status is published only on non-replay execution.
* docs(samples): standalone durabletask workflow streaming sample
Add sample 10_workflow_streaming demonstrating the async DurableWorkflowClient API on a standalone Durable Task worker: run_workflow(wait=False) to start without blocking, then stream_workflow to consume typed WorkflowEvent objects as a WriterAgent -> ReviewerAgent -> publish pipeline runs.
* refactor(durabletask): internal-only checkpoint codec and host-scoped workflow event streaming
Two related hardening changes to the durable workflow hosting layer, plus a
rebase-restored improvement.
Internal-only serialization codec (MSRC follow-up):
- Rename serialize_value/deserialize_value -> _serialize_value/_deserialize_value
in the shared durabletask serialization module and update all call sites, so the
pickle-backed checkpoint codec is unambiguously framework-internal. Untrusted
input is still neutralized with strip_pickle_markers at the HTTP boundary.
- Remove the duplicate agent_framework_azurefunctions._serialization module and
import strip_pickle_markers from the shared durabletask module instead. Move its
unique serialization/strip-marker tests into the durabletask test suite.
Scope workflow event streaming to hosts that can carry it:
- Add WorkflowOrchestrationContext.supports_event_streaming. The standalone
DurableTask host returns True (no custom-status size cap, has a stream_workflow
consumer); the Azure Functions host returns False.
- The orchestrator now accumulates and publishes the WorkflowEvent timeline to the
orchestration custom status only when the host supports streaming. On Azure
Functions the custom status returns to its pre-streaming shape
({state[, pending_requests]}), which fixes orchestrator failures with
"The size of the JSON-serialized payload must not exceed 16 KB" and stops leaking
pickle markers into the HTTP status response. The Azure Functions status endpoint
never consumed the event stream.
Workflow start endpoint:
- Accept text/plain raw request bodies (fall back from get_json to the raw body),
restoring an improvement from main that the rebase conflict resolution dropped.
* fix(azurefunctions): scope workflow status/respond endpoints to the workflow orchestrator
The workflow/status/{instanceId} and workflow/respond/{instanceId}/{requestId}
HTTP endpoints resolved durable instances by ID only. The durable client looks up
IDs across every orchestration in the task hub (agent entities, any
user-registered orchestrations, and other apps sharing the hub), so a caller
holding one instance ID could read another orchestration's status -- including
pending HITL request payloads -- or inject external events into it.
Add AgentFunctionApp._is_workflow_orchestration() and gate both endpoints on it:
an instance whose orchestration name is not WORKFLOW_ORCHESTRATOR_NAME now returns
404 instead of leaking state or accepting events. send_hitl_response now fetches
the orchestration status and validates ownership before raising the external
event. Legitimate workflow instances are unaffected.
Mirrors the .NET fix in PR #6608.
* fix(durabletask): resolve CI typing failures
- serialization: rename _serialize_value/_deserialize_value back to
serialize_value/deserialize_value to follow the package convention for
cross-module internal helpers (matches strip_pickle_markers, resolve_type).
The leading underscore tripped pyright reportPrivateUsage on cross-module
imports under the strict source gate; internal-only status is preserved by
not exporting them from the public API.
- Remove type-ignore comments pyright flags as unnecessary
(reportUnnecessaryTypeIgnoreComment) in _worker.py, orchestrator.py,
serialization.py.
- test_08_dt_workflow: add AgentClientFactoryProtocol and annotate the
agent_client_factory fixture as type[AgentClientFactoryProtocol] (matching
test_01-07) so mypy/ty stop reporting "type has no attribute create".
- samples (08_workflow, 09_workflow_hitl): pass structured output via
FoundryChatOptions[Any](response_format=...) instead of a plain dict so the
samples pyright (basic) config accepts default_options.
---------
Co-authored-by: Gavin Aguiar <80794152+gavin-aguiar@users.noreply.github.com>
Python Samples
This directory contains samples demonstrating the capabilities of Microsoft Agent Framework for Python.
Structure
| Folder | Description |
|---|---|
01-get-started/ |
Progressive tutorial: hello agent → hosting |
02-agents/ |
Deep-dive by concept: tools, middleware, providers, orchestrations |
03-workflows/ |
Workflow patterns: sequential, concurrent, state, declarative, explicit output designation |
04-hosting/ |
Deployment: Azure Functions, Durable Tasks, A2A |
05-end-to-end/ |
Full applications, evaluation, demos |
Getting Started
Start with 01-get-started/ and work through the numbered files:
- 01_hello_agent.py — Create and run your first agent
- 02_add_tools.py — Add function tools with
@tool - 03_multi_turn.py — Multi-turn conversations with
AgentSession - 04_memory.py — Agent memory with
ContextProvider - 05_functional_workflow_with_agents.py — Call agents inside a functional workflow
- 06_functional_workflow_basics.py — Write a workflow as a plain async function
- 07_first_graph_workflow.py — Build a workflow with executors and edges
- 08_host_your_agent.py — Host your agent via Azure Functions
Prerequisites
pip install agent-framework
Environment Variables
Samples call load_dotenv() to automatically load environment variables from a .env file in the python/ directory. This is a convenience for local development and testing.
For local development, set up your environment using any of these methods:
Option 1: Using a .env file (recommended for local development):
- Copy
.env.exampleto.envin thepython/directory:cp .env.example .env - Edit
.envand set your values (API keys, endpoints, etc.)
Option 2: Export environment variables directly:
export FOUNDRY_PROJECT_ENDPOINT="your-foundry-project-endpoint"
export FOUNDRY_MODEL="gpt-4o"
Option 3: Using env_file_path parameter (for per-client configuration):
All client classes (e.g., OpenAIChatClient, OpenAIChatCompletionClient) support an env_file_path parameter to load environment variables from a specific file:
from agent_framework.openai import OpenAIChatClient
# Load from a custom .env file
client = OpenAIChatClient(env_file_path="path/to/custom.env")
This allows different clients to use different configuration files if needed.
For the generic OpenAI clients (OpenAIChatClient and OpenAIChatCompletionClient), routing
precedence is:
- Explicit Azure inputs such as
credential,azure_endpoint, orapi_version OPENAI_API_KEY/ explicit OpenAI API-key parameters- Azure environment fallback such as
AZURE_OPENAI_ENDPOINTandAZURE_OPENAI_API_KEY
If you keep both OpenAI and Azure variables in your shell, the generic clients stay on OpenAI until you pass an explicit Azure input.
For the getting-started samples, you'll need at minimum:
FOUNDRY_PROJECT_ENDPOINT="your-foundry-project-endpoint"
FOUNDRY_MODEL="gpt-4o"
Consolidated sample env inventory
This is the single source of truth for package-level environment variables read by packages included by
agent-framework-core[all]. It intentionally excludes variables that are only read by standalone samples,
package sample folders, or tests. When package code adds, removes, or renames an environment variable,
update this table in the same change.
Example values below are illustrative. For entries not backed by a single public class, the class
column names the closest public surface, helper, or package-level initialization point that reads the
variable.
| package | class/module | env var | example value |
|---|---|---|---|
agent-framework-anthropic |
AnthropicClient |
ANTHROPIC_API_KEY |
sk-ant-api03-... |
agent-framework-anthropic |
AnthropicClient |
ANTHROPIC_CHAT_MODEL |
claude-sonnet-4-5-20250929 |
agent-framework-foundry |
FoundryEmbeddingClient |
FOUNDRY_MODELS_ENDPOINT |
https://my-endpoint.inference.ai.azure.com |
agent-framework-foundry |
FoundryEmbeddingClient |
FOUNDRY_MODELS_API_KEY |
env-key |
agent-framework-foundry |
FoundryEmbeddingClient |
FOUNDRY_EMBEDDING_MODEL |
text-embedding-3-small |
agent-framework-foundry |
FoundryEmbeddingClient |
FOUNDRY_IMAGE_EMBEDDING_MODEL |
Cohere-embed-v3-english |
agent-framework-azure-ai-search |
AzureAISearchContextProvider |
AZURE_SEARCH_ENDPOINT |
https://my-search.search.windows.net |
agent-framework-azure-ai-search |
AzureAISearchContextProvider |
AZURE_SEARCH_API_KEY |
search-key |
agent-framework-azure-ai-search |
AzureAISearchContextProvider |
AZURE_SEARCH_INDEX_NAME |
hotels-index |
agent-framework-azure-ai-search |
AzureAISearchContextProvider |
AZURE_SEARCH_KNOWLEDGE_BASE_NAME |
hotels-kb |
agent-framework-azure-cosmos |
CosmosHistoryProvider |
AZURE_COSMOS_ENDPOINT |
https://my-cosmos.documents.azure.com:443/ |
agent-framework-azure-cosmos |
CosmosHistoryProvider |
AZURE_COSMOS_DATABASE_NAME |
agent-history |
agent-framework-azure-cosmos |
CosmosHistoryProvider |
AZURE_COSMOS_CONTAINER_NAME |
messages |
agent-framework-azure-cosmos |
CosmosHistoryProvider |
AZURE_COSMOS_KEY |
C2F...== |
agent-framework-bedrock |
BedrockChatClient |
BEDROCK_REGION |
us-east-1 |
agent-framework-bedrock |
BedrockChatClient |
BEDROCK_CHAT_MODEL |
anthropic.claude-3-5-sonnet-20241022-v2:0 |
agent-framework-bedrock |
BedrockEmbeddingClient |
BEDROCK_REGION |
us-east-1 |
agent-framework-bedrock |
BedrockEmbeddingClient |
BEDROCK_EMBEDDING_MODEL |
amazon.titan-embed-text-v2:0 |
agent-framework-bedrock |
BedrockChatClient / BedrockEmbeddingClient |
AWS_ACCESS_KEY_ID |
AKIAIOSFODNN7EXAMPLE |
agent-framework-bedrock |
BedrockChatClient / BedrockEmbeddingClient |
AWS_SECRET_ACCESS_KEY |
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY |
agent-framework-bedrock |
BedrockChatClient / BedrockEmbeddingClient |
AWS_SESSION_TOKEN |
IQoJb3JpZ2luX2VjEO7//////////wEaCXVzLXdlc3QtMiJHMEUCIQD... |
agent-framework-copilotstudio |
CopilotStudioAgent |
COPILOTSTUDIOAGENT__ENVIRONMENTID |
00000000-0000-0000-0000-000000000000 |
agent-framework-copilotstudio |
CopilotStudioAgent |
COPILOTSTUDIOAGENT__SCHEMANAME |
cr123_agentname |
agent-framework-copilotstudio |
CopilotStudioAgent |
COPILOTSTUDIOAGENT__TENANTID |
11111111-1111-1111-1111-111111111111 |
agent-framework-copilotstudio |
CopilotStudioAgent |
COPILOTSTUDIOAGENT__AGENTAPPID |
22222222-2222-2222-2222-222222222222 |
agent-framework-core |
observability |
ENABLE_INSTRUMENTATION |
true |
agent-framework-core |
observability |
ENABLE_SENSITIVE_DATA |
false |
agent-framework-core |
observability |
ENABLE_CONSOLE_EXPORTERS |
true |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_ENDPOINT |
http://localhost:4317 |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT |
http://localhost:4318/v1/traces |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT |
http://localhost:4318/v1/metrics |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT |
http://localhost:4318/v1/logs |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_PROTOCOL |
grpc |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_HEADERS |
api-key=demo |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_TRACES_HEADERS |
api-key=trace-demo |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_METRICS_HEADERS |
api-key=metric-demo |
agent-framework-core |
observability |
OTEL_EXPORTER_OTLP_LOGS_HEADERS |
api-key=log-demo |
agent-framework-core |
observability |
OTEL_SERVICE_NAME |
sample-agent |
agent-framework-core |
observability |
OTEL_SERVICE_VERSION |
1.0.0 |
agent-framework-core |
observability |
OTEL_RESOURCE_ATTRIBUTES |
deployment.environment=dev,service.namespace=agent-framework |
agent-framework-devui |
DevUI server |
DEVUI_AUTH_TOKEN |
my-devui-token |
agent-framework-foundry |
FoundryChatClient |
FOUNDRY_PROJECT_ENDPOINT |
https://my-project.services.ai.azure.com/api/projects/my-project |
agent-framework-foundry |
FoundryChatClient |
FOUNDRY_MODEL |
gpt-4o |
agent-framework-foundry |
FoundryAgent |
FOUNDRY_AGENT_NAME |
travel-planner |
agent-framework-foundry |
FoundryAgent |
FOUNDRY_AGENT_VERSION |
v1 |
agent-framework-github-copilot |
GitHubCopilotAgent |
GITHUB_COPILOT_CLI_PATH |
copilot |
agent-framework-github-copilot |
GitHubCopilotAgent |
GITHUB_COPILOT_MODEL |
gpt-5 |
agent-framework-github-copilot |
GitHubCopilotAgent |
GITHUB_COPILOT_TIMEOUT |
60 |
agent-framework-github-copilot |
GitHubCopilotAgent |
GITHUB_COPILOT_LOG_LEVEL |
info |
agent-framework-mem0 |
agent_framework_mem0 package import |
MEM0_TELEMETRY |
false |
agent-framework-ollama |
OllamaChatClient |
OLLAMA_HOST |
http://localhost:11434 |
agent-framework-ollama |
OllamaChatClient |
OLLAMA_MODEL |
llama3.1:8b |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
OPENAI_API_KEY |
sk-proj-... |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
OPENAI_MODEL |
gpt-4o-mini |
agent-framework-openai |
OpenAIChatClient |
OPENAI_CHAT_MODEL |
gpt-4.1-mini |
agent-framework-openai |
OpenAIChatCompletionClient |
OPENAI_CHAT_COMPLETION_MODEL |
gpt-4o |
agent-framework-openai |
OpenAIEmbeddingClient |
OPENAI_EMBEDDING_MODEL |
text-embedding-3-small |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
OPENAI_BASE_URL |
https://api.openai.com/v1/ |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
OPENAI_ORG_ID |
org_123456789 |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_ENDPOINT |
https://my-resource.openai.azure.com/ |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_API_KEY |
sk-azure-... |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_API_VERSION |
2024-10-21 |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_BASE_URL |
https://my-resource.openai.azure.com/openai/v1/ |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_MODEL |
gpt-4o |
agent-framework-openai |
OpenAIChatClient |
AZURE_OPENAI_CHAT_MODEL |
gpt-4.1 |
agent-framework-openai |
OpenAIChatCompletionClient |
AZURE_OPENAI_CHAT_COMPLETION_MODEL |
gpt-4o-mini |
agent-framework-openai |
OpenAIEmbeddingClient |
AZURE_OPENAI_EMBEDDING_MODEL |
text-embedding-3-large |
agent-framework-openai |
OpenAIChatClient / OpenAIChatCompletionClient / OpenAIEmbeddingClient |
AZURE_OPENAI_RESOURCE_URL |
https://cognitiveservices.azure.com/ |
agent-framework-openai supports the Azure OpenAI client-specific deployment aliases listed above; keep
packages/openai/README.md as the authoritative reference for the exact fallback order and package-specific
behavior.
Note for production: In production environments, set environment variables through your deployment platform (e.g., Azure App Settings, Kubernetes ConfigMaps/Secrets) rather than using .env files. The load_dotenv() call in samples will have no effect when a .env file is not present, allowing environment variables to be loaded from the system.
For Azure authentication, run az login before running samples.
Note on XML tags
Some sample files include XML-style snippet tags (for example <snippet_name> and </snippet_name>). These are used by our documentation tooling and can be ignored or removed when you use the samples outside this repository.
Additional Resources
- Agent Framework Documentation
- AGENTS.md — Structure documentation for maintainers
- SAMPLE_GUIDELINES.md — Coding conventions for samples