* [BREAKING] Rename ChatAgent -> Agent, ChatMessage -> Message, ChatClientProtocol -> SupportsChatGetResponse Simplify the public API by removing redundant 'Chat' prefix from core types: - ChatAgent -> Agent - RawChatAgent -> RawAgent - ChatMessage -> Message - ChatClientProtocol -> SupportsChatGetResponse Also renamed internal WorkflowMessage (was Message in _runner_context) to avoid collision. No backward compatibility aliases - this is a clean breaking change. * [BREAKING] Rename Agent chat_client parameter to client * Fix rebase issues: WorkflowMessage references and broken markdown links * Fix formatting and lint issues from code quality checks * Fix import ordering in workflow sample files * fixed rebase * Fix test failures: use WorkflowMessage and A2AMessage after ChatMessage→Message rename - Replace Message(data=..., source_id=...) with WorkflowMessage(...) in workflow tests - Fix isinstance check in A2A agent to use A2AMessage instead of Message - Fix import in test_workflow_observability.py (Message→WorkflowMessage) * Fix lint, fmt, and sample errors after ChatMessage→Message rename - Auto-fix 70+ ruff lint issues across samples (ChatMessage→Message refs) - Fix HostedVectorStoreContent→Content.from_hosted_vector_store in file search sample - Fix _normalize_messages→normalize_messages in custom agent sample - Fix context.terminate→raise MiddlewareTermination in middleware samples - Fix with_update_hook→with_transform_hook in override middleware sample - Add TOptions_co import back to custom_chat_client sample - Add noqa for FastAPI File() default in chatkit sample - Fix B023 loop variable capture in weather agent sample * fix: update Agent constructor calls from chat_client to client in declaration-only tool tests * fix: add register_cleanup to devui lazy-loading proxy and type stub * fixed tests and updated new pieces * fix agui typevar * fix merge errors * fix merge conflicts * fiux merge * Remove unused links --------- Co-authored-by: Evan Mattson <evan.mattson@microsoft.com>
Custom Agent and Chat Client Examples
This folder contains examples demonstrating how to implement custom agents and chat clients using the Microsoft Agent Framework.
Examples
| File | Description |
|---|---|
custom_agent.py |
Shows how to create custom agents by extending the BaseAgent class. Demonstrates the EchoAgent implementation with both streaming and non-streaming responses, proper thread management, and message history handling. |
custom_chat_client.py |
Demonstrates how to create custom chat clients by extending the BaseChatClient class. Shows a EchoingChatClient implementation and how to integrate it with Agent using the as_agent() method. |
Key Takeaways
Custom Agents
- Custom agents give you complete control over the agent's behavior
- You must implement both
run()for both thestream=Trueandstream=Falsecases - Use
self._normalize_messages()to handle different input message formats - Use
self._notify_thread_of_new_messages()to properly manage conversation history
Custom Chat Clients
- Custom chat clients allow you to integrate any backend service or create new LLM providers
- You must implement
_inner_get_response()with a stream parameter to handle both streaming and non-streaming responses - Custom chat clients can be used with
Agentto leverage all agent framework features - Use the
as_agent()method to easily create agents from your custom chat clients
Both approaches allow you to extend the framework for your specific use cases while maintaining compatibility with the broader Agent Framework ecosystem.
Understanding Raw Client Classes
The framework provides Raw...Client classes (e.g., RawOpenAIChatClient, RawOpenAIResponsesClient, RawAzureAIClient) that are intermediate implementations without middleware, telemetry, or function invocation support.
Warning: Raw Clients Should Not Normally Be Used Directly
The Raw...Client classes should not normally be used directly. They do not include the middleware, telemetry, or function invocation support that you most likely need. If you do use them, you should carefully consider which additional layers to apply.
Layer Ordering
There is a defined ordering for applying layers that you should follow:
- ChatMiddlewareLayer - Should be applied first because it also prepares function middleware
- FunctionInvocationLayer - Handles tool/function calling loop
- ChatTelemetryLayer - Must be inside the function calling loop for correct per-call telemetry
- Raw...Client - The base implementation (e.g.,
RawOpenAIChatClient)
Example of correct layer composition:
class MyCustomClient(
ChatMiddlewareLayer[TOptions],
FunctionInvocationLayer[TOptions],
ChatTelemetryLayer[TOptions],
RawOpenAIChatClient[TOptions], # or BaseChatClient for custom implementations
Generic[TOptions],
):
"""Custom client with all layers correctly applied."""
pass
Use Fully-Featured Clients Instead
For most use cases, use the fully-featured public client classes which already have all layers correctly composed:
OpenAIChatClient- OpenAI Chat completions with all layersOpenAIResponsesClient- OpenAI Responses API with all layersAzureOpenAIChatClient- Azure OpenAI Chat with all layersAzureOpenAIResponsesClient- Azure OpenAI Responses with all layersAzureAIClient- Azure AI Project with all layers
These clients handle the layer composition correctly and provide the full feature set out of the box.