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/standard-cu.md

Standard File dependency branch

Standard only: provisioning never proves CU readiness.

Use discovery for ARM AIServices endpoints; never OpenAI hostname replacement. ContentUnderstanding is not a documented endpoint-map key. Missing/ambiguous metadata blocks selection; endpoints are not readiness. Read shared CU ingestion for checks, model purposes and pending drafts. Existing CU/deployment/access evidence permits planning; no setup-owner or azd prerequisite. Do not ask for a separate account-configuration confirmation. prerequisites.configuration: selected processing/required deployment evidence, not a default-model setup certificate. Only missing dependencies need native Azure setup; obtain separate approval. bootstrap-cu-contract-unresolved: unresolved required dependency, not for reuse. Never default to reduced extraction.

Image verbalization/source chat stay off.

Disclose auth in the existing concrete source approval, not a separate "can you set the key?" or "is ENV ready?" question. File system MI is implemented in inspected service code; live compatibility is unverified. This is independent evidence, not nullable shared Swagger or Blob MI. The public File example still uses a key; do not claim public/live MI validation. New plans default to verified Search system MI; no key fallback or silent setup.

Standard File planning

Set extraction_mode: "standard" and this closed content_understanding choice:

{"endpoint":"https://cu.services.ai.azure.com","resource_id":"<CU ARM ID>","auth":"system-assigned","managed_identity":{"search_resource_id":"<Search ARM ID>","role_assignment_id":"<CU ARM ID>/providers/Microsoft.Authorization/roleAssignments/<GUID>"},"prerequisites":{"resource":"<CU readback>","configuration":"<processing/deployment evidence>","identity":"<Search MI/role readback>","network":"<reachability evidence>"}}

Evidence: 1–4096 characters; private artifact, not summaries. vectorization: "none" omits embeddingModel; azureOpenAI needs independent embedding choices. Endpoints need not match. Minimal omits CU choices. Neither filename nor MIME selects extraction.

file_source.py --plan GETs the exact CU account (2024-10-01) before and after Search discovery: AIServices, ready provisioning, endpoint/location/network. Planning is GET-only: no credential reads, including listKeys. ARM metadata is not effective access or processing proof; user yes/no answers are not readback proof.

MI artifacts: file_cu_plan_version: "1.2", cu_identity_state, source.ai_services_managed_identity: true. GET Search (2025-05-01) and the CU-scoped role (2022-04-01): fingerprint running Search principal/tenant, endpoint, unconditional Cognitive Services User and network; refresh before writes. Missing identity/roles use packaged bootstrap under separate concrete approval; source execution changes none. System MI requires existing public CU without default-deny ACLs; other configurations need verified contracts, not key fallback. Wire aiServices.uri without apiKey or ingestion identity; optional embedding identity remains separate. MI does not require or change disableLocalAuth.

Redacted CU readback cannot prove auth. MI reuse requires reuse_input_file and reuse_result_file: original approved v1.2 File input and completed creation result, matching fresh definition/ETag/account/identity and complete inventory. Stale/missing provenance or unexpected creation presence blocks. No reingestion or key-bearing callbacks.

Legacy complete-wire/1.0 ENV and 1.1 ARM artifacts remain compatible. Explicit auth: "api-key-arm" omits managed_identity; its fingerprint binds ai_services_key_acquisition: exact account/endpoint, caller tenant/subscription/ principal, ARM version, key1 and source-PUT purpose. Key modes require explicit disableLocalAuth: false; “local authentication” means key auth, not manual setup. After approval/fresh checks, ARM POST <exact-account-id>/listKeys (2024-10-01) selects key1 once, internally, for the exact source PUT only. Existing auth: "api-key-environment" uses api_key_environment: "CU_API_KEY"; another PowerShell session's ENV does not configure this helper. Never put keys in chat, plans, logs or command arguments, ENV writes, files or receipts. No key/account/auth fallback, rotation, permission grant or policy change. Denied Microsoft.CognitiveServices/accounts/listKeys/action needs owner-approved resolution. No debugger/locals or HTTP body logs; Python cannot guarantee zeroization.

Endpoint/auth/network/identity drift blocks. Tags are immaterial. Location compares ASCII case/whitespace only (East US/eastus), not region guesses or availability. Equivalent readbacks need no new approval; real region drift blocks. Other fields stay strict; retained snapshots/fingerprints are unchanged. For evidence uncertainty or an explicitly requested canary only, read bounded MI validation. Do not run it automatically.

Review billable CU (no daily free document allowance), content moving from Search to CU/selected embeddings, possible cross-region processing, retention and auth. No CU/model/Storage provisioning or KB changes are included. Approve credential scope/purpose with these costs/data/access disclosures once, then run python helpers/file_source.py --input <approved.json> from the skill root. Material changes need refreshed approval, not repeated unchanged consent. Exact source/ETag/file-marker reuse needs no mutation approval or credential read; reuse is not processing/retrieval proof. Preserve upload verification, first failure, partial ownership and separate cleanup.

Source settings: API versus helper

The table distinguishes API requirements from helper choices. File standard: 2026-08-01-preview. Blob CU: GA 2026-04-01 or August preview. ADLS preview is this helper's boundary.

SettingPublic contractHelper boundary
Name/typename, kind, parameters requiredOwner/purpose: workflow inputs
DescriptionOptional textBlob accepts null
LocationFile: Search-managed; Blob: connectionString/containerNameNo File Storage setup
PrefixBlob folderPath optionalprefix: "" needs root consent
ExtractioncontentExtractionMode defaults minimal; CU standard opt-inExplicit choice; API default is not content-fit guidance
EmbeddingsOptional/nullable embeddingModelExplicit wire choice; select deployment/auth
Source chatOptional chatCompletionModelVerbalization off; no mandatory KB chat
AuthCaller/dependency access; Blob keys/MIFile MI or explicit ARM/ENV; Search/Storage keyless
AdvancedBlob schedules; preview permissions/private ingestionBlob: public/system MI, no schedule/permissions. File: no indexer/schedule or networkAccessMode

Null/false/empty helper fields aren't mandatory API questions; portal key choices don't change helper auth.

CU's embedding-deployment prerequisite is not Search embeddingModel; mappings need contract/error evidence, never guesses.

Source formats binds detected types/limits/API. Preserve bytes; never execute scripts. Images need August standard; 415 retains ownership. No suffix gate/mode switch: inspection informs suitability, not service admission.

File prose requires fileParameters.ingestionParameters despite optional Swagger; source docs override generic inference.

Authorities

Authorities: failure/conflict/uncertainty only.

File documentation, CU account listKeys.

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