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://mp-staging.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

helpers/search-intake-contracts.md

Reuse-first Search intake

Use before service enumeration/provisioning, not for existing KB retrieval or agent connection (their owners keep their actual read-only checks). No supplied service/intent: ask USE EXISTING / FIND CANDIDATES / CREATE NEW once before expensive discovery. Supplied IDs/names/endpoints imply USE EXISTING unless creation was explicit. Carry resolved intent and selections through File/Blob/KB/CU/model handoffs; never reopen informed answers. A supplied candidate completes FIND as USE EXISTING, without another inventory.

This checker is Search-only. For CU/model dependencies use purpose-specific discovery: CU uses AIServices; embedding/chat use OpenAI or AIServices (Foundry). Carry separate selections; USE/FIND/CREATE is workflow state, not a model-helper input field. Call model discovery for supplied selectors or FIND; CREATE goes to its native owner, never an empty selector. No generic AI-host bootstrap/quota/RBAC automation. CU, vectors and KB own API, auth/MI, RBAC, network and actual processing checks. File Standard defaults to system MI (v1.2), implemented but not live-verified. Explicit legacy ARM-key v1.1 and ENV-key v1.0 remain; no fallback. File auth checks exact CU/role/identity/network. Blob CU uses Search system MI; neither mode selects embeddings or KB chat.

Native helper

python helpers/search_intake.py --select intake.json

Closed UTF-8 input; only schema_version is required:

{"schema_version":"1.0","intent":null,"service":null,"subscription_id":null,
"resource_group":null,"source_region":null,"page":0,"operation":null}

intent: null, use-existing, find-candidates, create-new. service: exact Search ARM ID, service name or clean HTTPS Search root. Names: 2-60 lowercase ASCII letters/digits/dashes; first, second and last characters alphanumeric, no consecutive dashes. Thus ab-c is valid, a-b is not. Full ARM IDs are matched case-insensitively, then their service names validated. GUID subscription; group names follow ARM rules. IDs supply scope; conflicts block. source_region: observed source region, only a latency/data-movement preference, never inferred from names or used as compatibility proof. No default location or subscription scanning. Explicit subscription wins; otherwise az account show supplies the stated default. No context switch.

IntentReads/result
Missingintent-required, three choices; zero CLI/auth calls
USE EXISTING without locatorservice-required; ask for locator, no inventory
Supplied ID or name+groupExact ARM GET only, plus selected account context
Name/endpoint without groupOne az resource list --name <name> --resource-type Microsoft.Search/searchServices --subscription <sub>, then exact GET if unique
FIND CANDIDATESKnown group: az search service list --resource-group <group> --subscription <sub>; otherwise type-filtered az resource list in selected subscription
CREATE NEWRequire name/group, exact collision GET; creation-plan-required only on exact ResourceNotFound. No service inventory or implicit reuse

Lists use --query "[].{id:id,name:name,location:location}"; native CLI consumes pages in that scope. Keep the complete bounded inventory internally; return at most five rows, total/remaining/unassessed counts and next_page. page is zero-based, below 40; each page refreshes the scoped inventory. All candidates remain unassessed, not recommended or unique from a top-five view. Same observed source region first; retain cross-region rows. Explicit choice wins. Use the row's selection_input for exact readback, not another list. No model calls, cross-subscription fanout, arbitrary URL fetches or writes. More than 200 rows, duplicates, scope escape, malformed/denied reads block without partial choices or absence claims. Shared native reader: 20s/command, 120s total, one MiB post-capture limit, not a hard capture-memory bound.

Operation-specific reuse

Initially operation: null selects ARM metadata, not compatibility/readiness. Once the actual mode is chosen, rerun the same selected ID with one operation:

{"kind":"file-source","api_version":"2026-08-01-preview","extraction_mode":"minimal","vectorization":"none"}

Closed variants:

kindOther required fields
serviceapi_version
file-source / blob-sourceapi_version, extraction_mode: minimal/standard, vectorization: none/azureOpenAI
knowledge-baseapi_version, reasoning_effort: minimal/low/medium, output_mode: extractiveData/answerSynthesis

APIs: 2026-04-01 or 2026-08-01-preview; File, Standard extraction and nonminimal/synthesis KB require preview. Downstream source/KB validators retain their additional API, source-kind, tier/size, regional capability and data-boundary constraints; these variants are not a new capability matrix.

Existing keys may remain enabled when ARM shows aadOrApiKey and Entra read works. No Search/Storage keys, key retrieval, secret input, identity/firewall/network/tag changes, or hardening to fit creation defaults. Require running/succeeded, exact endpoint/ID and recognized observed SKU/region. Public firewall restrictions are preserved; actual caller read must succeed. Private/perimeter access is unsupported here: report search-network-unsupported, not a global compliance failure or instruction to open networking.

Search system MI is required for Blob (Storage/CU), source embeddings and KB chat/nonminimal reasoning, not lexical File or minimal/extractive KB alone. file-source does not encode CU auth: File's owner verifies MI or explicit legacy keys before its plan; this Search read is not File CU readiness. Verify required system principal/tenant; never accept a missing MI by request. UAMI selection is unsupported; an unused UAMI is not caller authentication.

For a selected operation, scoped az rest --method get --resource https://search.azure.com reads <endpoint>/servicestats?api-version=<selected-api> using CLI Entra auth, then exact ARM reread rejects access/identity drift. No billable write/model probes. Statistics GET proves only that metadata read, not source/KB write RBAC, feature-region support, Search-to-Storage/CU/model access, ingestion or retrieval. Verify these separate edges with the owning procedure before its plan/approval; no success-shaped fallback or permission relaxation on denial.

Handoff

selected: observed ID/endpoint/SKU/tier/location and qualified read evidence. After unique name/endpoint resolution, scope.resource_group and selection_input.resource_group carry the observed group in the selected subscription. Unresolved/ambiguous names and FIND retain their original scope; candidate rows carry each group's exact handoff without narrowing that inventory. operation_required means mode unresolved. Reuse selection_input; no receipt, approval envelope, ownership claim or creation-profile matching. Fresh selection/readback is not future consent. Creation delegates to unchanged bootstrap choices: secure new-service defaults, required region/quota/cost checks, exact collision reread and separate approval. Never run strict legacy bootstrap reuse merely to validate an existing operation.

Authorities

Authorities: failure/conflict/uncertainty only. Service naming rules, Entra and keys together, statistics GET.

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.

Download ZIP

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