microsoft / microsoft/agent-framework

.NET: [Feature]: first-class request/interaction context for dynamic model and tool policy

Open
#7,852 2 comments 0 reactions 1 assignee Claimed by @sphenry View on GitHub
.NET
Dominant language
Python
Stars
13.6k
Forks
2.3k
Avg merge
2d 45m
Merged PRs (30d)
358

Description

# Proposal: provide a unified dynamic configuration entry point for interaction-scoped agent runs

## Summary

I would like to propose that Microsoft Agent Framework provide a more unified dynamic configuration entry point for `AIAgent` runs, similar in spirit to Mastra's `RequestContext`.

MAF already has useful lower-level pieces: `AgentRunOptions`, `ChatClientAgentRunOptions.ChatOptions`, `ChatClientAgentRunOptions.ChatClientFactory`, `AIContextProvider`, `AgentRunContext`, and `AdditionalProperties`. However, for interactive applications, dynamic behavior currently feels scattered across several extension points.

## Problem

Many app-facing agents need to decide run behavior from the current interaction:

- Which model should handle this request?
- Which tools should be available?
- Which tools require approval?
- Which memory, workspace, tenant, user, locale, or UI mode applies?
- Which instructions or default options should be used for this turn?

Today this can be implemented, but the path is not obvious. Developers may need to combine custom `AgentRunOptions`, `AdditionalProperties`, `AIContextProvider`, `ChatOptions.Tools`, and `ChatClientFactory`. This makes dynamic policy possible, but not first-class or easy to standardize.

## Reference: Mastra RequestContext

Mastra uses `RequestContext` as a common input to dynamic agent configuration. In Mastra, request context can flow into dynamic instructions, default options, model resolution, tool resolution, workspace/memory selection, processors, scorers, and UI/playground run options.

The important idea is not the exact API, but the shape:

```ts
agent.stream(messages, {
requestContext,
});
```

Then agent configuration can resolve from the same request-scoped object:

```ts
model: ({ requestContext }) => ...
tools: ({ requestContext }) => ...
instructions: ({ requestContext }) => ...
defaultOptions: ({ requestContext }) => ...
```

## Proposal

Could MAF expose an official, unified request-scoped configuration model?

For example, conceptually:

```csharp
await agent.RunStreamingAsync(
messages,
session,
new AgentRunOptions
{
RequestContext = requestContext
},
cancellationToken);
```

And allow the main dynamic policies to resolve from that same context:

```csharp
options.ModelSelector = context => ...;
options.ToolSelector = context => ...;
options.ToolApprovalPolicy = context => ...;
options.Instructions = context => ...;
options.DefaultChatOptions = context => ...;
```

The exact API may be different. The main request is to avoid each application inventing its own convention using `AdditionalProperties` or custom run options.

## Lifecycle question

If this becomes too complex, is the preferred model instead to recreate a lightweight `AIAgent` per request with the desired model, tools, and options?

That may be simpler in some applications, but it raises lifecycle questions around sessions, provider state, tool approval state, telemetry, and chat history. It would be helpful to have guidance from the framework designers:

- Should MAF prefer stable agents with dynamic request-scoped resolution?
- Should per-request agent construction be considered cheap and idiomatic?
- Or should both patterns be supported, with clear guidance on when to use each?

I think a unified dynamic configuration entry point would make MAF much easier to use for interactive agent products, while still preserving the current stable-agent model for configuration-driven agents.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.