Managing Available Kernel Functions

[AdamSobieski]

Hello. I would like to share some ideas and questions for discussion involving the runtime management of dynamic collections of available kernel plugins and functions.

In theory, invoked kernel functions could modify application state and, while doing so, add or remove kernel plugins and functions from the kernel.Plugins collection. In theory, available kernel plugins and functions could be dynamic at runtime.

For example, one could allow users to invoke kernel functions to move an agent around on a world map, through various rooms, where different kernel plugins and functions could be available to users for each different room.

Brainstorming, here is a list of implementation possibilities:

1. Kernel functions could access the current Kernel using a static property somewhere, e.g., Program.CurrentKernel:

[KernelFunction]
[Description("Move the agent in a direction.")]
public string MoveAgent_1(string direction)
{
    // as the agent exits and enters rooms, could modify the Program.CurrentKernel.Plugins collection.
}

2. The current Kernel could be passed to kernel functions as a special attributed first argument:

[KernelFunction]
[Description("Move the agent in a direction.")]
public string MoveAgent_2(Kernel kernel, string direction)
{
    // as the agent exits and enters rooms, could modify kernel.Plugins collection.
}

3. A developer-provided state object could be passed to kernel functions.

[KernelFunction]
[Description("Move the agent in a direction.")]
public string MoveAgent_3(Kernel kernel, [FromKernelServices] IState state, string direction)
{
    // as the agent exits and enters rooms, could modify kernel.Plugins collection.
}

4. A developer-provided finite-state machine could be passed to kernel functions. Such state machines could utilize Boolean functions upon the other input arguments and/or upon the most recent ChatMessageContent in the contextual ChatHistory (or a shallow copy of it) to determine when to perform transitions between states. These Boolean functions for the transitions of state machines could make use of AI when processing such input arguments and content. As envisioned, both exiting and entering nodes, or states, could modify kernels' Plugins collections.

[KernelFunction]
[Description("Move the agent in a direction.")]
public string MoveAgent_4(Kernel kernel, [FromKernelServices] IStateMachine machine, string direction)
{
    IState state = machine.Current;
    // as the agent exits and enters rooms, could modify kernel.Plugins collection.
}

5. Other.

Update: Some quick experiments with version 1.41.0 showed that while kernel.Plugins, of type KernelPluginCollection, supports Add() and Remove() methods, involved AI chat-completion services appear to want to invoke removed plugins' functions after they are removed. Built kernels still forward information about later removed plugins to AI systems. So, while the kernel.Plugins collection is mutable at runtime, and is not read-only, updating this collection doesn't update built kernels as previously considered.

What do you think about runtime-dynamic kernel plugins and functions? What do you think about available kernel plugins and functions varying depending upon applications' or agents' states?

Are there any other approaches to manage dynamic collections of kernel plugins and functions?

Thank you.

[sophialagerkranspandey]

Thanks for the feedback. We've seen a number of customers build a vector store of plugins for this scenario. We are looking in the future to potentially create a sample to create.