Share via

Foundry Agent Ai Search Filter are static per agent version?

Elvis Lau 55 Reputation points
2026-02-09T09:24:34.2866667+00:00

I am using prompt agent in Microsoft foundry, according to the sample code in https://learn.microsoft.com/en-us/azure/ai-foundry/agents/how-to/tools/ai-search?view=foundry&tabs=keys%2Cazurecli&pivots=csharp. It seems that the filter applied to the ai search index are sticked to the agent version, which means if I want to change the filter from something like "conversation_id eq '1'" to "conversation_id eq '2'", I have to create a new agent version.

Is this the intended design? If so, I suppose the application of this design (I mean the only solution) is to create a new agent for each conversation?

Or is there any other way to allow the agent use ai search with filter, but not changing the agent version? Since the agent is now shared among conversations in my application.

Thanks!

Azure OpenAI in Foundry Models

3 answers

Sort by: Most helpful
  1. Anonymous
    2026-02-09T09:50:58.56+00:00

    Hi Elvis Lau

    In Microsoft Azure AI Foundry, when you configure the Azure AI Search tool for a prompt‑based agent, the search filter is stored as part of the agent definition. Because the agent definition is versioned, any change to the filter—such as changing conversation_id eq '1' to conversation_id eq '2'—forces creation of a new agent version

    In Foundry, an agent is treated as a persisted, auditable orchestration artifact that includes model selection, tools, parameters, and governance controls. To guarantee reproducibility, governance, and traceability, tool parameters (including AI Search filters) are immutable per agent version. This ensures that a given agent version always behaves deterministically. [learn.microsoft.com]

    Foundry separates agent configuration from conversation state. The agent defines how reasoning and retrieval happen, while the conversation stores runtime state and history for each user/session. Because of this separation, conversation‑specific values (like a conversation ID) are not expected to be encoded in the agent’s AI Search filter. Instead, conversations are the unit that changes per user or per session. [learn.microsoft.com]

    If you need per‑conversation isolation, the recommended approach is to move that variability out of the agent definition. Common patterns include designing your Azure AI Search index so that documents are already scoped per tenant, user, or session, or using separate indexes per logical scope. The agent remains constant, while the data it retrieves is naturally constrained by index design rather than dynamic filters.

    AI Search filters are static per agent version by design. No, you should not create a new agent per conversation. Instead, share a single agent across conversations and handle per‑conversation scoping through conversation state or index architecture. Today, Foundry does not support passing dynamic AI Search filters at runtime without changing the agent version.- AI Foundry Agent Service FAQ

    Hope this helps. Do let us know if you any further queries.

    Thank you!

    Was this answer helpful?

    1 person found this answer helpful.

  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.


    Comments have been turned off. Learn more

  3. AI answer

    2026-02-09T09:24:46.01+00:00

    In Microsoft Foundry, the filters applied to the Azure AI Search index are indeed static per agent version. This means that if you want to change the filter criteria, such as from "conversation_id eq '1'" to "conversation_id eq '2'", you would need to create a new version of the agent. This design ensures that each version of the agent maintains its own configuration, including any filters applied to the search index.

    If your application requires the agent to handle different conversation IDs without creating a new version for each change, you might consider designing your application to create separate agents for each conversation or implement a mechanism to dynamically manage filters within the agent's logic, if possible. However, the standard approach as per the current design is to create a new agent version for each distinct filter requirement.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.