Generated banner for Foundry Iq
Generated logo for Foundry Iq

Foundry Iq

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Data and AI
  • MIT
  • Medium risk
  • Has scripts

From the author

Foundry IQ knowledge bases. WHEN: make local or Blob documents searchable; create/diagnose KBs; triage unsupported connectors or multi-source KB creation/reconfiguration (even with classic-search terms); connect existing KB to agents (including multi-source KBs); create/reuse a Search service; retrieve from an existing knowledge base with citations; no brand words needed. Read its procedure before query/target questions. NOT: other KB providers, repository-file search, classic Azure AI Search index/query/app work with no Foundry IQ KB or connector request, generic agent creation.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Foundry IQ provides a structured framework for creating, diagnosing, and connecting knowledge bases to AI agents. It supports making local or Blob-based documents searchable, managing multi-source knowledge configurations, and retrieving information with citations. The skill emphasizes strict adherence to defined procedures for service discovery, resource creation, and troubleshooting to ensure reliable agent-knowledge integration.

What it does

  • Creates searchable knowledge bases from local or Azure Blob storage documents.
  • Connects existing knowledge bases to AI agents.
  • Diagnoses issues with knowledge base configurations or unsupported connectors.
  • Retrieves information from knowledge bases with source citations.
  • Manages the lifecycle of search services and knowledge sources.
  • Routes requests based on specific operational needs rather than source counts.

When to use it

  • When you need to make local or cloud-stored documents searchable by an AI agent.
  • When connecting an existing knowledge base to a new or current agent.
  • When troubleshooting or diagnosing a knowledge base configuration.
  • When you need to create a new search service or knowledge source.
  • When performing retrieval tasks that require citations from a knowledge base.

Advantages

  • Provides a clear, procedural approach to knowledge base management.
  • Ensures consistent handling of multi-source knowledge configurations.
  • Includes built-in diagnostic paths for troubleshooting.
  • Supports secure, citation-backed retrieval for agent responses.
  • Prevents unauthorized or unsupported configuration changes.

Usage examples

“Create a new knowledge base from my Azure Blob container.”
The agent will initiate the knowledge base creation procedure, validating the source and setting up the necessary search indexing.
“Connect my existing knowledge base to the current agent.”
The agent will follow the connection workflow to link the specified knowledge base to the agent's retrieval pipeline.
“Why is my multi-source knowledge base failing to index?”
The agent will trigger the diagnostic procedure to identify configuration drifts or unsupported connector issues.
“Retrieve information about project timelines from the knowledge base.”
The agent will query the knowledge base and provide an answer with citations from the source documents.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/foundry-iq/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip foundry-iq.zip -d .agents/skills

Documentation by Microsoft

Foundry IQ

Read one procedure before questions/actions; invocation is not a read. Read the owning procedure before blocked/unsupported responses too. Before mutation plans/approval, successfully read its required pre-action references, selected branches only. Do not reload successful reads. On failure, try only permitted bounded exact-path reads with any supported reader; never bypass restrictions or search broadly. If still unavailable: blocked: reference-unavailable, name missing references and inability to plan. Never invent requirements/plans. Failures first.

Cleanup and receipt-backed execution go directly to their lifecycle/producer owner; do not reopen Search intake, provisioning or hardening.

Before expensive service discovery, reuse supplied resource/intent; otherwise ask one early USE EXISTING / FIND CANDIDATES / CREATE NEW choice. Only FIND enumerates; supplied identity uses exact/minimum scoped resolution. CREATE checks its proposed name, not existing-service inventories. Preserve these answers across source/KB/CU/model handoffs; selection is not write approval.

Searchable docs: KB + validated retrieval. Confirm intent once; KS-only must be explicit. Child success is not KB completion. Unclear/compound/mode/completion: read.

Route by requested operation, not existing KB source count. Connecting an existing KB with two or more sources, without changing the KB, uses Connect. Read-only operations use their owning procedure and actual helper constraints; this does not add retrieval modes or supported source kinds. Explicit unsupported provisioning or multi-source KB creation/reconfiguration uses Diagnose and stops before discovery, even when connecting an agent is also requested. This routing takes precedence over classic-search terms (e.g. hybrid search) in compound requests. Never end in a plain refusal: Diagnose gives the boundary, docs pointer and agent handoff; writes still need an approved concrete plan. Do not silently execute only the supported part of a compound request. If existing-KB connection versus KB creation/reconfiguration is unclear, read intent-routing and clarify that scope before Azure discovery. Never infer KB mutation.

OutcomeRead
CleanupPlan cleanup
Failure/driftDiagnose
Unsupported connector provisioning / multi-source KB creation or reconfigurationDiagnose
ConnectConnect
Read KBQuery
Search onlySearch
File KS onlyFile
Blob/ADLS KS onlyBlob
Searchable/KBKB

Generic agents: microsoft-foundry. Reads: no approval; approve unchanged plans before writes. Hide hashes. No Search/Storage keys, scope widening, guessed identity/boundaries, drift repair or joint cleanup/creation approval. Acceptance != success.

Files

references/intent-routing.md

Intent, handoffs and completion examples

Read for ambiguous/compound goals, unresolved search-mode choices, or uncertainty about completion. These examples guide interpretation, not keyword-first matching.

Intent and completion

Route by the user's end result, not the first connector/resource keyword. Within Foundry IQ, "make these documents searchable" or "ask questions over these documents" means a usable KB with validated retrieval. Default to Create KB, not a source-only operation. Words such as files, Blob, index or embeddings identify prerequisites; they do not downscope a broader goal.

