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

references/blob-ingestion-progress.md

Blob ingestion status and customer progress

Use when interpreting Blob/ADLS watch output, pauses, or requests for file x/y. This is asynchronous Blob observation, not the synchronous File upload contract. No new SDK, authentication, private-network/UAMI/asset-store or RBAC capability. Normal invocation and receipt-backed continuation: recheck.

Primary service evidence

The primary read is the selected knowledge source's GET knowledgesources/{name}/status?api-version={original-version}. The helper preserves its equivalent exact OData identity syntax. Use the admitted 2026-04-01 or 2026-08-01-preview version; no API substitution. synchronizationStatus describes source availability, not successful ingestion.

The actual service fields are:

  • currentSynchronizationState.startTime, itemsUpdatesProcessed, itemsUpdatesFailed, itemsSkipped, errors.

  • lastSynchronizationState.status, startTime, endTime, and the same counters/errors.

Missing counters stay unknown, never zero. A missing completion endTime means keep observing within the watch bounds, not a timestamp failure or completed run.

Require completion after the original cutoff, valid times/counters, zero failed updates, no relevant errors or current cycle. partialSuccess/failure blocks readiness even when successful work remains. Recheck also requires nonempty, zero-skip completion and unchanged source/configuration/Storage evidence. Source readiness is not verified KB retrieval or whole-corpus content coverage.

Current-run observations take precedence over an older last run. A newer run replaces counters; never add runs together as unique files. After observing a newer start, an older completion cannot finish that watch. Counter decreases replace the observation; never infer a reset is an ingestion failure. The guide does not promise monotonically increasing counters.

Generated indexer /status is supplemental, sharing the status-request/time budget. Its top-level running means available, not executing/success. Only a relevant lastResult supplies execution status/start/end and itemsProcessed (attempted) / itemsFailed. Neither attempted items nor index documents/chunks are unique input files; execution success can include item errors. The indexer cannot supply missing primary source counters or readiness. An observed active execution remains unresolved across primary reads. Require fresh same-indexer terminal success and a primary completion ending no earlier than that execution; start times need not be identical. Older executions cannot clear a newer observation. Retain the resolved execution in private watch evidence.

Customer presentation

Show the bounded helper's message, for example:

Blob ingestion observation ingesting: item updates processed=13; failed=1; skipped=0; file total/remaining unknown (not comparable); elapsed=675s; next check=5s.

Do not turn this into "13/25 files ingested; 11 remaining". The guide does not establish unique-file identity, processed/failed overlap, or counter-to-snapshot equivalence. Inventory size, filtered prefixes, statistics.totalSynchronizations, average items, chunks and index documents cannot establish that denominator. This helper therefore admits no file-fraction conversion: total/remaining stay unknown even when an inventory count is known. No percentages, subtraction, summed retries, ETA or assumed 25-file corpus.

Unchanged observations back off; throttling and the next bounded check are visible. Watch expiry/cancellation pauses observation; service execution is not modified. Resume with the original input/receipt, not another create/run/reset/delete. Repeated unchanged counters alone do not prove a stall. Watch limits remain 3600 seconds/1000 status requests, 60-second initial interval and backoff cap, 30-second status reads. One window per invocation; no daemon. Native response-body deadline exhaustion also pauses when the watch expires. A shorter read deadline with watch budget remaining is a retryable observation, not remote ingestion failure; retain its code/ID and use the existing backoff. Retry-After accepts bounded scalar headers or typed seconds/UTC-date metadata, including the frozen typed protocol's year-only RFC850 century correction. Missing/invalid metadata uses bounded backoff; an overlong marker or delay outside this watch's wait budget pauses, never retries early. No transport-wide retry or change to the shared File metadata contract.

Errors can contain document keys, URLs, SAS and content in key, docURL, componentName, errorMessage, details and documentationLink. Never echo them or follow their links. Customer errors retain sanitized status/code and the relevant request ID; full bounded ID trace and error digests stay private, not in progress messages. No full status JSON or ID wall.

Narrow output contracts

Native readiness.progress and stderr blob_progress share closed schema 1.0:

  • schema_version, unit: item-updates, denominator: not-comparable-to-files; total and remaining are null.

  • phase: ingesting, waiting, throttled, paused, completed or failed.

  • run_start: canonical timestamp or null; processed, failed, skipped: observed nonnegative integers or null.

  • synchronization_status: active, creating, deleting or not-reported.

  • elapsed_seconds: finite nonnegative number; next_check_seconds: null or a finite number from 0 through 60.

Stderr adds this record and a content-free message only for Blob workflows. Same-phase updates are throttled; phase changes and terminal events are immediate. --no-progress suppresses stderr without changing HTTP sequence or results.

Legacy retained creation/vector receipts remain readable; new progress must match its own completed cycle and never substitutes for ingestion proof.

Closed compact blob-operation-summary is 1.1 when it includes readiness.progress; results without progress retain 1.0. Original full private results, v3 checkpoints, acknowledgements, sanitized binding proof and strict cleanup ownership are unchanged. No generated-child edits or cleanup on timeout.

Authorities: failure/conflict/uncertainty only. Official Blob guide, updated 2026-09-02, source commit 78d82fc1240820245ee4143df9f5296641986171. Indexer status. Public documentation inspection is not live ingestion evidence.

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