Foundry Tools or a Model?

What Foundry Tools give you

Not every AI task needs you to pick a model and write prompts. Often a ready-made service already does the job, and choosing it is faster, cheaper to build, and easier to run.

Foundry Tools help developers and organizations create intelligent applications with out-of-the-box, prebuilt, and customizable APIs and models. Example applications include natural language processing for conversations, search, monitoring, translation, speech, vision, and decision-making. Most Foundry Tools are available through REST APIs and client library SDKs in popular development languages.

The key phrase is out of the box. Most Foundry Tools let you send data and receive insights without any customization. Two examples show the idea:

• Send an image to Azure Vision in Foundry Tools to detect words and phrases or count the number of people in the frame.
• Send an audio file to the Speech service to get transcriptions and translate the speech to text at the same time.

The current toolset

Each Foundry Tool covers one kind of capability, so the first step is matching the task to the right one.

In words: Speech handles audio in and out, Translator covers more than 100 languages, Vision reads images and videos, Document Intelligence and Content Understanding extract information from documents and media, and Content Safety detects unwanted content.

Some older tools are scheduled for retirement: Anomaly Detector, Content Moderator, Language Understanding (LUIS), Metrics Advisor, Personalizer, and QnA Maker. They're still available for existing applications, but don't use them for new AI applications.

So when a new design mentions QnA Maker or LUIS, that's a red flag, not a shortcut. The retirement list matters as much as the active list, because a retiring tool still works today and can look like a safe choice.

How you consume a tool

Foundry Tools are cloud services you call, and a few practical facts shape the choice.

• Client libraries and REST APIs give developers and data scientists the greatest flexibility to call the services from any language and environment. You need an Azure account and Foundry Tools resources.
• Pricing tiers are based on the number of transactions. Each tier sets a maximum number of transactions per second (TPS), the features enabled, and the cost for a predefined number of transactions.
• Many tools have a free tier: to use it, choose F0 as the SKU for your resource.
• Many tools can run in containers for on-premises access, which brings the tool closer to your data for compliance, security, or other operational reasons.
• Some services let you bring your own data and train a custom model, for example flower images labeled with each flower's location.
• Security is layered: Microsoft Entra credentials, a valid resource key, and Azure Virtual Networks.

A managed tool or your own model

Document processing is where this choice gets real, because three options overlap.

Azure Content Understanding in Foundry Tools is powered by generative AI and LLMs. It's good at unstructured documents, varying layouts, multimodal content, inferred fields, and complex reasoning, all without labeled training data to get started.

Azure Document Intelligence in Foundry Tools provides specialized models trained for document parsing and extraction. It's ideal for structured documents with common templates where consistency, low latency, and proven accuracy come first.

Azure-hosted LLMs (Foundry models) are for teams that need complete control over their own models, prompts, and infrastructure.

In words: the managed tools bring OCR, confidence scores and grounding, and managed scaling with them. Building on a model gives you control, but you add OCR preprocessing, chunking for large files, scaling, and any confidence scoring yourself.

When building your own wins

The managed route is the default, but not always the answer. Building directly on Foundry models may be appropriate when you need complete control over model selection, fine-grained prompt ownership, or integration with a proprietary AI infrastructure that Content Understanding can't accommodate.

Know the cost of that choice. A custom solution has to be tested across document variations, scaled, and managed by you. With no confidence scores, you either accept all results or review all results based on the expected error rate, or you build your own confidence model to score the output.

Content Understanding, by contrast, gives you built-in quality, reliability, confidence scoring, and model lifecycle management. And if a prebuilt analyzer covers your document type, start there before building a custom solution.

Choosing inside Content Understanding

Once you pick the managed route, the next question is Content Understanding analyzers (CU) or Document Intelligence models (DI).

The same table in words:

• For OCR or layout only, use CU prebuilt-read or prebuilt-layout, for lower cost and richer layout extraction.
• For standard structured forms such as invoices, receipts, IDs, tax, or mortgage documents, use a DI prebuilt model.
• For contracts and legal agreements, use the CU prebuilt-contract analyzer.
• For custom fields without labels, use a CU custom analyzer: describe the fields in plain language and iterate fast.
• For custom extraction with labels on highly structured documents, train a DI custom model with as few as 5 labeled samples.
• For on-premises or air-gapped deployment, DI containers are the only option today.

Scenarios that decide it

Real documents fall into a few patterns, and each one has a first choice.

• Single-format forms, the same template every time: use a DI prebuilt model for structured documents or a CU prebuilt analyzer for semi-structured ones; for custom fields, start with a CU custom analyzer, since no labeling or training is required.
• A few known variants, such as claim forms in three regional formats: start with a CU prebuilt analyzer if one covers the type, or train DI custom models with at least five samples of each variant.
• High-variation documents, such as invoices from many vendors: a CU custom analyzer is recommended. Start zero-shot, then add labeled samples to its knowledge source to improve accuracy over time.

• Unstructured documents, such as contracts or referral letters: Content Understanding is the ideal service. It can infer fields not present in the document, such as deriving a contract end date from a start date and duration, or identifying jurisdiction from the parties' addresses.
• Mixed media, such as PDF forms plus ID images plus a recorded interview: Content Understanding offers multimodal analyzers that reason over extracted content and reference data, and it integrates with agentic frameworks like Microsoft Agent Framework and LangChain.

Preview and GA status

Version status matters when you design for production.

The Content Understanding API version 2026-06-01-preview is in public preview. Previews come without a service-level agreement and aren't recommended for production workloads.

The quick-reference recommendations above apply to the generally available versions: Content Understanding v1.0 GA (2025-11-01) and Document Intelligence v4.0 GA (2024-11-30).

If you already run Document Intelligence in production, your APIs, endpoints, SDKs, and billing are unchanged, and no migration is required. The guidance applies to new workloads and to expansion into adjacent use cases where generative AI, multimodal processing, or zero-shot extraction add value.

Key takeaways

• Foundry Tools are prebuilt and customizable APIs and models; most return insights out of the box, with no customization.
• Retiring tools such as QnA Maker and LUIS still work for existing apps, but don't use them for new ones.
• The free tier uses the F0 SKU, and many tools can run in on-premises containers.
• Content Understanding fits unstructured, varied, and multimodal content without labels; Document Intelligence fits structured documents with common templates.
• Build on a Foundry model only for complete control of models and prompts, and plan for missing confidence scores.
• DI containers are the only option for on-premises or air-gapped deployment, and a DI custom model needs as few as 5 labeled samples.