Connect retrieval pipelines directly to workflows and agent tools

An index is not yet a capability. Connecting it means choosing how an agent reaches it — the Azure AI Search tool, File Search over vector stores, or a knowledge base — and then handling the two problems that only appear once retrieval is inside an agent: per-tenant isolation and per-user permissions.

Why This Matters

Structured inputs make one agent serve many tenants. file_search.vector_store_ids is overridable per request, so a single agent definition can be pointed at each caller's own content.

Permissions are a source-type decision. Remote SharePoint inherits permissions, with a security filter fallback — the alternative is rebuilding an access model inside the index.

Foundry IQ is the packaging. It is "the managed knowledge layer that transforms enterprise content into reusable, permission-aware knowledge bases for agents".

Prerequisites

• Hybrid search, the semantic ranker, and agentic retrieval.
• Structured inputs and the three runtime overrides.
• Knowledge bases with indexed and remote sources.
• Tool schemas as the model's selection channel.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose among File Search, the Azure AI Search tool, and a knowledge base.
2. Use structured inputs for per-tenant isolation, and authorise them.
3. Meet per-user permission requirements without rebuilding an access model.
4. Attach retrieval to workflows and expose pipelines as reusable units.
5. Evaluate a retrieval-backed agent.

Building Blocks

The three attachment points.

Structured inputs. Runtime overrides taking precedence over stored configuration: file_search.vector_store_ids, code_interpreter.container, and mcp.server_label / server_url / headers.

Indexed against remote sources. Indexed — content ingested into an index. Remote — bypasses indexing, queried live; remote SharePoint inherits permissions, with a security filter fallback.

Agentic retrieval. Plans, decomposes into subqueries, retrieves in parallel, semantically reranks, and merges, returning an activity log and references. It has region restrictions.

Foundry IQ. "The managed knowledge layer that transforms enterprise content into reusable, permission-aware knowledge bases for agents in the Microsoft Foundry portal."

Workflow composition. Agents in workflows — agents as participants. Workflows as agents — a whole workflow exposed as a single callable agent. Declarative workflows express structure as configuration.

Evaluation. Retrieval (no ground truth needed), Groundedness / Groundedness Pro, and the agent family — Tool Selection, Tool Input Accuracy, Tool Output Utilization, Tool Call Success.

Deep Dive

Choosing the attachment point

The three routes differ in where the content already lives.

File Search grounds on documents you upload into vector stores. It suits content the agent owns — a curated set of policies, a product manual, per-customer documents — and its distinctive property is that the store is nameable per request.

The Azure AI Search tool queries an index you already maintain, bringing hybrid search, the semantic ranker, and where configured agentic retrieval. This is the right route when a search estate already exists: the agent becomes another consumer of it rather than a second copy of the corpus.

A knowledge base packages knowledge sources with an optional LLM and parameters, and its source types carry the important distinction. Indexed sources are ingested and searched; remote sources bypass indexing and are queried live, which removes staleness and shifts availability onto the source.

The instinct to carry: do not re-ingest a corpus that is already indexed. A second copy means two ingestion pipelines, two chunking strategies, and two things to keep current — the Azure AI Search tool exists precisely to avoid that.

Multi-tenancy without agent sprawl

The obvious response to per-customer content is an agent per customer. Structured inputs exist so that is unnecessary.

Because file_search.vector_store_ids is supplied at request time and takes precedence over the agent's stored configuration, one agent definition — one set of instructions, one tool list, one version history — serves tenant A's documents on one call and tenant B's on the next.

The operational payoff is substantial: one definition to update, one version history to audit, one evaluation baseline. The governance obligation is equally real and easy to miss: the platform honours whatever store it is given, so your application must enforce that a caller can only name their own. That check does not live in the agent, and its absence is a cross-tenant data exposure rather than a bug in retrieval quality.

The same mechanism handles environments cleanly — identical agent, different mcp.server_url per environment — avoiding duplicated definitions that drift apart.

Permissions, and the source type that solves them

Per-user permission trimming is where retrieval-backed agents most often go wrong, because the naive approach is expensive and fragile.

Reproducing permissions in the index means mirroring an access model — groups, inheritance, exceptions — into index fields and filtering on them at query time. It works, and it must be kept synchronised with the source forever.

A remote source avoids it. Remote sources bypass indexing and are queried live, and remote SharePoint inherits permissions, with a security filter fallback. Users see only what they may see because the source enforces it, not because the index reproduced it.

