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

helpers/file-upload-recovery.md

File upload continuation and partial batches

After partial File creation, retain the source. Never rerun creation, infer MI from redacted GET, or recover by recreation/deletion/reset/new roles. Generic File MI reuse/provenance guards remain unchanged.

Retain original evidence before creation

python helpers/file_source.py --input <original-approved.json> --cleanup-receipt-dir <private-receipts> --upload-receipt-dir <separate-private-empty-directory>

Use the private directory helper; no automatic directory/ ACL changes. The required journal retains original approval/context, actual conditional source PUT ACK/request ID/ETag, exclusive pre-POST attempts and separate upload responses. Never edit/remove/reconstruct entries. Integrity isn't a service signature: retain exclusive control, no concurrent writers.

File CLI creation requires protected --cleanup-receipt-dir and --upload-receipt-dir pre-write; separate directories, no guessed paths. Plan with --execution-output <new-private-plan.json>; show reference/counts, not hash-bearing envelopes. Plan JSON/library and non-File policies are unchanged.

Persistence failure stops requests. An attempt without result stays uncertain, even if POST wasn't sent. Missing ACK/ETag cannot come from GET. Journals neither replace cleanup provenance nor authorize deletion. Without originals: retain source, file-upload-provenance-missing, not "recreate required".

Supported upload-only plan

Closed request:

{"schema_version":"1.0","receipt_directory":"<absolute-original-private-directory>"}
python helpers/file_upload.py --plan resume-request.json --execution-output <new-private-resume.json>
python helpers/file_upload.py --input <newly-approved-resume.json>

Planning is read-only: an unapproved, closed version 1.0 resume-file-uploads envelope binds original plan/creation ACK/journal digests, owner, exact never-attempted ordinals and receipt directory; cleanup_approved stays false. Review and newly approve these uploads. An empty eligible list needs no mutation or execution; use the returned observation. Never edit ordinals/hashes to authorize attempted files.

Execution validates the original unchanged approved corpus (paths, full hashes, size, timestamps, mode, metadata), tenant/subscription/principal, source URL/API/ definition/ACK ETag, and applicable CU account/Search MI/role/network snapshots. It neither acquires CU keys nor changes authentication. It invokes only existing metadata GETs and direct File upload POSTs using the original Search identity; no source PUT, source update, new role, indexer operation, deletion, KB or model call. POST targets the original validated /knowledgesources('<name>')/files?api-version=2026-08-01-preview&pageSize=200 multipart contract; approval/privacy gates apply.

Continuation excludes previously attempted files, including exhausted 429 retries, timeout/409/5xx and interrupted attempts. Only the original operation may retry its received File-upload 429 once, as below. An immediate or delayed empty inventory never proves in-flight termination for unknown outcomes. Positive exact file-ID/ marker/hash/size readback can prove completed ingestion, but never invents an upload ACK or source ownership. Drift blocks; never repair by write.

Bounded batching and truthful progress

File upload is synchronous: extraction, chunking, embedding, indexing and metadata persistence finish before success. No File indexer, schedule or asynchronous status polling. Each sequential POST has a 180-second processing/response allowance, separate from the 60-second read budget; stricter approved outer deadlines win. Timeout is not remote cancellation. Retain 200/201 ACKs without relisting source/ full inventory after every healthy file. One final bounded inventory checks the batch; follow validated @odata.nextLink exactly, without rebuilding parameters. A per-file 415 permits independent continuation. Auth/access, deadlines, persistence, drift and unknown outcomes stop new uploads. Repeated 429, or later 429 after the operation's one retry opportunity, stops without more reads/sleeps. Preserve prior confirmed files; never hammer the remaining corpus.

429 recovery supplies one server-respecting delay/read opportunity, at most 30 seconds waiting/60 seconds per complete read sequence, including all pages and response reads. Overlong delays stop, not shorten. Journal-retained UTC backoff blocks resume planning/execution before any network; fresh approval never waives it. file_batch.backoff reports waiting/unresolved/ elapsed. Legacy 429 without timing stays unresolved; no invented deadline. --no-progress disables observations. Otherwise stderr emits counts, a waiting event with the bounded HTTP-429 delay, and terminal state. During POST, an immediate and then five-second content-free heartbeat reports ordinal/total/attempt, elapsed time and already ingested count: "1/25 ingested; processing file 2/25". This observer never makes requests. No within-file percentage, ETA, filenames or private content. Increment completion only after ACK/metadata proof and required receipt persistence.

file_batch.files records bounded relative names/full hashes, upload state, verification state and sanitized request IDs. Counts distinguish: accepted (original 200/201 ACK), confirmed (exact file-ID/markers without reported error), failed, pending (ACK but not confirmed), unverified (uncertain attempt), and not_attempted. Accepted overlaps verification counts; do not sum it with them. ingested counts synchronous completion proved by valid ACK metadata or exact completed-file readback. A status-only ACK is insufficient. Original ACK file IDs remain binding even if its remaining metadata is incomplete. Failed readback stays partial while preserving known prior ingestion; retrieval stays unverified. File completion does not prove OCR quality or KB retrieval.

Report "24 ingested, one failed/unverified" only with this proof; otherwise distinguish accepted/pending. Preserve outcomes, not a blanket blocker. A subset handoff must disclose pending files may appear and subset isolation is not proven; any KB use still needs its existing separate approval. No automatic KB writes.

One documented queue-rejection retry

The official File guide identifies upload HTTP 429 as a full processing queue and recommends bounded parallelism/exponential backoff; Retry-After is not guaranteed. Only this File upload route permits one same-operation retry across the batch, not per file. No private throttle marker/error text is required. Honor valid Retry-After; missing/invalid metadata uses the diagnosed first backoff step of one second. Shared 30-second wait/60-second complete preflight limits apply. After waiting, revalidate unchanged source/corpus and one fresh bounded inventory. Positive proof avoids another POST; absence is not the retry authority: the received queue-rejection 429 is. Persist exclusive original/retry attempt and result records when journaling. Retry the original URL, token, multipart bytes/ boundary and approved payload; source creation happens once.

The MI canary's stricter one-upload approval forbids this retry. No PUT/DELETE/ update retry, new roles or auth substitution. Each upload creates a new file ID, even for the same filename; no filename-idempotency key exists. Timeout/504/409/ 5xx remain unknown, never replayable from empty inventory or elapsed time. file-upload-retry-safety-unproven retains that blocker. Exhausted files stay failed; continuation uploads only never-attempted files under fresh approval, not another attempt at an exhausted file.

Authorities: failure/conflict/uncertainty only. File upload/troubleshooting.

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