镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

.NET: Azure AI Projects agent-mode silently ignores per-request tools (AG-UI/ChatOptions.Tools) #2959

Closed as not planned

Description

Summary

When using [AIProjectClient.CreateAIAgentAsync(...)]. During runs, tools provided per request (e.g., via AG-UI frontend tool definitions) are silently dropped and never reach the model/service request. This makes AG-UI “frontend tools” unusable with Azure AI Projects agents unless they were baked into the server-side agent definition at creation/version time.

Why this matters

AG-UI expects to be able to provide tool definitions per request (especially client-side / frontend tools).
Today this fails silently: the agent runs, but never calls/uses the provided tools because the model never sees them.
The silent ignore is hard to diagnose and looks like “tools don’t work”.

The per-request tools never show up in the model request context, so the agent never calls them.
No error/warning is produced.
Expected behavior (pick one)
Option A (strict): If per-request tools are supplied in agent-mode, explaining they are not supported and that tools must be added to the server-side agent definition/version.
Option B (support): Allow per-request tool augmentation (union) so AG-UI frontend tools work with agent-mode.

Root cause / code pointers

The Azure AI Projects agent-mode client intentionally clears non-overridable options in GetAgentEnabledChatOptions.

Activity

  1. added
    .NETUsage: [Issues, PRs], Target: .Net
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Dec 18, 2025
  2. changed the title [-]Azure AI Projects agent-mode silently ignores per-request tools (AG-UI/ChatOptions.Tools)[/-] [+].NET: Azure AI Projects agent-mode silently ignores per-request tools (AG-UI/ChatOptions.Tools)[/+] on Dec 18, 2025
  3. added and removed
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Jan 5, 2026
  4. MaciejSzczepanskiRedslim commented on Jan 21, 2026

    @MaciejSzczepanskiRedslim
    Author

    I've just noticed this PR #3285 - so it sounds like if you want to use AG-UI + frontend tools, then don't use foundry agents.... Mark Wallace (@markwallace-microsoft) ?

  5. simonscoffins commented on Feb 2, 2026

    @simonscoffins

    Maciek (@MaciejSzczepanskiRedslim) This is something I have been struggling with that I thought would be carried over from the "Classic Foundry" to the "New Foundry" (NF).

    Right now in NF I can create an agent to user the code interpreter tool but I cannot upload a file for a specific conversation other than a pdf for the agent to analyze (tested). So if I want to create a UI for an agent to analyze a file csv on a request basis I have to convert the csv file to pdf first...

    Loading a csv at agent creation time makes the data available to all calls to the agent. This is probably going to stop us moving forward using Foundry Agents at this moment.

    Or am I missing something fundamental? More than happy to be corrected and pointed in the right direction.

    Does anyone have an alternative approach to Agent + UI + File Upload + Tool request?

  6. javiercn commented on Aug 18, 2026

    @javiercn
    Contributor

    I checked the current Foundry Agent Service documentation, and this limitation has not been lifted.

    A service-managed FoundryAgent uses the model, instructions, and tools stored in its Foundry agent definition. Per-run tools, tool_choice, and parallel_tool_calls are removed from the request because the client cannot add model-visible tools dynamically.

    For AG-UI frontend tools, the supported approach is therefore to preregister the corresponding function definitions—using matching names and schemas—on the Foundry agent definition/version. AG-UI can then surface calls to those functions for execution by the frontend.

    If the available tools must change dynamically per request, use an application-owned FoundryChatClient instead of a service-managed Foundry agent. The current documentation explicitly recommends that model when runtime tool selection is required:

    https://learn.microsoft.com/agent-framework/integrations/by-component/agent-services/foundry#connect-to-a-prompt-agent

    Supporting dynamic tools on service-managed agents would require a Foundry Agent Service capability. Please raise that scenario through the Foundry Agent Service or Azure SDK feedback channels.

    Since Agent Framework cannot forward per-request tools where the underlying service-managed agent contract does not support them, I’m closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

.NETUsage: [Issues, PRs], Target: .Netag-uiUsage: [Issues, PRs], Target: AG-UI protocol integration

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions