AgentPrismWorkflowFunctionExtensions

Namespace AgentPrism · Assembly AgentPrism.Workflows.dll

Extensions that register a code function as a workflow node.

public static class AgentPrismWorkflowFunctionExtensions

Inheritance

object ← AgentPrismWorkflowFunctionExtensions

Inherited Members

object.GetType(), object.MemberwiseClone(), object.ToString(), object.Equals(object?), object.Equals(object?, object?), object.ReferenceEquals(object?, object?), object.GetHashCode()

Methods

AddWorkflowFunction<TInput, TOutput>(IAgentPrismBuilder, string, Func<IServiceProvider, Func<TInput, IWorkflowContext, CancellationToken, ValueTask<TOutput>>>, string?)

Registers a function that a WorkflowKind.Sequential workflow can use as a node, mixed in with agents from the catalog.

public static IAgentPrismBuilder AddWorkflowFunction<TInput, TOutput>(this IAgentPrismBuilder builder, string name, Func<IServiceProvider, Func<TInput, IWorkflowContext, CancellationToken, ValueTask<TOutput>>> factory, string? description = null)

Parameters

builder IAgentPrismBuilder

The AgentPrism configuration chain.

name string

The function’s unique name. A WorkflowDefinition node of kind WorkflowNodeKind.Function points to it by this name.

factory Func<IServiceProvider, Func<TInput, IWorkflowContext, CancellationToken, ValueTask<TOutput>>>

Resolves the function’s dependencies from the service provider and returns the handler that runs on every call.

description string?

A short description shown in the function catalog.

Returns

IAgentPrismBuilder

The chain, for continued configuration.

Type Parameters

TInput

The type the function accepts.

TOutput

The type the function returns.

Remarks

Security boundary. A workflow definition can only point to a function registered here, by name. The function’s code is never written from the UI or the database - the same boundary AddTool draws for tools, and the same boundary AgentPrismWorkflowsBuilderExtensions.AddWorkflow draws for a free-form graph.

factory runs exactly once, when the function registry is first built - not once per workflow run. Resolve every dependency the handler needs inside factory; the handler itself receives no service provider at call time (IWorkflowContext does not carry one, the same constraint tools hit).

The handler must be thread-safe. Because factory runs once, every workflow compile - and therefore every concurrent run of this workflow, and every other workflow that references the same function name - shares the exact same handler closure. A handler that captures mutable state (a counter, a non-thread-safe client) must guard it itself.

Only WorkflowKind.Sequential supports function nodes. Microsoft Agent Framework’s ready-made builders for the other four patterns accept only agents; splicing a function into them would mean hand-writing their orchestration logic, which is out of scope.

The handler must be idempotent when the workflow enables checkpointing (the default). Measured: resuming from the run’s LATEST checkpoint after it has already completed does not call the handler again - the checkpoint already reflects the finished graph, so there is nothing left to run. But resuming from an earlier checkpoint - the shape a real crash recovery takes, naming a checkpoint written before this node’s own super-step - replays that super-step, and the handler runs again with the same input. A handler with a real side effect (a file write, an HTTP call, a database insert) must therefore tolerate being called more than once for the same logical step.

builder.AddAgentPrism()
       .UseWorkflows()
       .AddWorkflowFunction<string, string>(
           "normalise",
           provider => (input, context, cancellationToken) => ValueTask.FromResult(input.Trim().ToUpperInvariant()));

Exceptions

ArgumentNullException

One of the required parameters is null.

ArgumentException

name is empty.