* [BREAKING] refactor: Normalize WorkflowBuilder APIs
* "partitioner" => "assigner"
* normalize ordering so sources always to the left of targets for edges
* normalize parameter ordering so sources and targets are always first arguments
* remove `params` (users should use collection expressions instead)
* refactor: Align name with Python
* Updates to async run loop.
* fix: Workflow Onwership can be release by nonowner
* fix: Incorrect handling of blockOnPending in StreamingRun
Depending on whether we are running in streaming on non-streaming mode, we may be using the StreamingRun in different ways. Unfortunately, the only place we can really know what is the actual state of execution is in the RunEventStream implementations.
This resulted in blocking where blocking was unneeded and occasionally not-blocking when blocking was needed.
The fix is to move the logic of handling this blocking into RunEventStream implementations.
* fix: Fix cleanup on error and end run
This ensures we clean up the background resources correctly.
* fix: Ensure we let the run loop proceed when shutting down
* fix: Add timeout for Input Waiting
* fix: Make the samples properly clean up `Run`s and `StreamingRun`s
* fix: Simplify Declarative Workflow Run disposal pattern
* Also fixes missing .Disposal() in Integration tests
---------
Co-authored-by: Ben Thomas <ben.thomas@microsoft.com>
* Re-enable ImplicitUsings in samples and clean up NoWarns
* Fix dotnet format
* More dotnet format
* More dotnet format
---------
Co-authored-by: Chris <66376200+crickman@users.noreply.github.com>
* feat: Make Executor id field mandatory
When checkpointing is involved, it is critical to keep executor ids consistent between runs, even when recreating a new object tree for the workflow.
The default id-setting mechanism generated a guid for part of the id, making it not work when restoring from a checkpoint.
This change prevents this situation from arising.
* feat: Enable running untyped Workflows
With the change to enable delay-instantiation of executors and support for async Executor factory methods, we must instantiate the starting executor to know what are the valid input types for the workflow.
To avoid forcing instantiation every time, and to better support workflows with multiple input types, we enable support for build and interacting with the base Workflow type without type annotations, and remove the requirement to know a valid input type when initiating a run.
* feat: Support Output from any executor and multiple outputs.
* Add AgentWorkflowBuilder group chat
And fix a variety of issues along the way:
- Use DateTime{Offset}.UtcNow rather than Now
- AIAgentHostExecutor shouldn't be publishing empty messages
- Sequential workflows should be flowing all history and not just the output from the previous agent as the input into the next agent
- Renamed some of the new agent workflow methods... still not super happy with the shape, though
- Simplified handoffs builder, e.g. using a hashset with a custom comparer instead of a dictionary
- Improved multi-service use by trying to change assistant->user role for messages created by other agents
- Changed MessageMerger to rely on M.E.AI's coalescing more and to avoid empty contents / text
- Ensured that messages from ChatClientAgent include MessageId and CreatedAt timestamps
- Avoided including instructions for agents in a handoff workflow that don't have any handoffs
- Removed the unnecessary end function in handoffs
- Improved naming of executors to include agent name for debuggability
- Use "N" formatting with Guid.ToString everywhere, to avoid the unnecessary extra dash character which is also not valid in various places (like function tool names)
- Replace `params T[]` with `params IEnumerable<T>` to make public APIs more flexible in what they consume
* Address feedback
- Fix unintentional provider change in sample
Jacob Alber