microsoft/semantic-kernel
1
0
Fork 0
mirror of https://github.com/microsoft/semantic-kernel.git synced 2026-10-12 11:19:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
4,997 Commits 64 Branches 1,077 Tags
copilot/bump-messagepack-version
Commit Graph
95 Commits
Author SHA1 Message Date
SergeyMenshykhandCopilot 61331d834d Python: Add function_choice_behavior support to Azure AI and OpenAI Assistant agents (#14057) 
### Description

Adds `function_choice_behavior` parameter to Azure AI and OpenAI
Assistant agents, aligning them with the existing Responses agent and
Chat Completion agent APIs.

### Changes

- Add `function_choice_behavior` parameter to
`invoke`/`invoke_stream`/`get_response` on both `AzureAIAgent` and
`OpenAIAssistantAgent` public APIs
- Add `function_choice_behavior` parameter to internal
`AzureAIAgentThreadActions` and `AssistantThreadActions`
`invoke`/`invoke_stream` methods
- Support `tools` parameter override for SDK-level tools
(CodeInterpreter, FileSearch, etc.)
- Filter kernel functions based on `FunctionChoiceBehavior`
configuration
- Validate that only `Auto` type with auto-invoke enabled is supported
- Fix `_get_tools` in OpenAI path to use passed `kernel` parameter
instead of `agent.kernel`
- Add comprehensive unit tests for both thread actions and public agent
APIs

---------

Co-authored-by: Copilot <[email protected]>
 2026-06-08 16:31:55 +00:00
ふぁーandEvan Mattson eeeccb4596 Python: Respect FunctionChoiceBehavior filters in OpenAI responses agent tools (#13235) 
issue: https://github.com/microsoft/semantic-kernel/issues/13234

## Summary
- honor FunctionChoiceBehavior filters when retrieving kernel function
metadata
 
### Contribution Checklist

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄

---------

Co-authored-by: Evan Mattson <[email protected]>
 2026-04-08 01:24:47 +00:00
Tao Chen d5c2b9d889 Python: Improves the robustness of filename handling (#13643) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Improves the robustness of filename handling in the Bedrock agent
integration. Ensures that filenames sourced from external responses are
properly sanitized before use in file operations, and adds safer
defaults for file write behavior.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
1. Sanitize filenames received from Bedrock agent responses.
2. Add overwrite parameter to BinaryContent.write_to_file (defaults to
False).
3. Add tests.
4. Update samples.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
 2026-03-12 17:02:02 +00:00
Eduard van Valkenburg 72bc02551f Python: added allowed_domains to HttpPlugin (#13462) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Adds allowed_domains setup for HttpPlugin.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2026-01-22 12:52:56 +09:00
Taylor Rockey e73446e86e Python: [Python] Updated Agents SDK version to latest for CopilotStudio connector (#13144) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
- The Agents SDK has been released, and the recent release changed the
namespace from `microsoft.agents` to `microsoft_agents`, which breaks
imports.
  2. What problem does it solve?
- This updates the `pyproject.toml` and copilot studio related files to
fix the imports
  3. What scenario does it contribute to?
      - Using a Copilot Studio agent as an Agent in Semantic Kernel
  4. If it fixes an open issue, please link to the issue here.
      - N/A
-->

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

- Updated pyproject.toml to use the released packages for the Agents
SDK.
- Updated imports in the `copilot_studio_agent` related files to use the
new `microsoft_agents` namespace

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [] I didn't break anyone 😄
 2025-09-23 01:01:51 +00:00
Evan Mattson 22ff5f844f Python: Fix responses agent kernel args bug (#13056) 
### Motivation and Context

The `arguments: KernelArguments` are not getting handled properly for
the Responses Agent invoke. Use the provided `arguments` instead of
trying to get them from the kwargs.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

- Closes #13053
- Adds unit test coverage. 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-09-04 01:27:27 +00:00
Evan Mattson 86b10b95d2 Python: provide AzureAIAgent thread msg id during streaming (#13032) 
### Motivation and Context

As part of invoking an AzureAIAgent via streaming, we weren't providing
the `thread_id` via the `AgentStreamEvent.THREAD_MESSAGE_CREATED` event.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Supply the caller with the `thread_msg_id` by sticking it into the
returned SCMC's `metadata` dictionary.
- Closes #12959

Sample output looks like:

```
Sample Output:

# User: 'Hello'
# AuthorRole.ASSISTANT: (thread message id: msg_HZ2h4Wzbj7GEcnVCjnyEuYWT) Hello! How can I assist you with 
    the menu today?
# User: 'What is the special soup?'
# AuthorRole.ASSISTANT: (thread message id: msg_TSjkJK6hHJojIkPvF6uUofHD) The special soup today is 
    Clam Chowder. Would you like to know more about it or anything else from the menu?
# User: 'How much does that cost?'
# AuthorRole.ASSISTANT: (thread message id: msg_liwTpBFrB9JpCM1oM9EXKiwq) The Clam Chowder costs $9.99. 
    Is there anything else you'd like to know?
# User: 'Thank you'
# AuthorRole.ASSISTANT: (thread message id: msg_K6lpR3gYIHethXq17T6gJcxi) You're welcome! 
    If you have any more questions or need assistance, feel free to ask. Enjoy your meal!
```

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-08-30 10:05:55 +00:00
Christian GlessnerEvan MattsonEvan Mattson
 		5e50e190c4 Python: Add reasoning support for OpenAI Responses Agents (GPT-5, o4-mini, o3) (#12881) 
## Summary

Adds reasoning capabilities to Python OpenAI ResponsesAgent, bringing
parity with the C# implementation. This enables fine-grained control
over reasoning effort for O-series models (o1, o3-mini, o4-mini) and
gpt-5 that support the reasoning parameter.

Fixes #12843

## Changes

### Core Implementation
- **`openai_responses_agent.py`**: Added reasoning configuration support
  - Constructor-level reasoning effort setting
  - Per-invocation reasoning effort override capability
  - Proper parameter validation and model compatibility checks
- **`responses_agent_thread_actions.py`**: Extended thread actions to
support reasoning parameters
  - Reasoning effort propagation through thread operations
  - Metadata preservation for reasoning tokens and summaries

### Sample and Tests
- **`responses_agent_reasoning.py`**: Comprehensive demonstration sample
  - Constructor vs per-invocation reasoning configuration
  - Function calling integration with reasoning
  - Reasoning comparison scenarios (low/medium/high effort)
  - Error handling and troubleshooting guidance
- **`test_openai_responses_agent_reasoning.py`**: Full unit test
coverage
  - Parameter validation tests
  - Integration scenarios with function calling
  - Edge cases and error conditions

## Features

✅ **Constructor-Level Reasoning**: Set default reasoning effort when
creating agents
✅ **Per-Invocation Override**: Override reasoning effort per request  
✅ **Priority Hierarchy**: per-invocation > constructor > model default  
✅ **Function Calling Compatible**: Works seamlessly with existing plugin
system
✅ **Azure OpenAI & OpenAI Support**: Compatible with both service
providers
✅ **Model Validation**: Automatic compatibility checks for O-series
models nad GÜT-5
✅ **Metadata Access**: Reasoning tokens and summaries available in
response metadata

## Usage Example

```python
# Constructor-level reasoning
# Constructor-level reasoning configuration
agent = AzureResponsesAgent(
    ai_model_id="gpt-5",
    client=client,
    reasoning={"effort": "low"}  # Default reasoning for all requests
)

# Per-invocation override
response = await agent.invoke(
    "Solve this complex problem step by step",
    reasoning={"effort": "high"}  
)


# Invoke with reasoning callback to capture intermediate thoughts
response = await agent.invoke(
    "Analyze this data step by step",
    reasoning={"effort": "high", "summary": "detailed"},
    on_intermediate_message=handle_reasoning_message
)

# Streaming with reasoning
async for response in agent.invoke_stream(
    "Explain quantum computing in detail",
    reasoning={"effort": "high", "summary": "detailed"},
    on_intermediate_message=handle_reasoning_message
):
    print(response.content, end="", flush=True)

---------

Co-authored-by: Evan Mattson <[email protected]>
Co-authored-by: Evan Mattson <[email protected]>
 2025-08-28 23:25:26 +00:00
Dmytro Struk 2a47ba9b7d Python: Removed usage of DefaultAzureCredential (#12964) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

The usage of `DefaultAzureCredential` by default is unsafe and raises
security issues. Instead, users should provide their own credential
types such as `AzureCliCredential`, `ManagedIdentityCredential` and so
on. More information here:

https://learn.microsoft.com/en-us/python/api/azure-identity/azure.identity.aio?view=azure-python

In this PR:
1. Removed the usage of `DefaultAzureCredential` from authentication
logic.
2. Replaced `DefaultAzureCredential` with `AzureCliCredential` in all
examples.

**Note**: this is breaking change for Azure users, who relies on
`DefaultAzureCredential`. Users will need to update the code and pass
the credential type of their choice by using `credential` parameter when
initializing one of the Azure clients.

Before:
```python
chat_completion = AzureChatCompletion()
```

After:
```python
chat_completion = AzureChatCompletion(credential=AzureCliCredential())
```

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
 2025-08-25 18:29:13 +00:00
Evan Mattson 40734345dc Python: Fix the Responses agent msg chaining with reasoning models (#12907) 
### Motivation and Context

When running a reasoning model with the OpenAI responses agent, it was
producing 400s due to the way we were either including or not including
FCC related to tool calls. This PR fixes it for both the default
(store_enabled=True) and the case where uses don't want to use OpenAI's
previous response id as a pseudo-thread (store_enabled=False).

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

- Closes #12843

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-08-13 10:35:38 +00:00
Evan Mattson 91392a77e0 Python: Fix ResponsesAgent image duplication in chat history preparation (#12859) 
### Motivation and Context

The ResponsesAgent is duplicating messages in chat history preparation
when messages contained multiple content items (text + images). The
`response_inputs.append()` call is inside the content processing loop,
causing each message to be added once per content item.

The fix:
- Moved `response_inputs.append()` outside the content processing loop
- Added unit test to verify multiple images don't get duplicated

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

- Fixed loop placement in `_prepare_chat_history_for_request`
- Added test `test_prepare_chat_history_multiple_images_no_duplication`
- Fixes #12848

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-08-05 14:58:35 +00:00
Evan Mattson 5332c2e330 Python: Require tool_call_id parameter for string-based tool messages in ChatHistory (#12753) 
### Motivation and Context

The `add_tool_message` method of `ChatHistory` accepts string content
without requiring a `tool_call_id` parameter. This design is flawed from
an API design perspective. It created tool messages that:

1. Violated chat completion protocols: most LLM APIs (OpenAI, etc.)
require tool messages to have a `tool_call_id` that references a
previous function call
2. Broke conversation flow: tool messages should always be responses to
specific tool calls, maintaining the call-response relationship
3. Created malformed message sequences: messages without proper tool
call IDs would fail when sent to language models

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

This PR modifies the `add_tool_message` string overload to require a
`tool_call_id` parameter, which makes sure we have proper tool call
protocol compliance.

1. The string overload now validates that `tool_call_id` is provided and
raises a clear error if missing
2. Tool messages now create `FunctionResultContent` objects with both
`id` and `call_id` set to the provided `tool_call_id`
3. Added support for an optional `function_name` parameter for better
bookkeeping
4. Provides informative error messages explaining why `tool_call_id` is
required
- Closes #12744 

Before:

```python
# This would create an invalid tool message without tool_call_id
# when the `.to_dict()` method is called on `ChatMessageContent`
chat_history.add_tool_message("Function result")  # Creates broken message and losing pairing to the corresponding `FunctionCallContent`.
```

After: 

```python
# Now requires tool_call_id for proper protocol compliance
chat_history.add_tool_message("Function result")  # raises clear error due to missing `tool_call_id`
chat_history.add_tool_message("Function result", tool_call_id="call_123")  # works correctly

# Optional function name for better bookkeeping
chat_history.add_tool_message("Function result", tool_call_id="call_123", function_name="get_weather") # works as well
```

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-07-23 04:07:20 +00:00
Evan Mattson d4f6703cf3 Python: fix Bing grounding & custom search content generation (#12760) 
### Motivation and Context

The same `agent_content_generation` method is used to handle both
`bing_grounding` and `bing_custom_search` tool calls; however, the
method expected that the dicts on the underlying types were named the
same - which they aren't. They have their respective names, as shown
above.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Fix Bing content generation based on the instance we're dealing with.
- Add unit tests.
- Closes #12746

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-07-23 03:17:29 +00:00
Tao Chen b723fbd5e1 Python: Add mix agent orchestration sample (#12749) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
We don't have a sample showing how to use a mix of agents of various
types in an orchestration. This PR adds one.
A bug is also discovered in the OpenAIResponsesAgent while creating the
sample.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
1. Add a new sample showing how to use a mix of agents in the Handoff
orchestration.
2. Fix a bug in the OpenAIResponsesAgent where the tools were not
considering the tools in the kernel instance. A new test is added too.
3. Fix a bug in the AgentActorBase where the intermediate message
callback was rejecting ChatMeesageContent type.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-07-22 16:57:05 +00:00
Tao Chen b74ea05540 Python: Improve orchestration exception handling (#12716) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Currently, exceptions that occur inside the orchestration actors are not
properly surfaced to the caller as it happens.

Fixes: https://github.com/microsoft/semantic-kernel/issues/12719

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
This PR addresses the issue by introducing a new exception_callback that
is hidden from the user but will raise exceptions that occurs inside the
orchestration actors to the caller.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-07-15 23:03:22 +00:00
Evan Mattson c15c885f84 Python: Emit partial result for magentic pattern when retrieving final result, if available (#12656) 
### Motivation and Context

When using the magentic orchestration pattern, if the `max_round_count`
is hit, the final result shows as:

```
Final result:
Max round count reached.
```

The interim messages do show as part of the `agent_response_callback`;
however, not everyone may have that configured. We should return more
meaningful results, even if partial. This PR updates to try and get a
partial result if it exists. When one calls:

```python
value = await orchestration_result.get()
```

for the `step5_magentic.py` sample, with `max_round_count=1` they should
receive the partial result:

```
Final result:
Based on the available data, here is a comparison of the estimated training and inference energy consumption for ResNet-50, BERT-base, and GPT-2, along with the associated CO₂ emissions when training on an Azure Standard_NC6s_v3 VM for 24 hours.

**Model Architectures and Datasets:**

- **ResNet-50**: Image classification model trained on ImageNet.
- **BERT-base**: Text classification model fine-tuned on the GLUE benchmark.
- **GPT-2**: Text generation model trained on WebText.

... <rest omitted for brevity> ...
```

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Return partial results for magentic orchestration if they exist.
- Closes #12625

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-07-02 15:18:27 +00:00
Tao Chen 44f1253460 Python: Agent response callbacks to provide full context (#12501) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Currently, the agent response callbacks in the `Orchestrations` are
triggered only when the final responses from the agents become
available. This limits developers to create solutions that can expose
the internal processing of the agents in multi agent orchestrations.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
The callbacks will now be triggered by the intermediate messages of the
agents:
1. A new sample
2. Tests

P.s. Fix a bug where the name of the intermediate messages is not
assigned.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-06-17 16:17:11 +00:00
Tao Chen dfbc993d8f Python: Remove orchestration persona adaptation messages (#12446) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
We previously found that agents might get carried away from in long
contexts. The persona adaptation messages were designed to steer the
agents in an orchestration to respond more closely to the instructions
provided (as system message).

As we perform more testing with newer models, we believe that the
persona adaptation messages are no longer necessary. The additional
instability (because they are hardcoded messages that devs can't
override) and cost (the additional token cost which is not significant,
but they do pollute the context which makes debugging difficult) they
introduce is not worth the benefit they provide.


Closing #12294 


> Ideally, we'd want to approach this more analytically. The lack of a
multi-agent evaluation process makes it difficult. All samples were
verified to make sure they behave the same before and after the removal
of the persona adaptation messages.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
1. Remove the persona adaptation messages.
2. Unit tests.
3. Replace `OpenAIChatCompletion` with `AzureChatCompletion` in some of
the samples.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-06-11 15:58:21 +00:00
Tao Chen 3baaee2ff3 Python: streaming agent response callback in agent orchestrations (#12360) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Issue: #12306 
Discussion: #12302 

Currently, we only have a **non-streaming** agent response callback for
users to interact with the agents inside an orchestration. Support for a
stream one has been requested by developers.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
Add support for a streaming agent response callback to all
orchestrations.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-06-04 23:06:58 +00:00
Evan Mattson ff1997047d Python: Support Declarative Spec for OpenAIAssistantAgent & OpenAIResponsesAgent (#12247) 
### Motivation and Context

This PR builds on the initial work/abstractions from #11982. The
`AzureAssistantAgent` / `OpenAIAssistantAgent` as well as the
`AzureResponsesAgent` / `OpenAIResponsesAgent` now support declarative
specs. Several examples on how to declare the spec are shown in the
respective dirs in `samples/concepts/agents`, as well as a simple
getting started example for each agent type.

To further simplify working with these two agents, the
`setup_resources()` methods for each agent type have been marked with a
deprecation tag. The new method to use is
`OpenAIAssistantAgent.create_client()` or
`OpenAIResponsesAgent.create_client()`. Further, when one needs to
access the underlying setting's, it's simple to do so with a settings
object and accessing the attribute.

In the previous PR for the AzureAIAgent, it lacked support for
templating - this is included in this current PR.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Bring in support for the declarative single agent spec for these agent
types.
- Add samples
- Add unit tests
- Add support for prompt templates for all current agent types
- Closes #11979

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-26 05:02:59 +00:00
Evan Mattson afb1e15724 Python: Relax Agent Invocation Methods to Allow Positional or Keyword Arguments for messages (#12248) 
### Motivation and Context

This PR relaxes the API signatures of all agent invocation methods
(`get_response`, `invoke`, `invoke_stream`) by changing the `messages`
parameter from keyword-only to positional-or-keyword. This enhances
ergonomics and Pythonic usability by allowing callers to pass messages
either positionally or as a keyword argument:

```python
agent.get_response("Why is the sky blue?")
agent.get_response(messages="Why is the sky blue?")
```

With our current use of **kwargs, it is possible to explicitly pass None
for messages (like `agent.get_response(messages=None)`). However, this
does not feel idiomatic in Python. If a caller wishes to invoke the
agent on an existing thread (which already contains all relevant
context), it is more natural and Pythonic to simply write:

```python
response = await agent.get_response()
```

This change makes the API more user-friendly, and removes unnecessary
verbosity when no new messages need to be provided.

Impact
- Backward compatible for all previous usage.
- Enables concise and intuitive API calls for primary message arguments.
- Subclasses overriding the prior keyword-only signature will continue
to work at runtime, but static type-checkers may require updating their
signatures to match the new base definition.
- No runtime breaking changes are expected.

| Scenario | Breaks at runtime? | Breaks at type-check? | Notes |

|----------------------------------|----------------------|-------------------------|--------------------------------------------------|
| Subclass w/keyword-only | No | Yes | Type checker error, but runtime
OK |
| Subclass matching base | No | No | Fine |
| Calls expecting keyword-only | No | No | Fine |
| Calls expecting positional | No (now allowed) | No | Improved
ergonomics |
| Decorators relying on kw-only | No | No (unless strict sig) | Only if
decorator is brittle, rare |
| Code generation/docs | No | No | Needs updating docs, not an actual
code break |
| Reflection-based invocation | No | No | Slight difference in behavior,
but not breaking |


Documentation and usage examples will be updated to reflect the improved
invocation style.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Relaxes the API signatures of all agent invocation methods.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-23 13:24:04 +00:00
Evan Mattson 0eec353504 Python: Add OpenAI's sequence_number attribute to unit tests based on their latest package (#12227) 
### Motivation and Context

OpenAI release a new python package (1.81.0) which has some updates to
the underlying Pydantic models for the Responses API. We need to pull in
a new change for `ResponseOutputItemDoneEvent`,
`ResponseOutputItemAddedEvent`, and `ResponseTextDeltaEvent` for
streaming invocation which now has `sequence_number` attribute.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Bring in a change from OpenAI's Python SDK from v1.81.0 related to SK's
OpenAIResponsesAgent.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-22 04:20:29 +00:00
Evan MattsonandTao Chen c64e51c40e Python: Update the AzureAIAgent packages, types, and APIs based on Azure SDK's new code (#12084) 
### Motivation and Context

The Azure AI Agent Service is moving to GA soon. As part of that,
they've made several changes in the underlying APIs, which require the
use of new packages, updated type imports and some new underlying APIs.
This PR updates the AzureAIAgent to use the latest Azure SDK's new code.

- The client's connection string has been replaced with an endpoint.
- The `AzureAIAgentSettings`'s `model_deployment_name` was updated to
`deployment_name`.
- Tools are now imported from `from azure.ai.agents.models` instead of
`from azure.ai.projects.models`.
- Declarative spec handling for AzureAIAgent was updated based on the
new APIs.
- Unit tests were updated.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Update the AzureAIAgent related code, samples and tests based on the
Azure SDK's latest APIs.
- Closes #12177 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄

---------

Co-authored-by: Tao Chen <[email protected]>
 2025-05-19 23:43:40 +00:00
Evan Mattson b88f05287a Python: Preserve Citation Title in AnnotationContent from Azure AI Foundry Annotations (#12152) 
### Motivation and Context

When invoking an Azure AI Foundry agent via AzureAIAgent, url_citation
metadata such as the document filename (title) is omitted in the
resulting AnnotationContent. Only the url field is populated; the
filename (title) is lost, and no structured metadata is retained. This
breaks traceability and rich citation in downstream responses.

This PR updates the annotation mapping to include the title from
url_citation into the resulting AnnotationContent.

This PR also updates the content types to properly show the present
information either in the `to_dict()` call or `to_str` call, as well as
handling the attributes for the `from_element` class method.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Citations in responses returned via AzureAIAgent now retain the full
provenance information (url, title, etc.) as delivered by the underlying
agent, matching the behavior observed with direct AIProjectClient calls.
- Closes #12133 
- Adds further unit tests to validate functionality

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-19 17:29:31 +00:00
Tao ChenandEvan Mattson d67f568d99 Python: Multi-agent orchestration: Magentic (#12104) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
PR for Magentic multi-agent orchestration.
ADR:
https://github.com/microsoft/semantic-kernel/blob/main/docs/decisions/0071-multi-agent-orchestration.md
Initial PR: https://github.com/microsoft/semantic-kernel/pull/11993

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

This PR includes the following:

1. Implementations for the magentic orchestrations
2. Unit tests and samples

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄

---------

Co-authored-by: Evan Mattson <[email protected]>
 2025-05-16 21:53:43 +00:00
Evan Mattson 50cf782645 Python: Remove Copilot Studio Direct link from Pyproject.toml (#12068) 
### Motivation and Context

The pyproject.toml currently references Microsoft Copilot Studio
packages that are only on test PyPI, and not yet available on the Public
PyPI repo. This breaks the ability to push the public SK package to
PyPI.

We will, until public PyPI packages are available, remove the extra from
our pyproject.toml and place explicit package install instructions in
the Copilot Studio Agent README.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Explicit instructions on how to install the necessary packages to use
the CopilotStudioAgent while the packages are on Test PyPI.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-15 00:50:48 +00:00
Tao Chen ee962943d6 Python: Multi-agent orchestration: Handoff (#12046) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
PR for Handoff multi-agent orchestration.
ADR:
https://github.com/microsoft/semantic-kernel/blob/main/docs/decisions/0071-multi-agent-orchestration.md
Initial PR: https://github.com/microsoft/semantic-kernel/pull/11993

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

This PR includes the following:

1. Implementations for the handoff orchestrations
2. Unit tests and samples

Follow up PRs will add the following:

- Magentic One

Contribution Check

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-05-14 22:50:56 +00:00
Tao Chen d826ad8d5a Python: Multi-agent orchestration: Group Chat (#12045) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
PR for Group Chat multi-agent orchestration.
ADR:
https://github.com/microsoft/semantic-kernel/blob/main/docs/decisions/0071-multi-agent-orchestration.md
Initial PR: https://github.com/microsoft/semantic-kernel/pull/11993

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
This PR includes the following:

1. Implementations for the group chat orchestrations
2. Unit tests and samples

Follow up PRs will add the following:

- Handoff
- Magentic One


### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-05-14 21:45:37 +00:00
Evan Mattson ea3215ebb7 Python: Support Declarative Agent Spec for ChatCompletionAgent & AzureAIAgent (#11982) 
### Motivation and Context

This is the first installment of a series of PRs related to adding
single agent declarative spec support.

SK .NET has had support for single agent declarative specs for a bit
now, and Python needs the functionality as well. This PR adds the core
abstractions and functionality to be able to define agents via a
declarative yaml spec.

Declarative specs require the use of a kernel, and if in the case of
function calling, require that any plugins defined in the spec already
be present in the kernel.

For naming, there are placeholder names that are camel case. This needs
to be the case so it can match .NET.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Provide declarative spec support for ChatCompletionAgent and
AzureAIAgent
- Adds many samples to show the use of declarative specs to handle
various AzureAIAgent + ChatCompletionAgent tools/plugins.
- Closes #11978

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-13 23:14:36 +00:00
Tao ChenandEvan Mattson 6eff772c60 Python: Multi-agent orchestration: Concurrent + Sequential (#11993) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Initial PR for multi-agent orchestration.
ADR:
https://github.com/microsoft/semantic-kernel/blob/main/docs/decisions/0071-multi-agent-orchestration.md


### Description
This is the initial PR for multi-agent orchestration. This PR includes
the following:
1. Base classes
2. Implementations for the concurrent and sequential orchestrations
3. Unit tests and samples

Follow up PRs will add the following:
- Group chat
- Handoff
- Magentic One

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄

---------

Co-authored-by: Evan Mattson <[email protected]>
 2025-05-13 16:28:09 +00:00
Evan Mattson 4724dbc8f3 Python: Fix AzureAIAgent intermediate message ordering for invoke and invoke_stream (#12005) 
### Motivation and Context

This PR fixes a core issue in `AzureAIAgent` where `FunctionCallContent`
and `FunctionResultContent` messages were not being emitted in the
correct order during `invoke()` and `invoke_stream()` execution.

- `invoke_stream`: tool messages are now drained and emitted after each
streamed assistant chunk, preserving causal ordering (tool call ->
result -> assistant reply).
- `invoke`: tool messages are emitted via callback immediately after the
non-streaming response is received, ensuring they precede the final
assistant message if applicable.

### Description

Updated samples to better show how the callbacks are used to receive the
intermediate messages in the proper order.
- Added unit tests to ensure proper coverage and message ordering.
- Closes #11999

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-12 22:58:06 +00:00
Evan Mattson b07454aff8 Python: Fix OpenAIAssistantAgent/OpenAIResponsesAgent intermediate message ordering for invoke and invoke_stream (#12008) 
### Motivation and Context

This PR fixes a core issue in `OpenAIAssistantAgent` and
`OpenAIResponsesAgent` where `FunctionCallContent` and
`FunctionResultContent` messages were not being emitted in the correct
order during `invoke()` and `invoke_stream()` execution.

- `invoke_stream`: tool messages are now drained and emitted after each
streamed assistant chunk, preserving causal ordering (tool call ->
result -> assistant reply).
- `invoke`: tool messages are emitted via callback immediately after the
non-streaming response is received, ensuring they precede the final
assistant message if applicable.

### Description

Updated samples to better show how the callbacks are used to receive the
intermediate messages in the proper order.
- Added unit tests to ensure proper coverage and message ordering.
- Closes #12007

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
 2025-05-12 22:45:43 +00:00
Evan Mattson fb2fc6b30c Python: Fix ChatCompletionAgent intermediate message ordering for invoke and invoke_stream (#12000) 
### Motivation and Context

When using the `on_intermediate_message` callback, we are returning
messages to the caller in an incorrect order. While using function
calling, the order is:

1. Provide user input to agent that requires a tool call
2. FunctionCallContent chunks returned via callback
3. FunctionResultContent returned via callback
4. Final output (StreamingTextContent/TextContent) from agent returned
via invoke_stream/invoke

What we are really seeing is:
1. Provide user input to agent that requires a tool call
2. Final output (StreamingTextContent/TextContent) from agent returned
via invoke_stream/invoke
3. FunctionCallContent chunks returned via callback
4. FunctionResultContent returned via callback

The callback needs a bit of adjusting -- for the streaming case it must
emit messages as part of handling the AsyncGen response_list loop.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Fix the ordering of the intermediate callback so messages aren't
received out of order.
- Adds unit tests to check message order
- Adjusts some samples
- Closes #11998 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-12 07:45:08 +00:00
Evan Mattson fa919883c8 Python: Fix fallback logic overriding custom ChatHistory in ChatHistoryAgentThread (#11976) 
### Motivation and Context

Fixes a bug where passing a valid `ChatHistoryReducer` into
`ChatHistoryAgentThread` would be silently overridden by a base
`ChatHistory` instance due to a falsy evaluation. There is now an
explicit `is not None` check to make sure the reducer behavior is
preserved.

Python is using the ChatHistory `__len__` override as part of the
truthiness check. The initial ChatHistoryReducer(ChatHistory) has no
messages when created, so it is evaluated as False.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Fixes a bug where we overwrite a passed in ChatHistoryReducer object
with a base ChatHistory.
- Adds unit tests

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-12 00:55:07 +00:00
Tao ChenEduard van ValkenburgEvan Mattson
 		07017af710 Python: Port Agent Runtime to SK repo (#11873) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Porting the agent runtime to SK repo for multi-agent orchestration work.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
1. Core runtime abstraction and in-process runtime implementation.
2. Unit tests.
3. Mark all public classes and methods experimental.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄

---------

Co-authored-by: Eduard van Valkenburg <[email protected]>
Co-authored-by: Evan Mattson <[email protected]>
 2025-05-07 12:33:36 +00:00
Evan Mattson 1a187b03bc Python: Introduce the Copilot Studio Agent (#11851) 
### Motivation and Context

Semantic Kernel Python currently has a demo showing how to interact with
a Copilot Studio Agent; however, that uses the `DirectLine API`. This PR
introduces a Semantic Kernel `CoilotStudioAgent` that leverages the
team's new `microsoft.agents.copilotstudio.client`. One must first have
a Copilot Studio Agent created via the portal; and once ready, they can
reference it with the proper App Registration and Agent metadata.
Interacting with the Agent can leverage Microsoft Copilot Studio's
knowledge sources and internal tools.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Add support for the `CopilotStudioAgent`. 
- Provide getting started samples
- Introduces a detailed README on what is required for setup and
interacting with the agent.
- The current version of the `CopilotStudioAgent` does not support
calling another Copilot Studio Agent via a skill.
- Authentication for the agent is limited to interactive right now. Once
service-to-service auth is support via the client, we will add this into
SK.
- Closes #11607

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-06 10:29:29 +00:00
Evan Mattson 89ef228f93 Python: Per deprecation message and date remove add_chat_message from AzureAIAgent and OpenAIAssistantAgent (#11827) 
### Motivation and Context

Per the deprecation message on the method `add_chat_message(...)`
currently on the `AzureAIAgent` and `OpenAIAssistantAgent` classes, we
are removing the method in favor of passing in any messages directly to
the `get_response(...)`, `invoke(...)` or `invoke_stream(...)`. The
underlying thread abstraction handles adding the messages to the thread
as part of invocation.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Remove the methods per the deprecation message and date.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-05-02 07:38:19 +00:00
Evan Mattson d7e4e3f12a Python: Support polling options at run-level for AzureAIAgent, OpenAIAssistantAgent, and OpenAIResponsesAgent (#11705) 
### Motivation and Context

Based on feedback, there are customer scenarios where it can be helpful
to be able to pass in run-level polling options, instead of only at the
agent definition/constructor level.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Add run-level run polling options parameter.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-25 15:04:00 +00:00
Evan Mattson da1e1e5b63 Python: Fix Agent StreamingTextContent Yielding and Proper Handling of FunctionCallContent/FunctionResultContent (#11563) 
### Motivation and Context

This PR addresses an issue where responses during the `invoke_stream`
call were not being properly filtered by content type. The bug caused
the system to yield responses containing non-text content (i.e.,
FunctionCallContent or FunctionResultContent) directly, rather than
routing them through the on_intermediate_message callback for
specialized handling. The fix ensures that only responses exclusively
composed of StreamingTextContent are yielded, while other
function-related content types are passed to the appropriate callback.

Additionally, the `ChatHistoryAgentThread` id property wasn't set - it
was configuring a `_thread_id`, which the base class doesn't use.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

- Properly yield expected content type `StreamingTextContent` from an
agent `invoke_stream(...)` call. Other FCC or FRC types are yielded via
the `on_intermediate_message` callback.
- Fix `ChatHistoryAgentThread` id bug that was setting `_thread_id`
instead of `_id`.
- Update integration tests to make sure we receive the expected content
types during function call invocations.
- Closes #11561
- Closes #11535 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-16 00:23:34 +00:00
Eduard van Valkenburg 12851923bc Python: allow settings to be created directly (#11468) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
I've always hated having to add the .create to a settings object, this
removes that, you can just use the regular init, added benefit is that
it has the proper fields in the docstrings for each implemented settings
object!

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
Adds a __new__ method to the base settings class, which takes the prefix
and if supplied the env_file and encoding, then calls model_rebuild and
then the init.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-04-11 06:26:22 +00:00
Evan Mattson 6f35b627f4 Python: Support Auto Function Invocation Filter for AzureAIAgent and OpenAIAssistantAgent (#11460) 
### Motivation and Context

The server-side agents like AzureAIAgent and OpenAIAssistantAgent do not
support the Auto function invocation filter. Although we return
intermediate step results, like FunctionResultContent, as part of the
`on_intermediate_steps` callback, this didn't allow for developers to
configure a filter to return the result as-is, or modify the result as
part of the filter.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Add support for the auto function invocation filter for the
`AzureAIAgent` and `OpenAIAssistantAgent`.
- Closes #11054
- Closes #11456 
- Adds samples on how to configure the filter for both agent types, and
how to configure the callback to show the various content types.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-10 00:39:47 +00:00
Evan Mattson 0ff97c7fe7 Python: add AzureAIAgent, OpenAIAssistant and OpenAIResponsesAgent Integration tests, AzureAIAgent FCC gen bug fix (#11394) 
### Motivation and Context

AzureAIAgents, OpenAIAssistantAgents, and OpenAIResponsesAgents
previously were not covered by integration tests. Adding a set of
integration tests to cover high-level usage of an AzureAIAgent and
OpenAIAssistantAgents for `get_response`, `invoke`, and `invoke_stream`.

As part of this work, a previous fix to typing caused a regression while
generating FunctionCallContent for an AzureAIAgent. Fixing to use the
correct instance check.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Adds integration tests for AzureAIAgent and OpenAIAssistantAgent.
- Fixes #11393
- Bump version to 1.27.2 for bug fix release.
- Remove unnecessary yield for function result content during streaming
invocation - these types will be added if the `on_intermediate_message`
callback is provided.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-07 10:46:59 +00:00
Evan Mattson ff498b4ca9 Python: Updates (#11371) 
### Motivation and Context

Some code cleanup. 

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

Some code cleanup. 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-04 13:32:26 +00:00
Tao Chen 94a78d15e2 Python: Add on_intermediate_message callback to the Agent abstraction (#11321) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Currently, our agents' `invoke` and `invoke_stream` have inconsistent
behavior where the responses may contain different contents. For
example, the chat completion agent (`invoke`) may return all content
types generated by the agent including function call/result contents
that are meant to be internal only, while the assistant agent doesn't
return those contents. This creates confusion both for users and
developers of SK of what an agent should return when working with
agents.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
This PR standardizes the behavior of agents by adding an
`on_intermediate_message ` parameter to the `invoke` and `invoke_stream`
methods in the `Agent` abstraction. This parameter accepts a callback
function that will be called whenever a new message is generated by the
agent, except the last one that gets returned to the caller. This allows
the caller to inspect what the agent did after a response is returned.
In addition, this PR also converges on the behavior of the `invoke` and
`invoke_stream` methods (respectively) to return the same content types
from all agents, making it easier for users to work with agents

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
 2025-04-03 22:30:10 +00:00
Evan Mattson 329a35edea Python: Introduce the OpenAI Responses Agent (#11240) 
### Motivation and Context

OpenAI recently released their Responses API, which is their newest core
API and an agentic API primitive, combining the simplicity of Chat
Completions with the ability to do more agentic tasks. Azure OpenAI also
recently released the Responses API, with close-to feature parity with
OpenAI's SDK. It gives us enough to introduce an `AzureResponsesAgent`
and an `OpenAIResponsesAgent` to Semantic Kernel.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

This PR introduces:
- The `AzureResponsesAgent` and `OpenAIResponsesAgent`
- Allows use of the web search tool with `OpenAI` (`Azure OpenAI`
currently doesn't support this).
- Allows use of the file search tool with both `OpenAI` and `Azure
OpenAI`.
- Provides getting started samples for both agent types.

**TODO:**
- Add unit test coverage for the `ResponsesAgentThreadActions` class.
- Add support for the computer user agent tool.
- Improve typing in the `ResponsesAgentThreadActions` class.
- Closes #11026

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-04-02 23:18:57 +00:00
Tao Chen 84f4841465 Python: Fix agent samples (#11278) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
This
[sample](https://github.com/microsoft/semantic-kernel/blob/main/python/samples/concepts/agents/chat_completion_agent/chat_completion_agent_function_termination.py)
was throwing an error due to duplicating tool messages in the chat
history.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
Fix a few agent samples.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-04-01 15:28:36 +00:00
Evan Mattson 5fc8381177 Python: Pass kernel args through to kernel invoke function call for AzureAIAgent and AssistantAgent (#11250) 
### Motivation and Context

In our AzureAIAgent and AssistantAgent thread actions, we're not passing
the supplied args from the caller through to kernel function call invoke
methods.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

This PR fixes that, and makes sure we pass kernel args all the way
through the process, so any function calls can leverage the args.
- Adds a concept sample for AzureAIAgent showing how to prompt with
different prompt templates.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
 2025-03-30 11:57:02 +00:00
Evan Mattson d7172a5ae4 Python: Common agent invocation API updates (#11224) 
### Motivation and Context

After this week's release of the common agent invocation API, there are
some things that we can do as further improvements.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

This PR includes updates for:
- Right now we force any agent invocation to provide some type of input,
whether a str, a CMC, or a list of str | CMC. At times, there could be a
reason, based on using an existing thread or just providing instructions
to the agent, that one doesn't need to provide a message to invoke the
agent. Updating to make messages optional. Updating the ABC contracts as
well.
- For `invoke_stream` calls on agents, there's no need to call
`thread.on_new_message` that contains a streaming chunks -- once we move
to support memory, this is where the "hook" will be. Removing this call.
- The `get_messages(...)` methods on the `AutoGenConversableAgentThread`
and the `ChatHistoryAgentThread` returned concrete `ChatHistory`
objects, whereas the `AssistantAgentThread` and `AzureAIAgentThread`
returned `AsyncIterable[ChatMessageContent]`. To align to a common API,
the `AutoGenConversableAgentThread` and `ChatHistoryAgentThread`'s
`get_messages(...)` methods were moved to return
`AsyncIterable[ChatMessageContent]`.
- Removing a public facing `output_messages` for streaming invoke, and
replacing it with a callback to get a chat history back of "full"
messages. Two samples are added in `samples/concepts/agents`:
  - `azure_ai_agent/azure_ai_agent_streaming_chat_history_callback.py`
  - `openai_assistant_streaming_chat_history_callback.py`
- Update the README for OpenAI Assistants to showcase new thread
abstraction.
- Include unit tests for chat history (`on_complete`) callback.

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
 2025-03-27 15:59:46 +00:00
Tao Chen ad5026fb12 Python: Update Agent invoke abstraction parameters (#11192) 
### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->
Now that our agents have a more aligned interface, we can move the
common interface parameters to the abstract class.

### Description

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
Move the messages and thread parameters to the abstract class `Agent`
for the `get_response`, `invoke`, and `invoke_stream` methods.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
 2025-03-25 23:16:34 +00:00
westeyBen ThomasEvan MattsonTao ChenBen ThomasMark WallaceEvan Mattson
 		17e63a782b Python/.NET: Add a common agent invoke api. (#11116) 
### Motivation and Context

Being able to different invoke agents using a common API is useful to
build higher level code on top of.

### Description

Adding a common Invoke method with a common Thread object.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [ ] The code builds clean without any errors or warnings
- [ ] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting

script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [ ] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄

---------

Co-authored-by: Ben Thomas <[email protected]>
Co-authored-by: Evan Mattson <[email protected]>
Co-authored-by: Tao Chen <[email protected]>
Co-authored-by: Ben Thomas <[email protected]>
Co-authored-by: Mark Wallace <[email protected]>
Co-authored-by: Evan Mattson <[email protected]>
 2025-03-24 23:29:06 +00:00