This is the same instinct as OAuth on-behalf-of passthrough for tools, where the call runs as the signed-in user so the downstream system applies that user's permissions. Both answer "the backing system already enforces access — don't rebuild it."

Foundry IQ names this property directly: "reusable, permission-aware knowledge bases for agents".

The trade to acknowledge: remote sources depend on the source's availability and latency at query time, and forgo the index's uniform retrieval features.

Composing into workflows

Retrieval rarely stands alone in a larger system.

Agents in workflows puts a retrieval-backed agent inside a structured flow — the common case where a deterministic pipeline needs grounded judgement at a few points.

Workflows as agents exposes an entire retrieval-and-reasoning pipeline as a single callable agent, so an outer orchestration invokes it like any participant without knowing its internals. That is the answer whenever an existing pipeline must be reused inside something larger; rebuilding its steps as separate participants duplicates logic and loses encapsulation.

Declarative workflows express the structure as configuration, which suits flows that must be reviewed or version-controlled.

And evaluation spans both halves. The retrieval side is measured by Retrieval and Groundedness — or Groundedness Pro where no judge deployment is permitted. The agent side is measured by Tool Selection (did it choose this source?), Tool Input Accuracy (was the query well-formed?), and Tool Output Utilization (did it use what came back?). A retrieval-backed agent that answers from parametric knowledge despite good retrieval is failing the last of those, and only per-link measurement distinguishes it from a retrieval failure.

Worked Examples

Example 1 — an existing search estate. An organisation already runs an Azure AI Search index over its knowledge base and wants an agent to answer from it.

The Azure AI Search tool, so the agent consumes the existing index with its hybrid search and semantic ranker. Re-ingesting the corpus into File Search vector stores would create a second copy with its own chunking, its own freshness problem, and two pipelines to maintain.

Example 2 — per-customer documents, one agent. A SaaS product must ground answers in each customer's own documents without an agent per customer.

Structured inputs: supply file_search.vector_store_ids per request, pointing at the calling tenant's store. One definition, one version history, one evaluation baseline. Your application must authorise the store id — the platform honours what it is given, and an unchecked identifier is a cross-tenant exposure.

Example 3 — permission-trimmed answers. An assistant must answer from SharePoint, and each user must see only documents they may see.

A remote knowledge source over SharePoint, which bypasses indexing, is queried live, and inherits permissions with a security filter fallback. Indexing the content would require reproducing the permission model in the index and keeping it synchronised — the problem this source type exists to avoid, and what Foundry IQ means by permission-aware knowledge bases.

Visual Explanations

Choosing the attachment point:

Two halves to evaluate:

Common Mistakes

Re-ingesting a corpus that is already indexed. Use the Azure AI Search tool.

Creating an agent per tenant. Structured inputs parameterise one definition.

Trusting a caller-supplied store id. The platform honours it; your application must authorise it.

Reproducing a permission model in the index. Remote SharePoint inherits permissions.

Writing a vague tool description. Selection happens from that text.

Ignoring agentic retrieval's region restrictions.

Rebuilding a pipeline's steps instead of exposing it with workflows as agents.

Measuring only retrieval. Tool Output Utilization catches the agent ignoring good results.

Forgetting remote sources depend on the source's availability.

Practice Exercises

1. Give the three attachment points and the deciding question.
2. How does one agent serve many tenants, and what must your application do?
3. Which source type solves per-user permissions, and what is the trade?
4. Which composition reuses an entire retrieval pipeline?
5. Retrieval scores well but answers ignore the results. Which evaluator, and what does it mean?

Summary & Concept Map

Connecting retrieval to an agent starts from where the content already lives: an existing index calls for the Azure AI Search tool, agent-owned documents for File Search over vector stores, and a live permission-bearing source for a remote knowledge source. Structured inputs — specifically file_search.vector_store_ids per request — let one agent definition serve many tenants, provided your application authorises the store id, since the platform honours whatever it is given. Per-user permissions are solved by source type rather than by index engineering: remote SharePoint inherits permissions, the same instinct as OAuth on-behalf-of, and what Foundry IQ packages as permission-aware knowledge bases. Compose with agents in workflows and workflows as agents for reuse, write tool descriptions that say when to use each source, and evaluate both halves — Retrieval and Groundedness for the pipeline, Tool Selection, Input Accuracy, and Output Utilization for the agent.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.