Principle:Microsoft Agent framework Agent Factory Configuration

Knowledge Sources	Microsoft Agent Framework Agent Framework Declarative
Domains	Declarative_Systems, Agent_Architecture
Last Updated	2026-02-11 00:00 GMT

Overview

A configuration principle that governs how an AgentFactory is constructed to serve as the central entry point for creating fully configured Agent instances from declarative YAML definitions.

Description

The Agent Factory Configuration principle defines how shared runtime configuration is centralized in a single factory object, which then produces Agent instances from YAML input without requiring each agent definition to redundantly specify infrastructure concerns. The factory holds cross-cutting resources such as the chat client, tool bindings, connection credentials, and provider mappings, and injects them into every agent it creates.

This follows the Factory Pattern applied to declarative agent construction. Rather than manually wiring up a chat client, binding tools, and resolving provider classes for each agent, the factory encapsulates these shared concerns once and applies them consistently to every YAML-defined agent it produces.

The key design decisions are:

• Shared chat client: A single SupportsChatGetResponse instance can be reused across all agents created by the factory, or omitted so that each YAML definition specifies its own provider
• Tool bindings: Python callables are bound by name, allowing YAML definitions to reference tools like get_weather without embedding code
• Provider extensibility: Built-in provider mappings cover AzureOpenAI, OpenAI, Anthropic, and AzureAI, with an additional_mappings parameter for custom providers
• Safe mode: Environment variable access in PowerFx expressions is disabled by default, enforcing explicit credential passing through constructors
• Environment loading: Optional .env file support via dotenv consolidates credential management

Usage

Use this principle at the start of any workflow that creates agents from YAML definitions. Configure the factory once with the shared resources, then call its creation methods repeatedly:

• Single-provider deployment: Pass a pre-built chat client when all agents share the same backend (e.g., Azure OpenAI)
• Multi-provider deployment: Omit the client parameter and let each YAML definition specify its own model.provider and model.apiType
• Custom integrations: Use additional_mappings to register proprietary or third-party chat client classes that the factory should be able to instantiate

Theoretical Basis

The factory centralizes shared configuration and produces agents from declarative definitions:

# Abstract algorithm (not real code)
factory = AgentFactory(
    client=shared_chat_client,         # optional shared client
    bindings=tool_name_to_callable,    # tool resolution map
    connections=credential_map,        # connection credentials
    additional_mappings=custom_providers,  # extend provider registry
    default_provider=provider_key,     # fallback when YAML omits provider
    safe_mode=True,                    # restrict env access in expressions
)

# Factory produces configured Agent instances from YAML
agent = factory.create_agent_from_yaml_path("agent.yaml")
agent = factory.create_agent_from_yaml(yaml_string)

The factory resolves the provider class by looking up a composite key of "Provider.ApiType" (or just "Provider") in its internal mapping table, which maps to a specific package, class name, and model ID field:

Provider Key	Package	Class	Model ID Field
AzureOpenAI.Chat	agent_framework.azure	AzureOpenAIChatClient	deployment_name
AzureOpenAI.Responses	agent_framework.azure	AzureOpenAIResponsesClient	deployment_name
OpenAI.Chat	agent_framework.openai	OpenAIChatClient	model_id
OpenAI.Responses	agent_framework.openai	OpenAIResponsesClient	model_id
Anthropic.Chat	agent_framework.anthropic	AnthropicChatClient	model_id
AzureAIClient	agent_framework.azure	AzureAIClient	model_deployment_name

Related Pages

Implemented By

• Implementation:Microsoft_Agent_framework_AgentFactory_Init