Confirm the intended finish once in normal intake, in user terms: "I'll make these documents searchable through a knowledge base and check retrieval against them. Do you want that full outcome, or only the knowledge source?" Do not re-ask an already explicit or confirmed goal. Use source-only only when the user explicitly requests or confirms that narrower outcome; never infer it from an intermediate step. Goal confirmation is not approval for Azure writes.

Retain the confirmed goal, selected data, explicit exclusions and remaining steps across handoffs. A child's completed result is not overall completion. For a KB goal, resume the KB owner after Search/model/source prerequisites with returned IDs and fresh source/readiness evidence. Present and approve the concrete KB plan, create/reuse and read back the KB, then run supported-question and unrelated-question retrieval checks under the selected API/output mode. Require source-backed results and original-source citations; source ingestion, KB existence or HTTP success alone is not validated retrieval.

Finish only when every requested outcome is verified. Otherwise report completed prerequisites, the blocker and remaining steps; never mark the whole goal complete or silently downgrade it to KS-only. Resume after an approved prerequisite rather than asking the user to restart. Never preapprove an unknown KB mutation. Explicit source-only, infrastructure-only and read-only requests remain bounded; never create an unrequested KB/agent. Explicit classic Search work still routes out.

Search-mode choice

For new unresolved search-mode intent, recommend/preselect Hybrid (keyword + vector), with Keyword-only (disable vectors) as the explicit opt-out. This recommendation is not consent or a helper default. Honor existing/informed keyword-only choices and exact reuse unchanged: do not re-ask settled choices, silently retrofit vectors or choose/deploy a model. An explicit change to an existing source needs a separate supported plan/approval; read-only retrieval never changes its source.

Ask in the grouped intake: "I recommend Hybrid (keyword + vector) for keyword precision plus semantic/paraphrase matching. Would you like Hybrid, or Keyword-only without vectors?" Where selectable defaults are supported, preselect Hybrid, but require an explicit customer choice; silence or an unanswered field is not consent. Reuse supplied informed choices and group compatible unresolved decisions rather than adding separate confirmations for each disclosure.

Before plan approval explain:

ChoiceBenefit and tradeoff
Hybrid (recommended)Combines keyword precision with semantic/paraphrase matching, including related wording without exact terms. Adds embedding charges, ingestion/query embedding processing where applicable, vector storage/capacity, and content processing/data movement to the selected embedding service. Disclose selected model, region, auth/network and applicable cost/data boundaries; no guaranteed relevance improvement.
Keyword-only (opt-out)Keeps keyword matching without source vectors or their embedding charges/processing/storage. May miss paraphrases with little term overlap. Search, extraction and independently requested chat/CU can still cost money; this is not a free or model-free promise.

Keyword-only: no embedding discovery. Discover only missing dependencies for the confirmed hybrid choice, using the bounded scoped helper; select an account before listing its deployments. Known compatible model choices need exact readback, not rediscovery. Never auto-select a deployment, deploy models, call models or upload content during intake. Missing/unavailable hybrid dependencies require supported scoped discovery, concretely approved setup, or explicit customer keyword-only opt-out; no silent keyword fallback. Report readback/access/capacity uncertainty precisely; metadata is candidate evidence, not effective readiness. Model-free minimal+extractive routes do zero model/CU discovery; keyword-only does not suppress independently required chat/CU discovery.

Retrieval keyword+vector is independent of text-only versus multimodal extraction. Neither search choice selects CU, KB reasoning/synthesis or semantic reranker automatically. A text-only PDF can use hybrid; multimodal content can use keyword-only. Assess extraction/answer dependence separately without defaulting Minimal or selecting Standard merely because an image/table exists.

Keep helper inputs explicit: File vectorization: none versus azureOpenAI; Blob minimal-lexical versus minimal-vector, or standard-cu with independently selected optional embeddings. File/Blob JSON examples are explicit keyword-only choices, not UX defaults. Omitted/null embeddings never become vectors; a selected vector mode with missing model choices blocks, not downgrades. Preserve separate sample-content consent and actual resource/permission/CU/source/KB approvals; do not approve unknown future bodies. Approved source creation/ingestion is not validated hybrid retrieval; use the existing vector/hybrid verification contract with explicit query approval, not a billable intake probe.

Scenario examples

Read the whole request; broader goals and explicit limits take precedence over a mentioned child step.

User requestStartRequired finish
Make these local documents searchable.Create KBConfirm KB outcome; File prerequisite, valid KB and validated retrieval.
Make this Blob container searchable.Create KBConfirm KB outcome; Blob prerequisite, valid KB and validated retrieval.
Create a Blob knowledge source, then a knowledge base and test it.Create KBBoth resources and validated retrieval; do not stop at the KS.
Use my existing Search service to make these files searchable.Create KBReuse Search; finish the KB and retrieval, not just infrastructure.
Create only a Blob knowledge source; no KB.Blob familyVerified source only; no KB or agent creation.
Set up only a Search service.SearchVerified service only; no source or KB creation.
Query this existing KB.RetrieveRead-only source-backed retrieval; no creation.
Connect this KB to my existing Foundry agent.ConnectVerified requested connection and agent retrieval; configuration alone is insufficient.
Make OneLake and Blob searchable together.DiagnoseState unsupported scope, point to documentation, and hand off to agent to take direct action; never substitute a Blob-only success.
Build a classic Search index and query it from my app.Outside this skillClassic Search handoff; do not invent a KB requirement.

References

Authorities: failure/conflict/uncertainty only.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

The author says: Azure

Security

What our scanner noticed· Medium risk

  • References to credential files
  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/foundry-iq-skills/skills/foundry-iq · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/foundry-iq-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download foundry-iq.zip