Useful AI. Built around your work.

Top pickDeployable app

Content Processing

Multi-document claim and intake processing

Intake document packs and flag missing material before review.

Operations teams

Microsoft-owned public repository

Top pickDeployable app

Document Knowledge Mining

Multimodal document discovery and comparison

Ask questions across documents and compare what they say.

Document reviewers

Microsoft-owned public repository

Top pickDesign only

RFP & contract review

Reviewer-led document assessment

Help reviewers compare requests for proposals and contracts against required evidence.

Procurement teams

Proposed custom workflow

Top pickDeployable app

Modernize

Informix SQL to T-SQL modernization

Help engineering teams review a bounded SQL-dialect conversion.

Software teams

Microsoft-owned public repository

Top pickOwner confirmation needed

SpecSuite

Code to spec · Knowledge graph · Spec to code

Turn existing code into specifications and connected system knowledge, then use reviewed specifications to guide improved code and modernization.

Software teams

Private owner-led solution

Builder toolkit

Employee Self-Service

ESS Agent Developer Kit for Copilot Studio

Help staff navigate routine internal guidance and service requests.

Assistant builders

Microsoft-owned public repository

Engineering codebase

Real-time voice agents

ART · Azure Real-Time Agent Accelerator

Answer routine spoken enquiries over the phone or a browser, and hand off to a person.

Voice app builders

Microsoft-owned public repository

Deployable app

Customer chatbot

Embedded service and product assistance

Answer routine service questions from approved guidance.

Customer service teams

Microsoft-owned public repository

Service integration

Voice Live

Real-time spoken agents with Bring Your Own Model (BYOM)

Explore spoken access to a bounded assistant workflow.

Service builders

Microsoft / GitHub platform guidance

Deployable app

Multi-agent orchestration

Multi-Agent Custom Automation Engine (MACAE)

Coordinate several assistant steps for a larger staff-work task.

Workflow builders

Microsoft-owned public repository

Deployable app

Conversation Mining

Conversation Knowledge Mining

Find themes and recurring issues in approved conversation records.

Service analysts

Microsoft-owned public repository

Deployable app

Content Generation

Creative brief to marketing copy and images

Provide a starting point for marketing-oriented generation experiments.

Content teams

Microsoft-owned public repository

Deployable app

Agentic Unified Data Foundation

Agentic Applications for Unified Data Foundation on Fabric

Connect an AI application to governed enterprise data through a Fabric Data Agent.

Business data teams

Microsoft-owned public repository

Fabric starting point

RealTime Operations

Real-Time Intelligence for Operations

Explore assistance around operational signals and emerging issues.

Operations analysts

Microsoft-owned public repository

Developer sample

Video workflow

.NET AI Video Analyzer

Explore a narrowly scoped video task under review.

Media app builders

Microsoft-owned public repository

Deployable app

Planetary Explorer

Natural-language Earth-science exploration

Explore specialist geospatial questions where there is a defined need.

Research teams

Microsoft-owned public repository

Configuration choice

Bring Your Own Key pilot

GitHub Copilot / VS Code Bring Your Own Key (BYOK)

Explore connecting developer tools to an organization-managed model.

Developer teams

Microsoft / GitHub platform guidance

Training workshop

MCP security workshop

Sherpa · securing agent tool connections

Teach engineers how to secure the tool connections that AI agents depend on.

Security learners

Microsoft-owned public repository

Infrastructure only

Private platform baseline

Deploy Your AI Application In Production

Offer a technical starting point for future integrated workflows.

Platform teams

Microsoft-owned public repository

Examples illustrate intended use, not customer deployments or verified results. This is a curated set of starting points, not a ready-to-install product suite. Each guide explains its readiness, limits and deployment requirements.

Your solution shortlist

No solutions selected. Open a solution and add it to your shortlist.

Combine the solutions you need; planning keeps unresolved gates visible. Selections stay in this page until reload; nothing is sent or saved to browser storage.

Tenant pilot checklist

Agree one outcome, an accountable business owner, an engineering owner and measurable acceptance criteria.
Confirm data permission, identity, service and region availability, model/API compatibility, quota, licenses and the full service budget.
Open the pinned source and later maintenance notices. Review prerequisites, license, support ownership and deployment templates; retain the reviewed revision or explicitly approve its replacement.
Have the tenant platform team adapt configuration to approved network and identity controls. Inspect model-resource creation even when reusing a project; verify intended endpoint and persisted-agent routing. Obtain approval before deployment commands.
Deploy only into an approved pilot environment using the chosen package instructions. Use synthetic or permitted data and bounded spending.
Test the named outcome, access restrictions, failure handling and costs. Assign monitoring, support and rollback ownership before any wider rollout.

Pilot acceptance and PTU value

Track adoption, accepted work, PTU utilization and headroom, time saved, quality and total service cost against an agreed baseline.

Scope and ownership
Name business, engineering and review owners. Agree the baseline, target, permitted data, representative examples, time box and spending limit before starting.
Outcome and safety
Evaluate the complete user journey, material errors, citations, permissions, missing inputs and escalation. Source inspection and successful provisioning are not acceptance.
Routing and economics
Trace every model path, including persisted agents and retrieval planning. Confirm deployment, model/version, API and approved geography; compare Standard, eligible Batch and existing PTU headroom.
Operate or stop
Expand only after agreed quality, useful demand and operating ownership are established. Otherwise repair, change the approach or stop; do not generate work to fill capacity.

Top pick / Application accelerator

Enterprise Knowledge

Turn a document collection into answers people can trace.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: An internal question-and-answer website for the information buried in your policies, manuals and procedures, with a chat screen for staff and a document-loading screen for administrators.
How it works: You load approved files or web pages. When someone asks a question, the app finds relevant passages, drafts an answer with source citations and supports follow-up questions.
Use it for: Help employees find and understand existing guidance without opening dozens of files or repeatedly asking a subject-matter expert. Readers can check the cited source.
Example scenario: Load a travel handbook, ask which expenses need advance approval, then open the cited policy passage to confirm the answer.

From input to useful workIllustrative

DocumentsInput
RetrieveProcess
Cited answerOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Knowledge owners, policy teams and internal service teams
What you get: A searchable document collection / Streaming answers with source citations / Conversation history
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A private question-answering site for your own documents. You load an approved collection — policies, procedures, manuals — and staff ask questions in ordinary language. Every answer shows the passage it came from, so the reader can check it rather than trust it.

What you actually receive

A web application you deploy: a chat window for staff, plus an admin page for loading documents.

What it does

Takes documents and web pages you upload and prepares them for search.
Finds the passages that relate to a question before it answers.
Writes the answer in plain language with citations to the source.
Keeps the conversation so people can ask follow-up questions.

What you would gain

People stop asking colleagues where a policy lives and get the passage itself.
Answers are checkable: a citation means a reader can confirm it.
New joiners find the reasoning behind an unfamiliar process without interrupting someone senior.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Selected knowledge-search and answer tests passed in an adapted local implementation. This is narrower than verification of an unchanged upstream package.

Choose this if

Your problem is really "the answer is in our documents somewhere".
Readers need to see the source, not just a confident paragraph.

Consider something else if

You have a specialist comparison or filtering gap after a CWYD-first pilot: assess Document Knowledge Mining only with a named maintenance owner or approved replacement, not a duplicate stack.
You need the same fields pulled out of every file into a record: see Content Processing.

01 / Use it for the right job

Where it earns its place.

An internal knowledge application with an administration workspace for ingestion and a conversational workspace for staff. It retrieves relevant passages before generating an answer, shows inline citations and retains conversation history. Use it when the primary job is finding an answer, rather than extracting a structured record from every file.

Best uses

Answer recurring policy or procedure questions from a maintained collection.
Help new team members find the source behind an unfamiliar process.

Know the boundary

Document permissions must be designed and tested; adding sign-in alone does not prove document-level authorization.
This is not a system of record or a replacement for checking the cited policy.

How people use it

A React chat workspace with source citations and history, plus an admin interface for document uploads and webpage indexing. The linked upstream overview shows the application; this page describes its workflow, not a simulated chat.

Publish a collection
A knowledge owner uploads supported documents or indexes approved webpages in the admin interface. Processing makes the content available for retrieval.
Ask a question
Staff enter a question in the chat workspace. The backend retrieves relevant material and streams a grounded response.
Follow the evidence
Open the cited sources, examine the context and continue the conversation. Unanswered questions reveal gaps in the collection.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Separate ingestion from interactive chat. The illustrated retrieval branch uses AI Search and Cosmos DB; PostgreSQL is the alternative documented by the package.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Documents / webpages
Owned sources
Approved source material enters through administration, not an unrestricted public upload endpoint.
Ingestion backlog
Blob + Queue Storage
Blob holds originals; the queue hands work to the ingestion worker.
Ingestion worker
Functions / Container Apps
Parses, chunks and embeds documents before updating retrieval storage.
Retrieval index
Azure AI Search
Returns passages and source metadata; replaced by pgvector in PostgreSQL mode.
Chat + admin UI
React / Container Apps
The browser experience for asking questions, reviewing citations and managing content.
Chat orchestration
FastAPI / Container Apps
Agent Framework or LangGraph coordinates retrieval, answer streaming and history.
Language + embeddings
Microsoft Foundry
Generates embeddings and responses. Content Safety and supported speech features are separate service dependencies.
Conversation state
Azure Cosmos DB
Persists history in the AI Search route; PostgreSQL mode replaces this dependency.

Read all 8 connections

Documents / webpages to Ingestion backlog
Upload originals
Ingestion backlog to Ingestion worker
Dequeue ingestion jobs
Ingestion worker to Retrieval index
Write indexed chunks
Chat + admin UI to Chat orchestration
Questions and streamed answers
Chat orchestration to Retrieval index
Retrieve relevant passages
Chat orchestration to Language + embeddings
Grounded generation
Ingestion worker to Language + embeddings
Embed chunks
Chat orchestration to Conversation state
Read and write conversations

The pinned design uses managed identity and RBAC. Its README explicitly does not require Key Vault for application secrets.
Configure and test end-user Entra authentication deliberately. Without it, the deployment guide says visitors share a default user and lack per-user history isolation.
The reviewed AVM template pairs PostgreSQL with LangGraph and the Cosmos DB/Search route with Agent Framework. The guide and top-level Bicep disagree on the default storage mode; inspect the selected deployment parameters rather than assuming a default.

03 / Prepare the inputs

From your data to useful output.

Supported documents and explicitly approved webpages, with an owner and update policy.

Queue the work
Uploads go to Blob Storage; Storage queues decouple intake from processing. Event Grid is an optional trigger.
Extract and index
A Functions worker hosted on Container Apps parses content, chunks it and creates embeddings.
Choose one storage route
Use AI Search with Cosmos DB, or PostgreSQL/pgvector for retrieval and history. These are deployment alternatives, not a mandatory combined stack.

Check citations against originals, deletion/reindex behavior and denied-access questions before inviting more staff.

04 / Run it in your environment

What you need to get running.

Azure Developer CLI and Bicep, followed by explicit container-image and application setup.

Code & access

Your team needs

Review the storage/orchestration pairing configured by the selected deployment template.
Confirm chat and embedding deployments, extraction services and region availability.
Review model-deployment resources and persisted agent model selections; verify the actual approved endpoint rather than assuming Foundry-project reuse means PTU reuse. Existing-project paths can still deploy GlobalStandard models.
Provide deployment/RBAC permissions, an approved network design and a document-access model.

Bring approved inputs

Supported documents and explicitly approved webpages, with an owner and update policy.

Budget separately for

Chat and embedding inference
Search plus Cosmos DB, or PostgreSQL
Container hosting, extraction, storage and monitoring

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/Azure-Samples/chat-with-your-data-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach 0fce71307dfa76a82ac82ec73bdde3daa47e503d
git rev-parse HEAD

Prepare the environment
Use the guide's local environment or reopen the pinned checkout in its dev container. Local setup needs Python 3.11, Node LTS, PowerShell and azd; the data setup script requires Azure CLI 2.87+. Avoid azd 1.23.9 rather than disabling preflight checks.
Configure before provisioning
Review infra\main.parameters.json and the linked parameter guide. Explicitly choose databaseType: the guide and top-level template disagree on its default. Confirm chat and embedding deployments, identity, region and approved network access. Resource reuse is not proof of PTU routing.
Provision infrastructure
Sign in to both CLIs, select the approved subscription and choose a new environment when prompted. This leaves placeholder images, not a working application.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Install the application and data plane
From the repository root, run these in order with the resource group produced above. The image script can temporarily open registry access: stop and arrange an approved private build path if policy prohibits that behavior.
Show commands
```
.\infra\scripts\post-provision\acr_build_push_update.ps1 -ResourceGroupName "<resource-group>"
.\infra\scripts\post-provision\post_deployment_setup.ps1 -ResourceGroupName "<resource-group>"
```
Require sign-in and ingest a small collection
Complete the authentication instructions in Step 5.3 of the pinned guide before sharing. Open the frontend URL, go to /admin, choose Ingest Data and upload permitted sample documents. Wait for ingestion; sign-in alone does not implement document-level authorization.

Verify before sharing

Ask a question with a known answer, open its citations and test an unanswerable question. Check user/history separation and document access with two test identities; verify the actual model deployment in provider telemetry.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

We can work with your AI and platform teams from code access and architecture through approved deployment, evaluation, handover and onboarding more teams. Agree scope, delivery roles, funding and support with the program/account team; this is not a support entitlement or promise of free implementation.

AI application CSA
Choose retrieval/orchestration options and define answer evaluation.
Search and data specialist
Design chunking, metadata, source refresh and access-aware retrieval.
Identity/platform engineer
Review sign-in, managed identity and network dependencies.

Bring to the session

An approved sample collection and its permission rules
Questions with expected source passages
The content owner and refresh/deletion requirements

Agree how to judge success

Citations support each material answer.
Out-of-scope and unauthorized questions do not leak content.
Source corrections and deletions appear in subsequent answers.

First working session

Agree a first corpus, draw its authorization boundary and compare expected answers against retrieved passages.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Top-level deployment parameters (opens in a new tab)
The top-level Bicep defaults databaseType to cosmosdb, while the deployment guide describes PostgreSQL as the default. Inspect the selected parameter route rather than assuming a default.
Image installation and application setup (opens in a new tab)
The manifest prints separate image build/push/update and post-deployment setup commands; infrastructure provisioning is not the complete application installation.

Pinned revision 0fce71307dfa76a82ac82ec73bdde3daa47e503d. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Run a guided demonstration with approved documents, source checks and a human reviewer.

Evaluation context

Selected knowledge-search and answer tests passed in an adapted local implementation. This is narrower than verification of an unchanged upstream package.

Results apply only to the tested adaptation and scenarios.
Access-aware retrieval, source quality and evaluation on representative material still need hardening.

Model capacity and cost

Repeated interactive questions could use compatible reserved model capacity. These tests do not establish PTU sizing or sustained demand.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Top pick / Application accelerator

Content Processing

Turn a document pack into structured results and explain its gaps.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: An intake application for work that arrives as a pack of related documents. Its built-in example processes insurance claims; another process needs its own fields and rules.
How it works: Reads each file, extracts fields into a structured record, evaluates the results and summarizes the whole pack with missing-information findings for a reviewer.
Use it for: Prepare consistent records and identify incomplete submissions before someone starts a detailed review. The complete processing path still needs evaluation; this does not approve a claim or request.
Example scenario: Submit a sample claim pack with one required document missing and inspect the completeness report and extracted fields before handing it to a reviewer.

From input to useful workIllustrative

DocumentsInput
ExtractProcess
FieldsOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Claims operations, document intake and process engineering teams
What you get: Mapped document fields and evaluation results / A cross-document claim summary / Gap findings linked to the processed pack
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

An intake system for packs of related documents; the example built in is an insurance claim. Each document is read and its fields pulled out and checked, then the pack is summarised as a whole with a report of what is missing. Moving it to a different intake process means rewriting the field definitions and rules.

What you actually receive

A web application you deploy that follows documents through a processing pipeline.

What it does

Extracts fields from each document and maps them to a defined schema.
Evaluates and stores each result with a confidence score.
Summarises the pack as a whole rather than one file at a time.
Reports what the pack is missing, linked back to the documents reviewed.

What you would gain

"Is this pack complete?" is answered before a reviewer spends time on it.
Structured fields come out of unstructured paperwork, so other systems can use them.
Findings point back at the documents, so a reviewer checks rather than trusts.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: A bounded missing-document workflow passed. A filter warning occurred, and the full happy path was not established.

Choose this if

Work arrives as a bundle of related documents that must be checked for completeness.
You need consistent fields from every document, not a conversation.

Consider something else if

You want document answers rather than structured intake: start with Enterprise Knowledge; assess Document Knowledge Mining only for an unmet specialist gap and with maintenance ownership.
You are assessing bids or contracts against a rubric: see RFP & contract review, which is a proposed workflow only.

01 / Use it for the right job

Where it earns its place.

The current accelerator is a multi-document claim-processing system. Individual documents pass through extraction, mapping, evaluation and persistence; a separate workflow coordinates the pack, builds a cross-document summary and performs gap analysis. Schemas and rules are the customization surface for other intake processes.

Best uses

Process a claim assembled from several related documents.
Adapt schema-driven extraction and gap checks to an owned intake process.

Know the boundary

The package is not a generic procurement decision engine; changing the domain requires schemas, rules and evaluation.
Confidence scores are not proof that extracted fields are correct. YAML requirements guide an AI gap-analysis agent rather than a deterministic compliance engine.
Gap findings are reviewer inputs, not automatic payment, coverage or eligibility decisions.

How people use it

A React/TypeScript processing monitor backed by a FastAPI gateway. The user follows document/process status and examines claim-level results rather than interacting only through a chat box.

Submit a pack
Provide the related documents and the processing definition for the claim.
Follow processing
The monitor shows progress while the workflow coordinates individual document jobs.
Review summary and gaps
Inspect mapped fields, evaluations and cross-document findings before taking any business action.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Four Container Apps separate the web monitor, API, pack workflow and document processor. Queue boundaries make long-running work distinct from the request/response UI.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Processing monitor
React / Container Apps
Shows processing status and reviewable results.
Intake gateway
FastAPI / Container Apps
Accepts process requests and exposes status/results.
Claim workflow
Workflow Container App
Coordinates document jobs, cross-document summaries and gap analysis.
Document processor
Processor Container App
Runs Extract -> Map -> Evaluate -> Save for each document.
Work dispatch
Storage queues + dead letter
Separates asynchronous workers and failed work from the UI.
Document extraction
Content Understanding
Extracts the content used by mapping and evaluation.
Mapping and synthesis
Azure OpenAI
Supports mapping, summarization and gap reasoning.
Documents and results
Blob + Cosmos DB
Blob stores files/manifests; Cosmos stores definitions, process state and claim results.

Read all 9 connections

Processing monitor to Intake gateway
Submit / inspect status
Intake gateway to Work dispatch
Enqueue work
Work dispatch to Claim workflow
Coordinate a claim
Work dispatch to Document processor
Dispatch document jobs
Document processor to Document extraction
Extract document content
Document processor to Mapping and synthesis
Map fields
Claim workflow to Mapping and synthesis
Summarize and find gaps
Claim workflow to Documents and results
Persist claim results
Document processor to Documents and results
Read files / save results

App Configuration and ACR support the four services; neither is the system of record for claim documents.
The evaluation handler merges confidence signals from extraction and model output; it is not an independent factual-validation model call.

03 / Prepare the inputs

From your data to useful output.

Related claim documents, processing schemas and domain-specific gap rules.

Store and dispatch
Blob Storage holds documents/manifests; queues deliver work to the workflow and document processor.
Extract, map, evaluate, save
Content Understanding extracts content and model-assisted mapping converts it to the configured schema. Evaluation merges available extraction and model confidence signals into field-level scores; these are not proof that a field is correct.
Assemble the claim
The workflow summarizes across documents and supplies YAML-defined requirements to a gap-analysis agent. Cosmos DB stores process and claim results for review.

Include complete packs, missing files, contradictory values and malformed documents; inspect queue/dead-letter handling.

04 / Run it in your environment

What you need to get running.

Provision four Container Apps and their data/AI services, then complete image build/push, the post-deployment script and required application authentication configuration.

Code & access

Your team needs

Content Understanding and model availability in the approved region
Review model-deployment resources and persisted agent model selections; verify the actual approved endpoint rather than assuming Foundry-project reuse means PTU reuse. Existing-project paths can still deploy GlobalStandard models.
Claim schemas, YAML gap rules and approved sample packs
Container build permissions, required application authentication setup and ownership of failed-job handling

Bring approved inputs

Related claim documents, processing schemas and domain-specific gap rules.

Budget separately for

Content Understanding extraction
Model mapping, summarization and gap analysis
Four application runtimes, Cosmos DB, queues, Blob and monitoring

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/content-processing-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach 659eaa1f503dd08b1e1aea1c72eab11c7c191d00
git rev-parse HEAD

Prepare configuration
Use the pinned guide's local toolchain or dev container. Review infra\main.parameters.json, extraction model availability, Foundry reuse, identity, network settings and schema requirements. Use compatible azd rather than disabling preflight.
Provision infrastructure
Select the approved subscription and a new lowercase alphanumeric environment. This is only the infrastructure stage.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Install images, then initialize schemas
Run from the repository root in this order. Check the API is ready and the Auto Claim schema set exists. The guide mentions automatic registration, but the pinned manifest has no post-provision hook; do not assume these steps ran.
Show commands
```
.\infra\scripts\acr_build_push.ps1
.\infra\scripts\post_deployment.ps1
```
Configure application authentication
Complete ConfigureAppAuthentication.md, linked from Step 5 of the manual: register the required applications, configure the frontend/API identity settings and callback URLs, and apply consent as documented. Authentication is required for access.
Upload and inspect a sample
Open the Web App Endpoint from deployment output, sign in, select Auto Claim and the matching schema, then Import Content. Use the permitted sample files under src\ContentProcessorAPI\samples before designing customer schemas.

Verify before sharing

Open a completed row and compare every required field with its source. Exercise missing fields, invalid input and authorization failures; capture extraction errors rather than treating a completed status as accuracy.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Document AI CSA
Map the schema and choose extraction/evaluation criteria.
Process/domain specialist
Define completeness and cross-document consistency rules.
Application engineer
Own workers, retries, dead letters and process-state visibility.

Bring to the session

Complete, incomplete and contradictory document packs
Field definitions and gap rules
A reviewer who can label correct and incorrect findings

Agree how to judge success

Mapped fields match original documents.
Missing and conflicting evidence is distinguished.
Failed processing cannot appear as a successfully completed claim.

First working session

Walk one pack through per-document extraction and claim-level gap analysis, then identify the domain-specific adaptations.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Extraction confidence evaluation (opens in a new tab)
Evaluation merges available Content Understanding confidence and OpenAI log-probability signals into field-level scores. It does not independently establish factual correctness.
AI gap-analysis implementation (opens in a new tab)
The executor loads YAML rules into an agent prompt, runs model-based gap analysis and persists the response to the claim record.
Sample claim requirements (opens in a new tab)
The sample YAML defines claim document types and requirements used to guide the gap-analysis agent; it is not evidence of a deterministic compliance engine.
Schema registration implementation (opens in a new tab)
The explicit post-deployment script waits for the API and registers schemas. It can skip registration when the API does not become ready.
Pinned azd hook configuration (opens in a new tab)
The manifest contains preprovision hooks only, despite the deployment guide describing automatic post-provision schema registration.

Pinned revision 659eaa1f503dd08b1e1aea1c72eab11c7c191d00. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Resolve the warning and test a complete document pack end to end before a guided demonstration.

Evaluation context

A bounded missing-document workflow passed. A filter warning occurred, and the full happy path was not established.

The successful missing-document case does not prove complete processing of a valid pack.
Resolve the filter warning and validate normal, malformed and incomplete inputs.

Model capacity and cost

Model-assisted checks could use compatible capacity. Parsing and storage cost extra; deferred processing may suit Batch.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Top pick / Application accelerator

Document Knowledge Mining

Search, filter and compare a body of documents, not just chat with one.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A research workbench for finding and comparing evidence across a large collection of documents, including information in pictures and scanned pages.
How it works: You upload documents; it extracts searchable text, topics and named entities. Filter the collection, select relevant files, then ask questions across that specific set or compare their contents.
Use it for: Investigate differences, recurring requirements or conflicting statements instead of reading every file end to end. Use it for a specialist gap, with an accountable maintenance owner.
Example scenario: Select three versions of a procedure and ask what changed in the approval requirements, then check the cited material against the originals.

From input to useful workIllustrative

DocumentsInput
CompareProcess
FindingsOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Research analysts, policy specialists and document-review teams
What you get: A searchable, filterable asset collection / Extracted metadata and summaries / Document-scoped answers and comparisons
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A research workbench for a body of documents. It reads the text and the pictures in your files, pulls out topics, names and other details you can filter by, and lets you ask questions across everything, across a chosen subset, or of one document at a time. Start with Enterprise Knowledge for general knowledge work; assess this specialist option only for a remaining gap, without building duplicate stacks.

What you actually receive

A specialist document-search and comparison application whose upstream is no longer maintained. A named maintenance owner or approved replacement is required before a new deployment.

What it does

Processes both text and images in uploaded documents into searchable material.
Extracts topics, entities and metadata so a large collection can be narrowed.
Answers questions across all documents, a selected set, or a single file.
Suggests follow-up questions to continue an investigation.

What you would gain

Narrowing comes first: a large collection is cut to the relevant few before anyone reads.
Comparing documents against each other is the built-in job, not something assembled by hand.
Scans and image-heavy material become searchable instead of sitting in a folder.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Selected question-answering and document-comparison scenarios were verified against a limited corpus.

Choose this if

A CWYD-first pilot leaves a specific need for collection filtering, selected-document comparison or image-heavy evidence.
A named owner will maintain the selected implementation, or an approved replacement meets that specialist need.

Consider something else if

You mainly need answers from an owned policy collection: start with Enterprise Knowledge rather than a second knowledge stack.
Nobody can own maintenance: choose an approved maintained alternative instead of deploying this unsupported upstream.
You need identical fields extracted from every document: see Content Processing.

01 / Use it for the right job

Where it earns its place.

DKM processes document text and images into searchable knowledge, extracts entities and metadata for filters, and supports conversations over all assets, selected documents or search results. These specialist capabilities can help analysts narrow a corpus and compare evidence. Start with CWYD for general knowledge work; use DKM only for an unmet specialist need with an explicit maintenance owner or approved replacement, not as a duplicate knowledge stack.

Best uses

Compare requirements or positions across a selected set of documents.
Find assets by extracted topics/entities, then investigate them conversationally.

Know the boundary

OCR and visual interpretation can miss tables, handwriting or layout-dependent meaning.
The AKS-based processor/orchestrator is more operationally involved than a small single-container chat sample.

How people use it

A React/TypeScript asset-search interface with upload/processing, entity filters and document-scoped chat. Analysts can chat with a single asset, selected assets or a search-result set; suggested follow-ups help continue the investigation.

Find the relevant assets
Search the collection and narrow results using extracted entities and metadata.
Set the evidence scope
Choose one document, several assets or search results as the conversation context.
Compare and inspect
Ask for similarities, differences or a synthesis, then check the answer against original document evidence.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

AKS hosts the React frontend, interactive AI service and asynchronous document-processing service. Processing and conversational orchestration have separate responsibilities.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Document workspace
React / AKS frontend
Search, filters, upload and scoped document chat. The pinned deployment script deploys frontapp to Kubernetes; the architecture guide describes App Service instead.
Files and backlog
Blob + Storage Queue
Stores originals and schedules document processing.
Document processor
AKS pods
Runs file-specific extraction pipelines, chunking and enrichment.
OCR and layout
Document Intelligence
Extracts text and handwriting for downstream document interpretation.
Knowledge index
Azure AI Search
Stores vectorized chunks and fields used for retrieval and filters.
AI service
AKS / Semantic Kernel
Orchestrates selected-document chat and streams responses.
Interpret and answer
Azure OpenAI
Supports multimodal enrichment and conversational answers.
Metadata and history
Cosmos DB for MongoDB
Persists processed-document results and chat history.

Read all 9 connections

Document workspace to Files and backlog
Upload documents
Files and backlog to Document processor
Read queued files
Document processor to OCR and layout
Extract text/layout
Document processor to Knowledge index
Index chunks and vectors
Document workspace to AI service
Search / scoped chat
AI service to Knowledge index
Retrieve selected evidence
AI service to Interpret and answer
Generate grounded response
Document processor to Interpret and answer
Enrich extracted content
AI service to Metadata and history
Read metadata / save chat

The reviewed Bicep and application deployment script use AKS, including the frontend. The architecture guide's App Service description is inconsistent with that deployment implementation.
App Configuration, ACR and monitoring support these workloads but are omitted from the data-flow view.

03 / Prepare the inputs

From your data to useful output.

An approved document corpus, including supported image-bearing files, with a defined metadata scheme.

Upload and queue
Original documents enter Blob Storage and processing steps are queued in Storage Queue.
Extract multiple modalities
AKS document-processing pods use Document Intelligence OCR and model-assisted extraction to derive text, context, keywords and summaries.
Persist search and metadata
Write chunks/vectors to AI Search, processed artifacts to Blob and document metadata to Cosmos DB for MongoDB.

Compare extracted values with source pages, including images/tables; test conflicting documents and permission boundaries.

04 / Run it in your environment

What you need to get running.

Package Bicep/azd infrastructure deployment, followed by Deployment/resourcedeployment.ps1 to configure Kubernetes, build/push images and deploy application workloads.

Code & access

Your team needs

Named maintenance owner or approved replacement for this no-longer-maintained accelerator before any new deployment
A specialist requirement not met by the CWYD-first pilot and a plan to avoid duplicate knowledge stacks
AKS operations ownership and container registry/build access
Search, Document Intelligence, model and Cosmos DB availability
Approved corpus, extracted-field requirements and user-access design

Bring approved inputs

An approved document corpus, including supported image-bearing files, with a defined metadata scheme.

Budget separately for

AKS nodes and application hosting
OCR, language models and embeddings
Search, Cosmos DB, queues, Blob and monitoring

No deployment commands run from this site.

Azure application - maintenance gate

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Document-Knowledge-Mining-Solution-Accelerator.git accelerator
Set-Location accelerator
git checkout --detach 7df8ed33a86dd4f0f9e7417e882039fd38556e59
git rev-parse HEAD

Resolve maintenance and tooling
This upstream is no longer maintained. Obtain an accountable maintenance owner or choose a replacement first. Prepare the guide's PowerShell, Azure CLI, azd and Kubernetes deployment prerequisites.
Review configuration and provision
Review infra\main.parameters.json, model/embedding deployments, AKS sizing and network settings. Sign in, select the approved subscription and run the infrastructure stage; do not relax filters or increase quotas as a shortcut.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Install Kubernetes application components
From the repository root, enter Deployment and run the application installer. With an azd deployment it discovers configuration; inspect every prompt and stop on errors.
Show commands
```
Set-Location Deployment
.\resourcedeployment.ps1
```
Configure authorized access and load data
Use the installer's final application URL and complete the guide's authentication/data-upload steps. Load only the approved small corpus and wait for processing. Do not copy upstream suggestions to weaken content filters.
Open document and collection chat
Use Chat with documents, then open a document's Details and chat view. Check the extracted material before relying on an answer.

Verify before sharing

Compare extracted fields and answers with source documents, including empty/unsupported documents and a second user's access. The historical limited-corpus result is not acceptance of a new installation.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Document AI specialist
Review extraction pipelines, image/table handling and metadata quality.
AKS/platform CSA
Size and operate the processor/orchestration services.
Search specialist
Design document scoping, filters and retrieval evaluation.

Bring to the session

Documents with difficult tables/images and known comparisons
An analyst-defined entity/filter vocabulary
Corpus permissions and retention requirements

Agree how to judge success

Selected-document scope is respected.
Extracted entities and comparisons match source evidence.
Processing errors and missing content are visible to the reviewer.

First working session

Trace one document from upload through extraction and search, then compare two conflicting sources.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Maintenance notice - public README reviewed 20 September 2026 (opens in a new tab)
Later source-review reference: DKM is no longer maintained. This does not replace the pinned package architecture or establish functional readiness.
Application build and Kubernetes deployment (opens in a new tab)
The script builds the frontend image, applies Kubernetes manifests and restarts frontapp, AI-service and document-processing deployments. This contradicts the architecture guide's App Service description.
Frontend and backend Kubernetes services (opens in a new tab)
The manifest defines services for aiservice, kernelmemory and frontapp, corroborating Kubernetes hosting for the frontend as well as the backend workloads.

Pinned revision 7df8ed33a86dd4f0f9e7417e882039fd38556e59. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Before a new deployment, name a maintenance owner or replacement: the later upstream review says no longer maintained. Retain distinctive comparison work only where it fills a gap; historical selected results are unchanged.

Evaluation context

Selected question-answering and document-comparison scenarios were verified against a limited corpus.

The limited corpus does not establish quality across all document types or languages.
A reviewer must check citations, omissions and conflicts against the source material.

Model capacity and cost

Repeated interactive comparison could fit compatible PTUs. Actual demand and answer quality need separate measurement.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Top pick / Proposed workflow

RFP & contract review

Design evidence-backed review without automating procurement or legal decisions.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A proposed assistant for reviewing requests for proposals, supplier responses and contracts against criteria your team defines. It is not yet an implemented local procurement application.
How it works: The intended workflow takes a document pack and review rubric, locates relevant passages, compares them with the requirements and presents evidence-linked findings or missing information.
Use it for: Give reviewers an organized starting point for consistent assessment instead of a cold read of every page. People retain all procurement, legal and approval decisions.
Example scenario: For a sample bid, locate the evidence for each required deliverable and flag unanswered criteria for the reviewer to investigate—not to make an award automatically.

From input to useful workIllustrative / proposed

RFP + contractInput
EvidenceProcess
Human reviewOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Procurement reviewers, commercial teams and contract specialists
What you get: Agreed review rubric / Proposed evidence-linked findings format / Human-reviewed evaluation plan
Source & ownership: Proposed custom workflow. View source basis

More on fit, scope and evidence

A design for helping reviewers work through bids, proposals or contracts: locating the relevant passages, checking them against criteria agreed in advance, and showing the reviewer the evidence behind each finding. The multi-agent orchestration accelerator has upstream RFP evaluation and contract-compliance packs to study, but this local workflow remains unimplemented and not functionally demonstrated. Those packs do not fix the recorded final-synthesis failure. Human reviewers keep every procurement and legal decision.

What you actually receive

A proposed local workflow, not an implemented application. Upstream MACAE scenario packs provide implementation references, not a verified local deployment.

What it does

Would extract passages from an authorized document pack.
Would compare them against a rubric your team agrees beforehand.
Would present each finding linked to the passage supporting it.
Would leave every decision to a named human reviewer.

What you would gain

Reviewers start from located evidence instead of a cold read of the whole pack.
An agreed rubric makes review consistent between different reviewers.
Missing information surfaces while it can still be requested.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Packs were inspected, but an evidence-backed RFP or contract-review workflow was not implemented or verified.

Choose this if

You want to scope a reviewer-assistance pilot and can define the rubric.
Your reviewers stay the decision-makers, and an implementation owner can repair and evaluate the complete workflow before use.

Consider something else if

You need a proven procurement application now: the upstream references do not establish one here.
Your documents arrive as structured intake packs: assess Content Processing, whose full happy path still needs work.

01 / Use it for the right job

Where it earns its place.

A proposed local workflow for extracting and reviewing authorized RFP or contract material against an agreed rubric; it is not implemented or functionally demonstrated here. Upstream MACAE includes RFP evaluation and contract-compliance scenario packs that can inform implementation. Their existence does not verify this local workflow or resolve the recorded final-synthesis failure. Extraction, retrieval, findings and reviewer disposition below remain proposed components.

Best uses

Define a reviewer-assistance pilot for summarizing an authorized document pack.
Explore evidence-backed identification of missing information and clauses requiring specialist review.

Know the boundary

This local workflow remains proposed and not implemented; upstream scenario packs are implementation references, not deployment or functional proof.
No automatic award decision, legal advice, compliance approval or contract execution.
Neither the generic extraction guidance nor the upstream pack references establish a locally implemented scoring, redlining or approval experience. The recorded MACAE final-synthesis failure still requires remediation.

Experience and implementation to confirm

Proposed reviewer workspace for inspecting source passages and draft findings. No bespoke document-upload, redlining, scoring or approval interface is established.

Agree the review scope
Choose permitted documents, authoritative guidance and a reviewer-owned rubric.
Design evidence-linked findings
Specify how summaries and potential issues must reference source passages and expose uncertainty.
Adjudicate with a reviewer
Have authorized specialists confirm findings and record decisions in the existing business process.

02 / Under the hood

Components and how they connect.

Proposed extraction, retrieval and reviewer-assistance design. Upstream scenario packs are references; no local implementation is verified.

Proposed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Review documents + rubric
Authorized input pack
Proposed inputs selected by the accountable reviewer.
Document extraction
Proposed Document Intelligence
Generic extraction option; document structure and provenance require validation.
Evidence retrieval
Proposed Azure AI Search / optional
Optional implementation choice for permission-aware retrieval.
Reviewer workspace
Proposed application
Would display draft findings and supporting passages; no existing UI is established.
Review assistance
Proposed application logic
Would apply the agreed rubric and separate missing evidence from possible issues.
Drafting and analysis
Proposed model integration
Would generate reviewable findings; provider compatibility remains to be confirmed.
Final disposition
Authorized reviewer
Human decisions remain in the approved procurement or legal process.

Read all 6 connections

Review documents + rubric to Document extraction
Extract permitted evidence
Document extraction to Evidence retrieval
Proposed indexing
Reviewer workspace to Review assistance
Submit bounded review task
Review assistance to Evidence retrieval
Retrieve supporting passages
Review assistance to Drafting and analysis
Draft evidence-linked findings
Reviewer workspace to Final disposition
Review and adjudicate

All application-specific components are proposed.
Generic document-extraction guidance does not verify RFP analysis, legal assessment or approval functionality.

03 / Prepare the inputs

From your data to useful output.

Proposed: authorized RFP/contract documents, authoritative policy guidance and a review rubric.

Preserve document structure
Evaluate extraction of text, headings and tables while retaining document and section provenance.
Design retrieval
Propose an access-controlled evidence collection with separate document versions and clear source references.
Prepare reviewer findings
Define draft summaries, possible issues and missing-evidence outputs; implementation remains to be selected or built.

Missing information must remain distinct from noncompliance; require source evidence for every material finding.

04 / Run it in your environment

What you need to get running.

Select or build an implementation after approving the review design. No verified scenario install command is available.

Code & access

Repository not verified for this catalog entry. Use the platform or custom-implementation path below, not a standalone app installer.

Your team needs

Accountable procurement/legal reviewer and an agreed rubric
Permitted documents and authoritative guidance
Reviewed implementation, identity design and evidence-retention requirements
If selecting MACAE, review model-deployment resources and persisted agent model selections; verify the actual approved endpoint rather than assuming Foundry-project reuse means PTU reuse. Existing-project paths can still deploy GlobalStandard models.
Remediation and end-to-end evaluation of final synthesis before treating a MACAE-based workflow as usable

Bring approved inputs

Proposed: authorized RFP/contract documents, authoritative policy guidance and a review rubric.

Budget separately for

Custom integration and evaluation effort
Selected extraction, retrieval and model services
Reviewer time and approved hosting

No deployment commands run from this site.

Custom implementation required

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. A complete installation runbook is not yet available; follow the access or implementation path below.

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Agree the review contract
Choose RFP evaluation or contract compliance, appoint the human decision-maker and define required evidence, scoring limits and prohibited automated decisions. Create a synthetic reference set with expected findings.
Select the implementation base
Review the separately pinned MACAE RFP and contract packs in Code & sources. If choosing MACAE, use solution 2's deployment walkthrough for its base runtime; pack availability is not a working RFP application.
Reconcile the package versions
The reviewed content packs and base application have different pins. An engineer must verify their schemas, dependencies and model selections together, record a compatible revision/overlay and supply the actual initialization commands. Do not copy a newer pack blindly into the older runtime.
Implement evidence and reviewer controls
Configure approved extraction/retrieval, document versions, authorized access and source-linked findings. Add the reviewer workflow and retention controls. Remediate the known final-synthesis failure before acceptance.
Publish a reproducible runbook
Record the chosen revision, tools, parameters, deployment and data-loading commands, sign-in setup, expected outputs and recovery procedure. Reproduce it in a clean approved environment before offering self-service deployment.

Verify before sharing

A reviewer checks final synthesis, material findings, missing evidence and false positives against the reference set. Until the integration and runbook exist, this remains a proposed workflow rather than an installable package.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Procurement/legal specialist
Own the rubric, materiality and final decisions.
Document/search specialist
Design extraction, provenance and authorized retrieval.
Application architect
Select or build the implementation and review its deployment requirements.

Bring to the session

Authorized review pack
Authoritative policy set and reviewer rubric
Known material findings and decision-record process

Agree how to judge success

Every material finding is traceable to evidence.
Missing information is distinct from noncompliance.
Only an authorized person records the final business or legal decision.

First working session

Trace one proposed finding from source passage to reviewer disposition before selecting or building the workflow.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Generic document extraction and RAG guidance - not an RFP package (opens in a new tab)
Upstream MACAE RFP evaluation pack - implementation reference (opens in a new tab)
Separately pinned source review dated 20 September 2026. Pack availability is not a local implementation, successful final synthesis or functional test.
Upstream MACAE contract-compliance pack - implementation reference (opens in a new tab)
Separately pinned source review dated 20 September 2026. Pack availability does not establish procurement automation or change the proposed local workflow status.

Platform references explain the integration or design option only; they do not verify a portfolio-specific package.

Deployment notes & implementation considerations

Package and integration

Define an evidence-linked review rubric and build a bounded reviewer-led demonstration.

Evaluation context

Packs were inspected, but an evidence-backed RFP or contract-review workflow was not implemented or verified.

This is a proposed workflow, not a deployed procurement product.
Review support must not be presented as automatic legal advice, compliance approval or an award decision.

Model capacity and cost

Recurring, interactive review may fit compatible capacity after quality and actual volume are established. Batch remains valid for deferred analysis.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Top pick / Application accelerator

Modernize

Translate Informix SQL, then verify it against the target engine.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A conversion assistant for moving database code from Informix SQL to the SQL Server dialect, T-SQL. It is not a general-purpose application or programming-language migration tool.
How it works: Upload a batch of SQL. The application drafts conversions, checks the generated syntax with a parser, reviews meaning, attempts repairs and exports the results with a processing summary.
Use it for: Give database engineers a reviewable first pass instead of translating every script by hand. Behavioral testing and a maintenance owner are required; upstream is no longer maintained.
Example scenario: Convert a small set of reporting queries, run the originals and drafts against equivalent test data, and compare the results before accepting the changes.

From input to useful workIllustrative

Legacy codeInput
Plan changesProcess
Review + testOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Data platform engineers, database specialists and modernization teams
What you get: Translated SQL drafts / Processing and validation summaries / Exportable conversion artifacts
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A conversion assistant for one specific database migration: Informix SQL into T-SQL, the dialect SQL Server uses. You upload a batch of SQL; it translates, checks the result against a real T-SQL parser, reviews the meaning and lets you export the drafts for your engineers to test properly. It is not a general "migrate anything" tool.

What you actually receive

A SQL-dialect conversion application whose upstream is no longer maintained. A named maintenance owner or approved replacement is required before a new deployment.

What it does

Converts a batch of Informix SQL into T-SQL drafts.
Checks the generated syntax with a parser, not only a model opinion.
Reviews each translation for meaning and attempts repairs.
Exports the drafts and a processing summary for independent testing.

What you would gain

The tedious first pass of a migration is drafted in bulk, leaving engineers the judgement work.
A parser check catches broken syntax before an engineer spends time on it.
Progress becomes countable across a batch instead of tracked file by file.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: A selected modernization workflow was verified. This does not demonstrate full behavioral equivalence between source and target systems.

Choose this if

You are moving Informix SQL to SQL Server and want reviewable drafts at volume.
A named owner will maintain the implementation and your engineers will test the output against the target database themselves.

Consider something else if

Your dialect is not Informix, or the job is SAS or whole-application migration: this package does not establish those.
You need ongoing upstream maintenance: select an approved maintained SQL-conversion alternative rather than assuming this package is supported.
You want a system described rather than its code converted: see SpecSuite, subject to its open questions.

01 / Use it for the right job

Where it earns its place.

The shipped web experience converts Informix SQL to T-SQL through a multi-agent migration, selection, repair and validation workflow. Validation includes a T-SQL parser as well as model-assisted semantic review. Engineers inspect and export generated SQL for independent target-engine tests. Other dialects or non-SQL scenarios require explicit adaptation; this is not a verified SAS or whole-application migration engine.

Best uses

Assess a representative batch of Informix SQL for conversion to T-SQL.
Create reviewable conversion drafts before a database migration workstream.

Know the boundary

Parser-backed syntax checks and model-assisted semantic review do not prove target-engine execution or behavioral equivalence.
Other dialects and non-SQL conversions require explicit customization; SAS program, macro or DATA-step modernization is not established by this package.
Database schema migration, application changes, performance tuning and production cutover remain separate workstreams.

How people use it

A batch-oriented conversion application with Informix as the shipped source option and T-SQL as the target option. Engineers upload inputs, follow processing, inspect generated SQL and export results. The backend is configurable, but that does not establish a ready-made dialect matrix.

Choose an Informix query set
Select representative SQL files for the shipped Informix-to-T-SQL scenario.
Translate and inspect
Review migration candidates, repair activity, parser-backed syntax checks and semantic-review feedback.
Export for engineering checks
Execute proposed T-SQL against controlled target-engine fixtures and assess semantics and performance independently.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

SQL files are the input, not a live production database. The conversion application calls models and stores artifacts; target-engine acceptance is an engineering step outside the accelerator.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Source SQL files
Authorized query corpus
Input queries and dialect context for a bounded conversion batch.
SQL and artifacts
Azure Blob Storage
Stores source queries and generated outputs.
Conversion workspace
Web / Container Apps
Selects inputs and dialect; shows progress, summaries and export.
Conversion orchestration
Container Apps
Coordinates translation and validation agents for the chosen SQL scenario.
Model-assisted conversion
Microsoft Foundry
Produces migration candidates, repair suggestions and semantic-review feedback; the runtime also invokes a separate T-SQL syntax parser.
Processing results
Azure Cosmos DB
Tracks batch metadata and results.
Target-engine tests
Customer test environment / optional
Proposed acceptance integration: execute on controlled fixtures and compare behavior/performance.

Read all 6 connections

Source SQL files to SQL and artifacts
Stage query files
Conversion workspace to Conversion orchestration
Select batch and dialect
Conversion orchestration to SQL and artifacts
Read source / save output
Conversion orchestration to Model-assisted conversion
Convert and review SQL
Conversion orchestration to Processing results
Persist processing results
Conversion workspace to Target-engine tests
Export for independent tests

The dashed target-engine component is a recommended acceptance step, not a claim that the package provisions or migrates a database.
The shipped UI offers Informix and T-SQL. Additional dialects or non-SQL workflows need deliberate adaptation.
The syntax-checker plugin invokes a T-SQL parser; this is not target-database execution or proof of semantic equivalence.

03 / Prepare the inputs

From your data to useful output.

Authorized Informix SQL files for the shipped T-SQL conversion scenario; remove secrets and production data from the test corpus.

Stage source SQL
Store selected query files in Blob Storage with enough context to interpret the conversion task.
Run conversion jobs
The application coordinates model-assisted translation/validation and tracks processing state.
Persist and export results
Blob holds SQL/artifacts and Cosmos DB stores processing metadata/results for the application.

Include null handling, date arithmetic, joins, aggregates and unsupported constructs in target-engine regression checks.

04 / Run it in your environment

What you need to get running.

Bicep/azd provisioning, then the package ACR image build/push step.

Code & access

Your team needs

Named maintenance owner or approved replacement for this no-longer-maintained accelerator before any new deployment
Source/target SQL dialect and a representative query corpus
A controlled target-engine fixture and regression assertions
Foundry models, Container Apps, Blob, Cosmos DB and registry access

Bring approved inputs

Authorized Informix SQL files for the shipped T-SQL conversion scenario; remove secrets and production data from the test corpus.

Budget separately for

Translation and validation model turns
Container Apps and image registry
Blob/Cosmos DB plus the separate target-engine test environment

No deployment commands run from this site.

Azure application - maintenance gate

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Modernize-your-code-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach 7592ea97550fb711d7d8b64186875967d574c5d5
git rev-parse HEAD

Resolve maintenance and conversion scope
Require a maintenance owner or supported replacement. This package converts Informix SQL to T-SQL, not arbitrary application languages. Prepare the guide's tooling and an isolated test database.
Configure and provision
Review infra\main.parameters.json, model deployment, hosting and network requirements. Select the approved subscription and a fresh environment.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Install application images
From the repository root, run the separate ACR image installation stage; provisioning only prints this next step.
Show commands
```
.\scripts\build_and_push_images.ps1
```
Require sign-in
Complete AddAuthentication.md from the pinned deployment guide. Open the frontend Container App Application URI and verify authorized sign-in before uploading source.
Convert a sample batch
Start with permitted files under data\informix. Upload, select Start Processing, inspect batch status and download the translated files and reports using Download all as .zip.

Verify before sharing

Review the SQL and execute representative original/translated queries on isolated test data. Compare results and error behavior; generated syntax alone does not establish behavioral equivalence.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Database modernization specialist
Assess dialect compatibility, unsupported constructs and migration scope.
AI application CSA
Tune the conversion workflow and evaluate error handling.
Database/application owner
Define equivalence, performance and rollback criteria.

Bring to the session

Representative SQL with difficult edge cases
Target-engine version and test fixtures
Known source outputs and performance constraints

Agree how to judge success

Results match expected semantics on controlled fixtures.
Unsupported conversions are flagged rather than silently accepted.
Performance and cutover requirements are assessed separately from translation quality.

First working session

Convert a small, representative query set and compare generated output against target-engine execution.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Maintenance notice - public README reviewed 20 September 2026 (opens in a new tab)
Later source-review reference: Modernize Your Code is no longer maintained. This does not replace the pinned package architecture or establish functional readiness.
Shipped source and target options (opens in a new tab)
The UI shows Informix as the source option and T-SQL as the target option. A broader ready-made dialect matrix or SAS workflow is not established.
Parser-backed T-SQL validation (opens in a new tab)
The syntax-checking tool invokes the T-SQL parser. Syntax checking is not target-database execution or proof of semantic equivalence.
Adapting the conversion workflow (opens in a new tab)
Describes engineering changes required for another conversion scenario, including agents, prompts, API integration and validation.

Pinned revision 7592ea97550fb711d7d8b64186875967d574c5d5. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Require a maintenance owner or supported replacement before deployment; upstream now says no longer maintained. Demonstrate a small SQL conversion with source/target execution tests, rollback and known limitations.

Evaluation context

A selected modernization workflow was verified. This does not demonstrate full behavioral equivalence between source and target systems.

Engineers must review generated changes and run regression tests.
Do not infer a complete migration, compatibility guarantee or automatic production approval.

Model capacity and cost

Repeated model-assisted engineering work could use compatible PTUs. Measure realistic usage rather than assuming continuous load.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Top pick / Owner-led offering

SpecSuite

Understand existing code, recover its specifications and use them to guide better code.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A private code-to-spec and spec-to-code tool for understanding and evolving existing or legacy software, designed to work across programming languages.
How it works: Analyzes a codebase into specifications and a knowledge graph: a connected map of behavior, components and dependencies. Engineers use the reviewed specifications to generate or improve code.
Use it for: Understand unfamiliar systems, recover business rules, plan modernization and guide code changes. Confirm language and framework coverage on your own code rather than assuming universal support.
Example scenario: Take an inherited billing module, map its rules and dependencies, review the specification, then use it to guide an improved implementation and regression tests.

From input to useful workIllustrative / proposed

Existing codeInput
Specs + graphProcess
Code changesOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Software architects, requirements engineers and application owners
What you get: Draft system specifications / A knowledge graph of behavior and component relationships / Proposed code changes guided by reviewed specifications
Source & ownership: Private owner-led solution. View source basis

More on fit, scope and evidence

SpecSuite connects code-to-spec and spec-to-code work. Starting with an existing or legacy codebase, it is designed to recover specifications and build a knowledge graph: a connected map of what the software does and how its components relate. Engineers can use that understanding to explain the system, improve its design, plan modernization and generate revised code from reviewed specifications. The offering is described as language-spanning; the actual languages, frameworks and repository size must be checked in an owner-led pilot. The code is private, and we can coordinate access or an approved handoff. This product description does not change the historical testing status.

What you actually receive

Private code through an owner-approved access or delivery arrangement; confirm the supported package before deployment.

What it does

Analyzes authorized existing or legacy source code to recover behavior, business rules and specifications.
Connects that understanding in a knowledge graph so engineers can explore components and dependencies.
Uses reviewed specifications to guide code generation, improvements and application modernization.
Keeps engineers responsible for checking the recovered understanding and testing generated changes.

What you would gain

Engineers can understand an inherited application without starting every investigation by reading the entire codebase.
Specifications and connected knowledge provide a shared baseline for handover, design discussions and change planning.
Modernization can start from reviewed behavior and requirements, not just a line-by-line code translation.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: This portfolio carries forward existing owner validation. SpecSuite was not retested in this evaluation.

Choose this if

You own a system whose documented behaviour has drifted from its code.
You want to carry recovered system knowledge into improved code or a modernization effort, with engineers reviewing both directions.

Consider something else if

You want Informix SQL-to-T-SQL conversion drafts rather than specifications: assess Modernize only with a maintenance owner or approved replacement; it is not arbitrary code migration.
You need a public self-service download or guaranteed coverage of every language: arrange private access and confirm supported inputs with the owner first.

01 / Use it for the right job

Where it earns its place.

The supplied product description connects code-to-spec with spec-to-code: analyze an existing or legacy codebase, recover specifications, connect the findings in a knowledge graph and use that reviewed understanding for improved implementations or modernization. It is designed for code across programming languages; actual language, framework and repository coverage need confirmation on the selected package. Private access can be coordinated with the owner. The diagram is a conceptual workflow, not independently verified runtime architecture.

Best uses

Recover the behavior, rules and dependencies of an inherited application.
Use connected specifications to explain the system, plan changes and onboard engineers.
Guide improved code or modernization from specifications that engineers have reviewed.

Know the boundary

Cross-language design is not verified support for every language, framework or repository size; confirm coverage with the owner and a representative module.
Recovered specifications and graph relationships can be incomplete or incorrect; engineers must check them against source and behavior.
Generated code requires review and regression testing; this is not automatic equivalence or migration approval.
The supplied product description does not upgrade the historical testing status or verify the package architecture.

Experience and implementation to confirm

The workflow centers on inspecting a codebase, reviewing specifications and connected system knowledge, then working with proposed code changes. Confirm the actual CLI, editor or web interface, graph exploration and export options in an owner-led walkthrough; no specific interface is asserted here.

Choose a bounded codebase
Select an authorized revision and a module whose behavior engineers can independently check.
Recover and connect knowledge
Analyze the code into draft specifications and a knowledge graph, then inspect the recovered rules and dependencies.
Review the desired change
Correct the specifications and agree the intended behavior before using them to guide code generation or modernization.
Generate, inspect and test
Review the proposed implementation, run regression tests and compare it with the accepted specification before merging anything.

02 / Under the hood

Components and how they connect.

Conceptual code-to-spec and spec-to-code workflow based on the supplied product description. Runtime services, graph storage, model route and deployment topology require owner confirmation.

Proposed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Existing codebase
Authorized source revision
The legacy or current code to understand; language and framework coverage must be checked.
Code-to-spec analysis
SpecSuite / runtime to confirm
Recovers a draft description of behavior, rules and components from the selected code.
Specifications
Engineer-reviewed behavior
Engineers check recovered behavior and define the desired changes before code generation.
Knowledge graph
Connected system knowledge
Connects components, rules and dependencies to support understanding and change planning; storage technology is unconfirmed.
Spec-to-code changes
Review + regression tests
Proposed improved or modernized code, checked against accepted specifications before use.

Read all 5 connections

Existing codebase to Code-to-spec analysis
Analyze permitted source
Code-to-spec analysis to Specifications
Recover draft specifications
Specifications to Knowledge graph
Connect reviewed understanding
Specifications to Spec-to-code changes
Guide implementation from specs
Knowledge graph to Spec-to-code changes
Inform dependencies and change scope

This is a functional reference design, not a claim about confirmed services or automatic end-to-end success.
General Container Apps documentation is only a possible hosting reference; it does not establish SpecSuite features or dependencies.

03 / Prepare the inputs

From your data to useful output.

An authorized existing or legacy codebase, the engineering questions to answer, and reviewed specifications for the intended change.

Control source access
Choose a specific revision and define exclusions for secrets and restricted files before analysis.
Check specifications and graph
Compare the recovered behavior, component relationships and file coverage with the actual source; make gaps explicit.
Control the return to code
Keep generated specifications, approved specifications and proposed code changes distinct, with revision provenance and engineer review.

Evaluate both directions: source-to-specification and graph accuracy, then specification-to-code behavior. Require regression tests rather than accepting a plausible explanation or successful generation alone.

04 / Run it in your environment

What you need to get running.

Owner-led package review before choosing a deployment route. No verified public install command is available.

Code & access

SpecSuite code is private. We can work with you and the owner to arrange repository access or an approved code handoff. Access, licensing and delivery depend on owner approval; confirm the supported package and deployment guide before installation.

Your team needs

Owner-approved package, revision, license and support contact
Actual runtime/dependency and model-provider requirements
Authorized source repository and acceptance rubric

Bring approved inputs

An authorized existing or legacy codebase, the engineering questions to answer, and reviewed specifications for the intended change.

Budget separately for

Model and analysis compute after package confirmation
Confirmed knowledge-graph/artifact storage and hosting
Engineering review of specifications, graph relationships and generated code

No deployment commands run from this site.

Private package - access required

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. A complete installation runbook is not yet available; follow the access or implementation path below.

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Request the approved package
Ask the program team to coordinate owner-approved repository access or a code handoff for SpecSuite. Obtain the revision, license, support owner and a real product walkthrough.
Obtain the missing installation runbook
The owner must supply tool versions, dependency restore instructions, configuration names, graph/storage initialization, deployment commands, authentication setup and upgrade/rollback steps. These are not verified publicly; stop here until supplied.
Review the target design
Confirm supported languages/frameworks, model endpoints, knowledge-graph hosting, data retention, identity and network requirements with the owner. Approve costs and source-code access before installation.
Install with the owner
Follow the supplied revision-specific runbook in the approved environment. Record commands, configuration and outputs without credentials; require a clean-environment reproduction before describing it as self-service.
Load one permitted module
Run code-to-spec, inspect graph relationships and generated specifications, then scope one spec-to-code change. Keep generated changes on a review branch.

Verify before sharing

The owner demonstrates sign-in, code ingestion, graph/specification output and a reviewed generated change passing the project's regression checks. Until then, this is an access-and-validation path, not full deployment instructions.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Application-modernization CSA
Define the understanding or modernization outcome and the permitted change scope.
SpecSuite owner
Demonstrate both directions of the workflow and confirm package, language coverage and deployment requirements.
Software architect
Check recovered rules, graph relationships and code behavior against source and tests.

Bring to the session

A small authorized repository and its language/framework inventory
A target specification and one bounded desired change
Regression tests plus the package owner and supported distribution

Agree how to judge success

Material specification claims and graph relationships can be checked against the source.
Unsupported inputs and missing analysis are explicit.
Generated changes pass agreed behavioral and regression tests before acceptance.

First working session

Walk one inherited module from code to reviewed specifications and knowledge graph, then use an approved specification change to guide a tested implementation.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Container hosting reference (not SpecSuite documentation) (opens in a new tab)

Platform references explain the integration or design option only; they do not verify a portfolio-specific package.

Deployment notes & implementation considerations

Package and integration

Arrange private package access, confirm language and framework coverage, then evaluate code-to-spec, knowledge-graph accuracy and spec-to-code changes on one permitted module.

Evaluation context

This portfolio carries forward existing owner validation. SpecSuite was not retested in this evaluation.

Any demonstration is conditional on confirmed ownership and support.
Prior validation is not evidence of current integration or production readiness.

Model capacity and cost

Potential model usage depends on the confirmed package, supported integration and compatible deployment.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Developer kit / platform integration

Employee Self-Service

Customize employee assistance around approved HR and IT workflows.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A toolkit for the people who build employee-help assistants in Microsoft Copilot Studio. Installing the kit does not itself create or license a working staff chatbot.
How it works: Makers prepare answer topics and templates, configure approved HR or IT connections, test employee journeys with evaluation material and synchronize approved changes through the platform.
Use it for: Maintain employee-service answers through a repeatable build-and-test process rather than editing them directly in front of staff. Platform permissions, licensing and model billing are separate decisions.
Example scenario: Build a password-help topic, test whether it gives the approved instructions for common employee questions, then publish the reviewed change to the employee agent.

From input to useful workIllustrative

ToolkitInput
ConfigureProcess
AssistantOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: HR/IT service owners, Copilot Studio makers and Power Platform administrators
What you get: Reviewed topic and integration configuration / An evaluation set for the selected employee journey / A documented deployment-readiness and licensing review
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A kit for the makers who build and maintain an employee help agent in Microsoft Copilot Studio. It helps them prepare answer topics, connect approved HR and IT systems, and test the result before publishing. The employee-facing agent is set up and licensed separately; installing this kit does not create it.

What you actually receive

A toolkit for the people who build a Copilot Studio agent. It is not itself a deployable chatbot.

What it does

Gives makers a prepared workspace for building topics and templates.
Supports configuration of approved employee-service integrations.
Provides evaluation material for testing a journey before release.
Synchronises approved changes through the platform.

What you would gain

Changes to employee answers are tested before staff ever see them.
HR and IT knowledge is maintained deliberately instead of edited live.
Makers work to a structured method rather than inventing conventions per change.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: No tested ESS integration establishes a provisioned model path in this portfolio.

Choose this if

You already run, or plan to run, an employee agent in Copilot Studio.
Your Power Platform administrators are involved from the start.

Consider something else if

You want a standalone assistant hosted in your own Azure environment: this is not that.
You are assuming reserved model capacity will serve it: that routing is not established here.

01 / Use it for the right job

Where it earns its place.

The pinned repository is a maker and validation toolkit for an Employee Self-Service agent in Copilot Studio, not a standalone Azure chatbot. Makers use GitHub Copilot in VS Code to prepare topics, templates, flows and evaluations, then synchronize approved changes through Dataverse. The employee-facing agent and enterprise connections require separate platform setup.

Best uses

Adapt policy answers, routing and handoff topics for an existing ESS agent.
Configure and evaluate authorized Workday, ServiceNow or other employee-service integrations.

Know the boundary

The public kit is an example/learning tool, not a supported Microsoft product or a service entitlement.
Installing the maker kit does not deploy or license the employee-facing ESS agent, and does not establish customer-managed Azure OpenAI/PTU routing.

How people use it

Makers work in the specific ess-maker-skills VS Code workspace, not the repository root. Employees use the separately configured Copilot Studio agent in an approved channel; the kit itself is not that employee interface.

Choose one employee journey
Agree the permitted answer or transaction, identity checks and human handoff.
Prepare and review changes
Generate or edit topic YAML, template configurations, adaptive cards and relevant flows; inspect the dry-run diff.
Publish through the platform process
Push approved components through Dataverse, evaluate in the authorized environment and validate the employee channel before release.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Separate authoring and employee runtime paths: the kit edits platform components; Copilot Studio and enterprise connectors deliver the actual service.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Maker workspace
VS Code + GitHub Copilot
Generates and reviews topic/configuration changes and evaluations.
Agent configuration
Dataverse MCP / API
Reads components and synchronizes approved changes to the Power Platform environment.
Employee channel
Configured ESS experience
Uses the separately deployed agent under an approved user identity.
Employee-service agent
Copilot Studio
Runs configured topics, knowledge, routing and handoff.
Authorized business actions
Power Automate / connectors
Connects to HR/IT systems with reviewed permissions and connector licensing.

Read all 4 connections

Maker workspace to Agent configuration
Review + synchronize components
Agent configuration to Employee-service agent
Agent configuration
Employee channel to Employee-service agent
Employee request
Employee-service agent to Authorized business actions
Authorized retrieval / action

The maker Copilot subscription and employee runtime entitlements are different concerns.
FlightCheck reports readiness risks; it does not certify production suitability or grant licenses.

03 / Prepare the inputs

From your data to useful output.

An existing ESS agent, approved policies, topic/configuration samples and authorized enterprise connectors.

Connect the maker workspace
An administrator enables Dataverse MCP and permits the Microsoft GitHub Copilot client; the maker authenticates to the approved environment.
Prepare agent components
Work from a local working copy of topics and configuration, with checkpoints and reviewable changes.
Connect business systems
Configure permitted ServiceNow/Workday templates and shared flows, or separately reviewed custom flows and connection references.

Test employee versus manager permissions, sensitive-topic escalation, connector failures and unintended data updates with synthetic records.

04 / Run it in your environment

What you need to get running.

Prepare the authorized Copilot Studio/ESS environment first, then set up the pinned maker workspace and follow its review/push workflow.

Code & access

Your team needs

ESS availability and runtime licensing confirmed with the account team; an ESS agent already deployed in an approved Power Platform environment
VS Code, active GitHub Copilot subscription for the documented maker experience, and Dataverse MCP with the permitted client
Platform administrators, DLP/connector policies, source-system access and employee-channel permissions

Bring approved inputs

An existing ESS agent, approved policies, topic/configuration samples and authorized enterprise connectors.

Budget separately for

GitHub Copilot maker subscription and optional Codespaces usage
Copilot Studio / Microsoft 365 runtime entitlement or consumption as applicable
Power Automate premium/custom connector licensing where applicable, source-system licenses and administration

No deployment commands run from this site.

Copilot Studio customization kit

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Employee-Self-Service-Agent-Developer-Kit.git accelerator
Set-Location accelerator
git checkout --detach 3236a513b7312b13602326fbdf7778797174d45f
git rev-parse HEAD

Confirm platform access and licensing
Obtain the required ESS/Copilot Studio entitlements, a permitted Dataverse environment and an existing agent or approved agent-creation path. This kit customizes agents; installing developer tools does not deploy an ESS service.
Set up the pinned maker workspace
Use setup\README.md for the tool/dependency prerequisites and open solutions\ess-maker-skills in VS Code. Review installer telemetry and feed settings. Avoid the one-line bootstrap against main; it can replace the reviewed checkout with a newer revision.
Connect and check prerequisites
In the maker workspace, run /setup in Copilot Chat, sign in and select the intended Dataverse environment/agent. Run FlightCheck and resolve licensing, permission and configuration failures before pushing changes.
Show commands
```
python scripts\flightcheck\cli.py --scope full
```
Customize a bounded topic
Use the maker guide to pull the agent and create a checkpoint. Generate or edit one topic/workflow locally, run its error scan and inspect the dry-run diff. Keep connection credentials out of generated files.
Push, verify and publish deliberately
Push only the reviewed changes to the selected development agent using the kit's documented workflow. Test in Copilot Studio, complete connection/consent configuration and publish only after the environment owner approves the intended channel and audience.

Verify before sharing

An authorized employee completes the selected task and an unauthorized identity is denied. Confirm licensing and service billing separately: Copilot Studio usage does not demonstrate Azure OpenAI PTU consumption.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Power Platform specialist
Review ESS setup, Dataverse, DLP and release management.
HR/IT process owner
Own answer quality, transaction scope and sensitive-case escalation.
Licensing/identity specialist
Confirm maker versus runtime entitlements and per-user connector access.

Bring to the session

One approved employee journey and escalation owner
An ESS-enabled environment and administrator-approved connector plan
Synthetic employee/manager test cases and a licensing inventory

Agree how to judge success

The employee sees only authorized information and actions.
Readiness warnings, telemetry choices and licensing obligations are resolved or explicitly recorded.
Human escalation and rollback are demonstrated before broader release.

First working session

Review one topic from maker diff through the employee channel. Ask the Microsoft account team about ESS access and specialist assistance; neither availability nor no-cost support is guaranteed.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
ESS platform architecture and access (opens in a new tab)
Separates the Copilot Studio employee runtime from the maker kit; access availability should be confirmed through the account team.
Maker workspace setup and release workflow (opens in a new tab)

Pinned revision 3236a513b7312b13602326fbdf7778797174d45f. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Choose and test the model route, permissions and billing boundary for one staff-service scenario.

Evaluation context

No tested ESS integration establishes a provisioned model path in this portfolio.

A custom-model integration and a Copilot Studio solution are different implementation and billing choices.
Do not assume Copilot Studio billing consumes existing PTUs.

Model capacity and cost

A compatible custom-model path could use PTUs. Copilot Studio usage has its own billing considerations and must be checked separately.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Reference accelerator

Real-time voice agents

Hold a spoken conversation with a caller, then hand off cleanly to a person.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: An engineering codebase for building assistants that speak with callers over a telephone or browser. It includes call and audio handling, unlike a speech service alone.
How it works: Connects the call, streams speech, coordinates tools and conversation, handles interruptions and provides a route to hand off to a person. Your team supplies the business logic.
Use it for: Build a bounded spoken service journey without starting the real-time communication infrastructure from scratch. Telephony, speech and hosting have separate costs and require operational ownership.
Example scenario: Prototype a caller asking a routine service question, then requesting a human; evaluate the spoken answer, interruption behavior and transfer in an approved test environment.

From input to useful workIllustrative

Live audioInput
Agent toolsProcess
ResponseOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Contact-centre and service-delivery owners, real-time application engineers and AI application architects
What you get: A working voice conversation spine / Measured turn latency for one scenario / A documented escalation and failure path
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

The working parts of a spoken agent that answers a phone call or a browser conversation: taking the call, streaming audio both ways, knowing when the caller has stopped speaking, and passing the conversation to a person when it should not continue. The agent’s actual business logic is yours to write. The package describes itself as covering roughly the first eighty per cent of the work.

What you actually receive

An engineering codebase teams build on. It is not a finished application.

What it does

Connects a call arriving from a telephone number or a browser.
Streams audio in both directions while the conversation is happening.
Manages turn taking and interruption.
Offers two audio approaches behind one switch: separate speech steps, or a single managed voice-to-voice service.
Provides a documented route for handing the caller to a person.

What you would gain

The hardest engineering in a voice agent, real-time audio and turn taking, is already solved, so the team works on the conversation.
Two audio paths behind one switch mean the latency and control trade-off can be measured rather than argued.
A clean handoff to a person is designed in, rather than added after the first bad call.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: This candidate was added by source review of the pinned public package. No deployment, call or model request was performed for it, so there is no functional result to report.

Choose this if

Callers must speak to something immediately, and routine enquiries dominate the volume.
You have engineers who will own a real-time service, including how it fails.

Consider something else if

You only need speech added to one bounded workflow: Voice Live is a much smaller step.
You cannot fund telephony numbers, real-time speech and always-on hosting: none of them are free.

01 / Use it for the right job

Where it earns its place.

A code-first accelerator for real-time voice agents. It supplies the telephony, streaming and orchestration plumbing so a team can focus on the agent logic. Two interchangeable audio paths are documented: a pipeline that separates speech recognition, reasoning and speech synthesis, and a single managed voice-to-voice service. The package describes itself as an accelerator that covers roughly the first eighty per cent of the work; hardening, security posture and release engineering remain the adopting team’s responsibility.

Best uses

Answer a narrow set of routine spoken enquiries and transfer anything else to a person.
Compare a separated speech pipeline against a managed voice-to-voice path for latency and control.

Know the boundary

This catalog entry is based on source review at a pinned revision. Nothing was deployed and no call was placed, so no latency, accuracy or reliability figure is claimed here.
Published latency figures are the package’s own characterisation, not an independently reproduced measurement.
Spoken interaction raises consent, recording, retention and accessibility obligations that the package does not decide for you.
Telephony numbers, real-time speech capacity and always-on hosting are separate recurring costs from any reserved model capacity.

How people use it

Engineers work from a repository: a browser client for testing, a streaming backend service, and a mode switch that selects the separated speech pipeline or the managed voice-to-voice path. Reference implementations for several regulated industries are included as starting points.

Choose one narrow call intent
Pick a single, high-volume, low-risk enquiry with a known correct answer and an obvious escalation route.
Select an audio path
Decide between the separated recognition-reasoning-synthesis pipeline for control, or the managed voice-to-voice service for lower latency and faster setup.
Measure a real conversation
Test interruption handling, silence, accents, background noise and transfer to a person, then record where it failed.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Telephony, streaming middleware, speech, reasoning and session state are deliberately separable, so one part can be replaced without rebuilding the others.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Caller
Phone or browser
Starts or receives the conversation.
Call and web front door
Azure Communication Services
Handles telephony, call control and two-way media streaming.
Speech recognition and synthesis
Azure AI Speech
Turns speech into text and replies back into audio on the separated pipeline.
Real-time middleware
Streaming application service
Manages the audio stream, turn taking and interruption handling.
Business tools and data
Application-specific services / optional
Proposed integration boundary for permitted lookups and actions.
Agent reasoning
Configured language or voice model
Decides the next reply, either from text or directly from audio.
Session state and history
Cache and document store
Holds live session context and conversation history across turns.

Read all 6 connections

Caller to Call and web front door
Place or receive a call
Call and web front door to Real-time middleware
Stream audio in both directions
Real-time middleware to Speech recognition and synthesis
Transcribe speech and speak the reply
Real-time middleware to Agent reasoning
Request the next response
Agent reasoning to Business tools and data
Look up or act on permitted data
Agent reasoning to Session state and history
Record the conversation turn

The two audio paths are selected by configuration. The separated pipeline gives step-by-step control; the managed voice-to-voice path removes separate recognition and synthesis components.
The reviewed infrastructure definition provisions substantially more than a single application: a cache, a document cluster, a container registry, container and web hosting, configuration, secret storage, monitoring and communication services.
Checked-in model capacity defaults are far larger than an evaluation needs. Review and reduce them before any approved deployment.

03 / Prepare the inputs

From your data to useful output.

Live or recorded speech, the prompts and policies that steer the agent, and whatever business tools it is permitted to call.

Agree the spoken scope
Write down what the agent may answer, what it must refuse, and when it must hand off.
Connect only permitted tools
Expose the minimum set of business lookups and actions, with their own authorization.
Decide the recording position
Establish consent, retention and redaction for audio and transcripts before any pilot call.

Judge it on complete calls with interruptions and accents, not on a clean scripted demonstration.

04 / Run it in your environment

What you need to get running.

A developer-CLI workflow drives Terraform and container builds. Start with browser audio; telephony number acquisition and configuration are separate, optional steps for a phone pilot.

Code & access

Your team needs

Approval and budget for always-on hosting, a cache, a document cluster and a container registry, none of which have a free option
Real-time speech or voice-model availability, quota and region support confirmed for the exact model and API
A separately purchased telephony number, plus consent and recording decisions, before any live call
A Bash-compatible shell with container, Python and Node tooling

Bring approved inputs

Live or recorded speech, the prompts and policies that steer the agent, and whatever business tools it is permitted to call.

Budget separately for

Real-time speech or voice-model usage, billed separately from text capacity
Telephony number rental and per-minute call charges
Cache, document cluster, container registry, container and web hosting
Configuration, secret storage and monitoring services

No deployment commands run from this site.

Voice application - Bash workflow

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/Azure-Samples/art-voice-agent-accelerator.git accelerator
Set-Location accelerator
git checkout --detach a2e1ce2edbf103661c56a861cccef73c30acacee
git rev-parse HEAD

Prepare the full toolchain
Use the linked prerequisites with a Bash-compatible shell (WSL/Git Bash on Windows), Terraform, azd, Azure CLI, containers, Python and Node. Review infra/terraform defaults and all three services in azure.yaml, including cardapi-mcp.
Approve capacity and integration choices
Price and reduce the model/hosting defaults before provisioning. Select the intended speech/reasoning path, identity and network settings. Start with browser audio: a phone number is required only for a separately approved PSTN test.
Deploy from the repository root
In Bash, sign in to both CLIs and select the approved subscription. azd invokes Terraform, provisioning hooks and container deployment; require each service to become healthy.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Open and configure a browser scenario
Open the frontend URL, allow microphone access and use synthetic demo profile data only. In Agent Builder select one agent/template, configure a narrow scenario and expose only approved tools. Review authentication before sharing the endpoint.
Add telephony only if approved
For a phone pilot, follow the separately linked number-setup guide to obtain/configure the ACS number and call/event routing. Number purchase and recurring charges require separate approval; verify consent and human handoff first.

Verify before sharing

Run realistic audio with interruptions, silence, noise and out-of-scope questions. Measure latency and handoff, inspect tool permissions and verify the actual model route. No calls or performance measurements are established by source review.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Contact-centre or service owner
Define the call intents, escalation rules and acceptable failure behaviour.
Real-time application engineer
Own streaming, turn taking, interruption handling and latency budgets.
AI application specialist
Confirm model, API and region compatibility for the chosen audio path.
Privacy and compliance adviser
Decide consent, recording, retention and accessibility obligations.

Bring to the session

One narrow call intent with a known correct answer
Recordings or transcripts representative of real callers, including difficult audio
A decision on consent, recording and retention
An agreed maximum acceptable response delay

Agree how to judge success

The agent hands off to a person whenever it is uncertain or out of scope.
Response delay stays within the agreed threshold on realistic audio, not only on clean speech.
Consent, recording and retention behaviour is implemented and reviewed.
Model, API and region compatibility is confirmed for the exact deployment rather than assumed.

First working session

Run the same call intent through both audio paths and compare response delay, interruption handling and transfer behaviour against an agreed threshold.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Telephony number provisioning (opens in a new tab)
A usable phone number is acquired separately after the infrastructure exists. It carries its own recurring and per-minute charges and is a purchasing decision, not a template setting.
Required tooling and shell (opens in a new tab)
The documented workflow expects a Bash-compatible shell, container tooling and both Python and Node toolchains. Windows users are directed to Git Bash or WSL.

Pinned revision a2e1ce2edbf103661c56a861cccef73c30acacee. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Obtain explicit approval and budget for telephony, real-time speech and container hosting, then measure one bounded call scenario end to end.

Evaluation context

This candidate was added by source review of the pinned public package. No deployment, call or model request was performed for it, so there is no functional result to report.

Source inspection is not a functional test; latency, accuracy and interruption handling remain unmeasured.
A working demonstration requires telephony numbers, real-time speech services and container hosting that are outside the current closed allowances.

Model capacity and cost

The most PTU-relevant candidate in the catalog: the package documents a path that can use a customer-supplied real-time model deployment. Provisioned capacity for real-time voice models, regions and APIs is not interchangeable with text capacity and must be confirmed for the exact model before any sizing claim.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Customer chatbot

Put guided product and policy assistance inside a customer experience.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A customer-facing website assistant, supplied as example storefronts with an embeddable chat widget. The examples use sample product and policy information, not live customer systems.
How it works: A visitor types a question; the application routes it to a product or policy specialist and drafts a response using the configured material. An optional voice path is included.
Use it for: Prototype help with product selection and service-policy questions inside a website. Its grounded-answer test failed here, so repair and reevaluate it before exposing it to customers.
Example scenario: Ask whether a sample product fits a stated need and what its return policy says, then verify both answers against the supplied catalog and policy.

From input to useful workIllustrative

Visitor questionInput
Product + policyProcess
ResponseOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Digital service owners, customer experience teams and web developers
What you get: A scenario host website / An embeddable chat widget and API / Catalog- and policy-grounded conversations
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

An assistant that sits inside a customer-facing website and answers questions about products and policies, passing different kinds of question to different specialists behind the scenes. Example retail, healthcare and banking storefronts are included with sample data; those are demonstrations, not connections to any real ordering or banking system.

What you actually receive

A web application you deploy: an example storefront plus a chat widget that embeds in it.

What it does

Embeds a chat widget into a host website.
Routes each question to a product specialist or a policy specialist.
Answers from the supplied catalog and policy material.
Includes an optional spoken-conversation path.

What you would gain

Routine "where is my order" and "what is the return policy" traffic is answered where the customer already is.
Separating product questions from policy questions keeps each answer closer to its source.
Three industry examples give a concrete starting shape instead of a blank page.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: The tested answer did not satisfy the grounded-answer requirement. A functioning chat interface is not proof of trustworthy answers.

Choose this if

You are prototyping a customer-facing assistant and want a complete shape to study.
Your questions divide cleanly into product facts and written policy.

Consider something else if

You are close to putting this in front of customers: its grounded-answer test failed here, so treat it as a prototype to repair.
Your users are staff rather than customers: Enterprise Knowledge fits internal question answering.

01 / Use it for the right job

Where it earns its place.

This accelerator combines a scenario website with an embeddable chat application. A coordinating agent routes questions to product/catalog and policy/knowledge specialists. Ecommerce, healthcare and banking scenario packs supply different host experiences and sample data; one scenario is deployed per environment.

Best uses

Help a visitor find products and understand return or warranty policies.
Prototype an industry-specific service experience before connecting real customer systems.

Know the boundary

Scenario seed data and sample transactions are not integrations with a real order, appointment or banking system.
Healthcare and financial scenarios require domain-specific review; a chat answer is not a clinical or financial decision.

How people use it

Two logical applications: scenario-app supplies the industry host; chat-app supplies widget.js, chat APIs, agent orchestration and an included Voice Live path. The reviewed IaC deploys a separate frontend and backend for each, totaling four App Service web apps. The retail experience combines product browsing with an assistant rather than presenting an isolated chatbot.

Browse the scenario site
A visitor views the configured catalog or service experience. The selected scenario controls labels, seed data and specialist instructions.
Ask within the page
The embedded widget sends the question to the chat API; orchestration selects a catalog or policy tool.
Check the answer and next action
The visitor sees the response in context. Real transactions and human escalation need customer-specific integration and validation.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The host site and chat widget have separate responsibilities. The agent backend retrieves from catalog/policy stores; the host UI is not itself the knowledge source.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Scenario website
React + API / App Service
Hosts product/service browsing and the embedded assistant.
Embedded chat
widget.js / chat-app
Collects questions within the host website. The package includes a Voice Live path; using it requires the associated service/model configuration and incurs separate usage costs.
Chat API + coordinator
FastAPI / App Service
Routes intent to catalog/product and policy/knowledge specialists.
Specialist reasoning
Microsoft Foundry
Powers the coordinator and specialist agents.
Catalog + policies
Azure AI Search
Retrieves product and policy context using the scenario indexes.
Catalog and sessions
Azure Cosmos DB
Stores catalog/order sample data and conversation history.

Read all 5 connections

Scenario website to Embedded chat
Embed assistant
Embedded chat to Chat API + coordinator
Send question / stream answer
Chat API + coordinator to Specialist reasoning
Coordinate specialists
Chat API + coordinator to Catalog + policies
Retrieve facts and policies
Chat API + coordinator to Catalog and sessions
Read catalog / persist session

The reviewed IaC provisions four App Service web apps: scenario frontend/backend and chat frontend/backend. These implement two logical application surfaces, not two hosting resources.
Voice Live is included in the chat runtime but requires its associated configuration and usage budget. Connections to real customer systems remain customer-specific integrations.

03 / Prepare the inputs

From your data to useful output.

A chosen scenario pack, approved catalog records and policy documents.

Select the scenario first
Set the scenario before the first deployment; it affects infrastructure, indexes, instructions and UI configuration.
Seed the data stores
Post-provision scripts load catalog records into Cosmos DB/Search and policy documents into the retrieval layer.
Create and align agents
Create Foundry agents with tool names and instructions matching the selected scenario manifest.

Test product facts, policy grounding, unanswered requests and cross-customer access before exposing the widget externally.

04 / Run it in your environment

What you need to get running.

Scenario-aware azd/Bicep deployment of four App Service web apps, followed by image, data and agent setup.

Code & access

Your team needs

One scenario per environment and approved replacement data
App Service, Foundry, Search, Cosmos DB and registry access
Identity, abuse protection and escalation design for the intended audience

Bring approved inputs

A chosen scenario pack, approved catalog records and policy documents.

Budget separately for

Model and retrieval usage
App Service hosting for four web apps across two logical application surfaces
Search, Cosmos DB, registry, monitoring and Voice Live usage when used

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/customer-chatbot-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach cb86d1153df30a1bc6e744d74d3ff583764cd154
git rev-parse HEAD

Select a scenario before deployment
Prepare the README's tools and review infra\main.parameters.json. Use one environment per scenario: ecommerce, healthcare or banking. The example selects ecommerce; change it before the first provision, not after seeding.
Show commands
```
azd env new "<environment-name>"
azd env set AZURE_ENV_SCENARIO ecommerce
```
Authenticate and provision
Review model deployments, search indexes, application permissions and network access for the selected scenario, then select the approved subscription.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Build the application images
From the repository root, run the image command printed by the pinned manifest. Wait for the web apps to use the new images.
Show commands
```
.\infra\scripts\post-provision\build_push_images.ps1
```
Load data and create agents
Run both stages together. Confirm the scenario's catalog/policy indexes and Foundry agents were created and that their model assignments match the approved deployment.
Show commands
```
.\infra\scripts\post-provision\postprovision_data_agents.ps1
```
Open the scenario experience
Open Scenario Web App URL from deployment output and its embedded chat widget; Chat Web App URL is the separate chat surface. Review access, CORS and allowed origins before exposing the customer-facing host.

Verify before sharing

Ask a policy question and a catalog question against seeded facts, then an unsupported question. Require grounded answers, correct citations and a safe fallback; the historical grounded-answer requirement was not met.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Digital/AI CSA
Select the scenario and define the host/widget integration.
Customer service specialist
Design supported questions, handoff and escalation.
Application/security engineer
Review session isolation, public ingress and transactional APIs.

Bring to the session

A catalog and approved policies
The target website and customer journeys
Unsupported-question and escalation examples

Agree how to judge success

Answers agree with the current catalog/policies.
Sessions do not reveal another customer context.
Unsupported questions and failed tools produce a safe, visible outcome.

First working session

Follow one product question and one policy question from the embedded widget to their different knowledge tools.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Chat API and included voice route (opens in a new tab)
The FastAPI application registers chat, chat configuration and Voice Live routers. Voice is an included runtime path, not merely a proposed external integration.
Container-image installation instructions (opens in a new tab)
The manifest prints the container-image build/push step needed to point the deployed web apps at application images.

Pinned revision cb86d1153df30a1bc6e744d74d3ff583764cd154. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Fix grounding and pass source-backed evaluation before reconsidering this candidate.

Evaluation context

The tested answer did not satisfy the grounded-answer requirement. A functioning chat interface is not proof of trustworthy answers.

Do not present this candidate as ready for public-facing service.
Source retrieval, answer grounding and escalation behavior need repair and reevaluation.

Model capacity and cost

Reserved capacity does not fix a grounding failure. Establish answer quality before considering throughput.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Service integration

Voice Live

Add a live voice conversation to a carefully bounded service.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A service integration that adds live, spoken conversation to an application. It supplies the speech interaction; your team still builds the business workflow and interface.
How it works: Streams microphone audio, handles pauses and interruptions, and speaks the reply from a model. The documented bring-your-own-model route can connect to a compatible deployment your organization controls.
Use it for: Offer spoken access when typing is inconvenient or inaccessible. Speech charges are separate, and this catalog has not tested the complete voice or customer-PTU integration.
Example scenario: Prototype a voice interface to an approved help workflow: ask a question aloud, interrupt to clarify it, and assess the reply and response delay.

From input to useful workIllustrative

SpeechInput
ModelProcess
Spoken replyOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Service designers, accessibility teams and voice application engineers
What you get: A working audio-session client / A documented model/authentication route / Measured speech latency and interruption behavior
Source & ownership: Microsoft / GitHub platform guidance. View source basis

More on fit, scope and evidence

The live-speech layer that wraps around a model: it listens, manages the back-and-forth of a spoken conversation, and speaks the reply. "Bring your own model" means the thinking can be done by a model deployment your organization controls rather than only a service-managed one. The application around it is still yours to build.

What you actually receive

A Microsoft service your application talks to. There is no application to deploy.

What it does

Runs a real-time microphone session with speech in and speech out.
Handles turn taking and interruption inside the conversation.
Can send the reasoning to a compatible model deployment you own.
Leaves the business logic, escalation and interface to your application.

What you would gain

Spoken access opens a service to people for whom typing is slow, awkward or impossible.
Using your own model deployment keeps the reasoning on a route you control.
A ready-made client exists, so speech behaviour can be judged before an application is built.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Managed text probes were verified. Official documentation supports Bring Your Own Model (BYOM) with provisioned deployments, but that integration was not tested here.

Choose this if

Speech is the point: the interaction has to be spoken rather than typed.
Your workflow is narrow and well bounded rather than open-ended conversation.

Consider something else if

You want the telephony and call handling built for you as well: see Real-time voice agents.
Text is acceptable: it is cheaper, simpler and far easier to evaluate.

01 / Use it for the right job

Where it earns its place.

Voice Live provides the real-time speech session around a generative model. BYOM selects a compatible deployment in a Foundry resource rather than relying only on a service-managed model. It is a service/API integration: the client, business tools, escalation and operational experience still need an application design.

Best uses

Prototype spoken access to a bounded information or assistance workflow.
Evaluate a compatible organization-managed model within the Voice Live session.

Know the boundary

A text-only model probe does not establish voice quality, turn handling or end-to-end latency.
Speech/session services and model capacity are separate charges; compatible PTUs are not an all-inclusive voice license.

How people use it

The official quickstart supplies a real voice playground/client. A user explicitly starts a microphone session, speaks, hears responses and ends the session. Business-system actions or a contact-center handoff are additional integrations, not included merely by enabling BYOM.

Start with consent
The client obtains microphone permission and opens an authenticated Voice Live session.
Speak and respond
Voice Live exchanges audio/session events and uses the configured model route to generate responses.
End or hand off
End the session reliably; implement a separately agreed escalation path for unsupported or sensitive requests.

02 / Under the hood

Components and how they connect.

The voice service owns the real-time session; the selected model deployment supplies the reasoning. A separate customer application owns the user experience and any business tools.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Audio client
Browser / native app
Captures consented audio, plays responses and manages session lifecycle.
Real-time voice session
Voice Live API
Coordinates streaming audio and conversation events.
Selected BYOM deployment
Microsoft Foundry
Uses a compatible realtime, chat-completion or supported Messages profile.
Resource identity access
Managed identity / RBAC
Required for cross-resource BYOM even with API-key authentication; also needed for Entra-authenticated chat-completion/Messages sessions and token renewal.
Business tools / handoff
Optional custom integration / optional
Customer-owned APIs and escalation workflows with explicit authorization.

Read all 4 connections

Audio client to Real-time voice session
Duplex audio + session events
Real-time voice session to Selected BYOM deployment
BYOM profile/model request
Resource identity access to Real-time voice session
Authorize model access
Audio client to Business tools / handoff
Optional application integration

The documented Anthropic Messages BYOM mode is preview; check profile, API, region and model support for the chosen deployment.
The compatible PTU route is documented, not verified by this catalog.

03 / Prepare the inputs

From your data to useful output.

Live audio, session instructions and any deliberately implemented business-tool context.

Configure the session
Set profile to a supported realtime, chat-completion or Messages BYOM mode, and model to the deployment name, not merely the model family.
Stream audio and events
Use the documented WebSocket/SDK flow; do not represent this as a file-upload transcription batch.
Route to the model
For another Foundry resource, set foundry-resource-override to its resource name and grant the Voice Live resource identity access on the model resource.

Test noisy speech, pauses, interruptions, long sessions/token renewal, disconnects and microphone shutdown.

04 / Run it in your environment

What you need to get running.

Official Voice Live quickstart plus the BYOM integration guide; customize the client for the business workflow.

Code & access

Repository not verified for this catalog entry. Use the platform or custom-implementation path below, not a standalone app installer.

Your team needs

Supported Voice Live region, model deployment and integration profile/API version
Speech and model budget, microphone consent and retention rules
System-assigned identity permissions on the model resource: mandatory for cross-resource use with either keys or Entra ID; verify the current Foundry role definition

Bring approved inputs

Live audio, session instructions and any deliberately implemented business-tool context.

Budget separately for

Voice Live/speech processing
Chosen model deployment usage or capacity
Client/backend hosting and business integrations

No deployment commands run from this site.

Voice API integration

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Prepare the baseline client
Open the official quickstart and choose Python plus your operating system and keyless authentication. Use Python 3.10+, the listed audio dependencies, a microphone and a supported Foundry resource. Obtain the documented Cognitive Services User permission.
Run the documented quickstart
Create the quickstart's Python environment using approved package feeds, save its sample as voice-live-quickstart.py and set its documented endpoint/authentication configuration. Sign in with Azure CLI and confirm audio input/output before adding business tools. A managed baseline is not yet your PTU route.
Grant model access
In the Voice Live Foundry resource, enable its system-assigned identity. On the model resource, grant that identity the current documented Foundry User role. Cross-resource BYOM needs this even with key authentication; verify the real role definition, not a placeholder ID in an example.
Apply the BYOM client changes
Follow the linked BYOM guide's Python changes: add the profile and optional resource-override arguments, pass them into BasicVoiceAssistant, and send profile/resource override in the connection query. Use the deployment name, not just a model family.
Run against the chosen deployment
After applying those changes, use the chat-completion profile for a compatible text-model deployment. For a different Foundry resource add the documented --foundry-resource-override argument. Confirm API/SDK compatibility.
Show commands
```
python voice-live-quickstart.py --byom "byom-azure-openai-chat-completion" --model "<deployment-name>"
```

Verify before sharing

Measure a complete conversation, interruptions and long-session authentication; correlate it with the intended model deployment. Speech/Voice Live charges remain separate. Hosting a business client, tools and handoff requires additional implementation.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Speech/AI specialist
Select supported profiles and evaluate audio/session behavior.
Service design specialist
Define consent, conversation scope and escalation.
Identity/platform CSA
Review resource identity, token renewal and deployment routing.

Bring to the session

Conversation scripts including interruptions and failures
The intended languages, devices and acoustic conditions
A model route and service budget

Agree how to judge success

The intended deployment actually handles the model request.
Interruptions, disconnects and long sessions behave correctly.
Speech and model costs are reported separately.

First working session

Instrument one complete conversation and separate audio/session latency from model and tool latency. Ask the Microsoft account team about Speech/AI specialist assistance; this is not guaranteed or a free entitlement.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Platform references explain the integration or design option only; they do not verify a portfolio-specific package.

Deployment notes & implementation considerations

Package and integration

Run a separate Voice Live BYOM integration test with speech, compatible models and realistic latency checks.

Evaluation context

Managed text probes were verified. Official documentation supports Bring Your Own Model (BYOM) with provisioned deployments, but that integration was not tested here.

Text probes do not establish end-to-end voice quality or latency.
Speech fees are separate from model-processing capacity.
This is not categorically excluded from PTU use; compatibility and the full integration must be tested.

Model capacity and cost

The documented BYOM route can use compatible PTU deployments. It is a conditional path, not a verified PTU integration in this portfolio.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Multi-agent orchestration

Coordinate a team of specialized agents around one defined task.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A configurable application for tasks that need several AI assistants working in sequence, rather than one chatbot answering a question.
How it works: Engineers define specialist roles and permitted tools. A coordinator assigns the work, passes results between assistants and shows their intermediate outputs before attempting a combined response.
Use it for: Prototype work that combines research, analysis and drafting in one reviewable process. It is not a finished business app; the recorded final-response failure needs repair.
Example scenario: Configure a briefing workflow in which one assistant gathers approved material, another compares findings and a third drafts a summary for a person to review.

From input to useful workIllustrative

TaskInput
Agent stepsProcess
SynthesisOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Business process owners and AI application developers
What you get: A configured agent team / Visible task progression and intermediate responses / A combined response for human review
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A way to break one large task into steps, give each step to a specialised assistant, and have a coordinator keep them in order. You watch the steps happen instead of receiving only a final answer. It is a foundation to configure, not a finished business system.

What you actually receive

A web application you deploy, plus an engine engineers configure for each workflow.

What it does

Splits a submitted task into steps and assigns each to a specialised agent.
Runs those steps, letting agents use only the tools you permit.
Shows the intermediate work so a person can inspect the reasoning.
Combines the steps into one response for human review.

What you would gain

Work that normally spans several people can be drafted in one pass; the coordination is the point.
Visible intermediate steps make an answer auditable instead of a single block of text to judge.
One configurable engine can serve several workflows rather than commissioning a tool for each.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Some intermediate steps ran, but the final combined response failed. MACAE is an orchestration engine, not a finished business product.

Choose this if

Your task genuinely has distinct stages that different specialists would handle.
You need to inspect the intermediate work, not only the final output.

Consider something else if

You only need answers from documents: a retrieval application such as Enterprise Knowledge is simpler.
You need something dependable now: upstream describes this as a proof of concept, not for commercial use.

01 / Use it for the right job

Where it earns its place.

MACAE is a configurable orchestration foundation. Scenario teams combine specialized agents and tools to plan, execute and combine work such as a release plan or employee-onboarding coordination. The business workflow, tool permissions and review gates must be configured; deploying the engine does not automate every department.

Best uses

Prepare a cross-team release plan using bounded specialist roles.
Prototype a multi-step staff workflow where intermediate work must be inspected.

Know the boundary

The pinned README describes a proof of concept, states that it is not intended for commercial use or distribution, and provides no warranty or support. Review the license and usage terms before delivery.
Tool execution and human approval controls need workflow-specific design. Do not give a general agent unrestricted transactional access.

How people use it

A task-oriented web frontend backed by configurable agent teams and content packs. Users submit a business task and inspect coordinated agent work rather than choosing from a universal set of ready-made business transactions.

Select a task and team
Choose the configured scenario and describe the task, its required output and constraints.
Coordinate specialist work
The orchestration runtime plans and calls configured agents and tools. Inspect intermediate results and tool access.
Review the combined output
Validate final synthesis against the task requirements; partial agent progress is not task completion.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The browser talks to an orchestration backend. Retrieval and MCP tools are distinct dependencies; model reasoning alone does not execute business work.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Task workspace
Frontend / App Service
Presents the configured agent experience and task results.
Agent coordinator
Backend / Container Apps
Coordinates the scenario team and combines agent responses.
Agent reasoning
Microsoft Foundry
Provides the model deployments used by specialized agents.
Tool integration
MCP server / Container Apps
Exposes configured tools; customer APIs require explicit integration and permissions.
Scenario knowledge
Azure AI Search
Holds indexed content loaded from the selected content pack.
Task and team state
Azure Cosmos DB
Stores application state and configuration for the orchestration experience.

Read all 5 connections

Task workspace to Agent coordinator
Submit task / receive progress
Agent coordinator to Agent reasoning
Plan and reason
Agent coordinator to Tool integration
Invoke allowed tools
Agent coordinator to Scenario knowledge
Retrieve task context
Agent coordinator to Task and team state
Persist application state

The deployment manifest requires building frontend, backend and MCP images, then loading team/content configuration.
The reviewed IaC provisions an App Service frontend and separate backend and MCP Container Apps; the README resource table describes the frontend hosting differently.

03 / Prepare the inputs

From your data to useful output.

A scenario definition, team configuration, authorized content pack and explicitly permitted tools.

Configure the team
Define roles, instructions and tool boundaries for a single business process.
Load scenario knowledge
The post-deployment script uploads team configurations, indexes sample data and creates the knowledge base.
Connect tools deliberately
The package builds an MCP server alongside the app components; replace sample integrations with approved, narrowly scoped tools.

Evaluate final synthesis, tool failures, missing context and approval boundaries, not only whether each agent responded.

04 / Run it in your environment

What you need to get running.

Bicep deployment through azd, then image deployment and content-pack initialization.

Code & access

Your team needs

One process owner and a specific scenario/team definition
Foundry models, Search, Cosmos DB and hosting quotas
Review model-deployment resources and persisted agent model selections; verify the actual approved endpoint rather than assuming Foundry-project reuse means PTU reuse. Existing-project paths can still deploy GlobalStandard models.
An app-registration owner and a reviewed tool-permission model

Bring approved inputs

A scenario definition, team configuration, authorized content pack and explicitly permitted tools.

Budget separately for

Every agent/tool-driven model turn
App Service, Container Apps and ACR
Search, Cosmos DB, storage and logs

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Multi-Agent-Custom-Automation-Engine-Solution-Accelerator.git accelerator
Set-Location accelerator
git checkout --detach 8ac703a71f10b622bd3c82a9cc2b5dfe921c3025
git rev-parse HEAD

Prepare tools and model configuration
Use PowerShell 7+, Azure CLI, compatible azd, Bicep CLI 0.33+ and Python. Review infra\main.parameters.json and the guide's Foundry reuse instructions. Match deployment names in team configurations; existing-project reuse can still create separately billed models.
Provision the selected environment
Select the approved subscription, environment, infrastructure region and AI region. Do not reuse an unrelated .azure environment or bypass failed preflight checks.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Build all runtime images
Run from the repository root. This installs frontend, backend and MCP server images; provisioning alone does not install them.
Show commands
```
.\infra\scripts\post-provision\Build-And-Push-Images.ps1
```
Initialize one scenario
Run the setup menu, select the agreed content pack and allow its data, indexes and team configurations to finish. Inspect persisted agent model selections after initialization.
Show commands
```
.\infra\scripts\post-provision\post_deploy.ps1
```
Configure access and open the application
Complete the guide's App Authentication Configuration before sharing. In the resource group, open the frontend App Service Default domain, sign in and select the initialized use case.

Verify before sharing

Run a known multi-agent task through the final combined answer, not only individual agents. Final synthesis failed in the historical evaluation; require remediation and a successful end-to-end result before adoption.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

AI/agent CSA
Define the team, orchestration boundaries and synthesis evaluation.
Business process specialist
Identify approval gates and a useful final artifact.
Integration engineer
Scope MCP tools and external API permissions.

Bring to the session

A process map and a successful final artifact
Approved sources and allowed tool actions
Named approvers and failure/escalation rules

Agree how to judge success

The final artifact satisfies the process rubric.
Tool failures and denied actions are visible.
Additional agents demonstrably improve the task rather than merely increasing calls.

First working session

Map one task into agent responsibilities and identify which actions remain under human control.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Image and content-pack initialization (opens in a new tab)
The manifest instructs operators to build frontend, backend and MCP images, then upload team configurations, index sample data and create the knowledge base.
Task and plan application routes (opens in a new tab)
The frontend defines home and per-plan routes, supporting the task-oriented workspace description.

Pinned revision 8ac703a71f10b622bd3c82a9cc2b5dfe921c3025. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Repair final synthesis and evaluate one bounded workflow before making any product claim.

Evaluation context

Some intermediate steps ran, but the final combined response failed. MACAE is an orchestration engine, not a finished business product.

A working intermediate step does not prove the end-to-end outcome.
More model calls can add cost and latency without improving the final answer.

Model capacity and cost

An orchestration engine can call compatible models, but failed synthesis is not a basis for capacity adoption or purchase.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Conversation Mining

Move from individual conversations to evidence-backed themes and metrics.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: An analysis workspace for understanding patterns across many support conversations, chats or transcripts, rather than using AI to answer a live customer.
How it works: Load permitted conversation records, ask questions about recurring themes and explore dashboards. It combines relevant conversation excerpts with database calculations so a count can be checked against examples.
Use it for: Help service teams investigate repeated complaints, common questions and process gaps. The evaluated output had meaning-level defects, so findings need validation rather than automatic acceptance.
Example scenario: Ask which delivery problems appear most often in a sample set of support chats, then inspect the matching conversations behind each reported theme.

From input to useful workIllustrative

ConversationsInput
Find patternsProcess
InsightsOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Service improvement analysts, quality teams and insights teams
What you get: Enriched searchable records / Conversational analysis using search and SQL / Schema-driven KPI and chart dashboards
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A way to look across a large pile of recorded conversations — support calls, chats, transcripts — and find the themes, rather than reading them one at a time. It can both quote individual conversations as evidence and count them, because it uses search for examples and database queries for totals.

What you actually receive

A web application you deploy, with screens for loading data, exploring it and viewing dashboards.

What it does

Takes in conversation records and enriches them for search.
Answers questions using both retrieved examples and calculated totals.
Builds dashboards from the measures you define.
Links an aggregate number back to the records behind it.

What you would gain

A recurring problem becomes a counted theme instead of an anecdote someone remembers.
The number and its supporting examples sit together, so the claim can be checked.
Analysis covers the whole set, not the handful someone had time to read.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: The evaluated output had semantic defects: successful execution did not establish that the analysis meant the right thing.

Choose this if

You hold a permitted set of conversation records and want themes and trends across them.
You need both the statistic and the examples underneath it.

Consider something else if

Your source material is documents rather than conversations: start with Enterprise Knowledge; consider Document Knowledge Mining only for a specialist gap with a maintenance owner or approved replacement.
You need this dependable now: the tested output had meaning-level defects that need repair first.

01 / Use it for the right job

Where it earns its place.

The current application combines ingestion, conversational exploration and generated insight dashboards. An agent uses both search and SQL tools: unstructured evidence supports explanations, while structured records support aggregates and charts. Its scope is broader than summarizing a transcript.

Best uses

Investigate recurring issues in an approved set of service conversations.
Compare aggregate metrics with the source records that explain a trend.

Know the boundary

Generated themes, queries and charts require semantic validation against known examples.
Conversation records can contain sensitive personal data; establish consent, minimization and authorized access before ingestion.

How people use it

Three real surfaces: Home for uploads/sample setup, Explore for questions with search and SQL tools, and Insights for schema-driven dashboards. These are application surfaces described upstream, not decorative tabs on this catalog page.

Load a scenario or records
Start from Home with a documented sample scenario or authorized upload.
Explore the evidence
Ask questions in Explore; the agent can retrieve source context and query structured data.
Inspect the dashboard
Use Insights to examine generated KPIs/charts and reconcile their definitions with the underlying records.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Search and SQL are complementary branches. Insights depend on the structured schema; Explore can connect narrative evidence with quantitative results.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Home / uploads
Web application
Accepts supported inputs or initiates scenario setup.
Files + ingestion queue
Blob + Queue Storage
Holds material and dispatches background processing.
Extraction/enrichment
Content Understanding + AI
Produces extracted content and structured analysis fields.
Evidence retrieval
Azure AI Search
Makes enriched source records searchable.
Explore + Insights
Frontend / App Service
Presents questions, analysis and schema-driven charts.
Analysis API
Backend / App Service
Coordinates the chat agent and insight generation.
Agent and insight plans
Microsoft Foundry
Selects search/SQL tools and proposes insight plans.
Structured analysis
Azure SQL Database
Stores enrichment, metadata and history for aggregate queries.

Read all 8 connections

Home / uploads to Files + ingestion queue
Upload permitted records
Files + ingestion queue to Extraction/enrichment
Process queued work
Extraction/enrichment to Evidence retrieval
Index narrative evidence
Extraction/enrichment to Structured analysis
Persist structured fields
Explore + Insights to Analysis API
Questions / dashboard requests
Analysis API to Agent and insight plans
Plan analysis
Analysis API to Evidence retrieval
Retrieve supporting records
Analysis API to Structured analysis
Query metrics and history

The reviewed deployment hook temporarily changes public network access during setup. In a restricted tenant, adapt this to an approved network-connected build/setup path; do not relax policy to reproduce the sample.

03 / Prepare the inputs

From your data to useful output.

Supported documents, structured records, images or audio, or an explicitly configured bring-your-own data source.

Queue incoming records
Blob/Queue Storage decouples uploaded material from background enrichment.
Extract and enrich
Content Understanding and model processing produce searchable content and structured fields.
Build two query surfaces
Index evidence in AI Search and store enrichment/metadata in SQL so the agent can retrieve context and calculate aggregates.

Use human-labeled records and known totals; a fluent summary or successful SQL query is not sufficient evidence of correct interpretation.

04 / Run it in your environment

What you need to get running.

azd deployment with automatic image builds and an interactive scenario/data setup hook.

Code & access

Your team needs

Approved record use and privacy/retention rules
Content Understanding, SQL, Search and model availability
A reviewed post-provision network path and SQL identity permissions

Bring approved inputs

Supported documents, structured records, images or audio, or an explicitly configured bring-your-own data source.

Budget separately for

Extraction and model enrichment per record
Interactive model and query usage
App Service, SQL, Search, Blob/Queue and monitoring

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Conversation-Knowledge-Mining-Solution-Accelerator.git accelerator
Set-Location accelerator
git checkout --detach 8a00aa54bc25fd3624020648c63f2c069172d8ca
git rev-parse HEAD

Prepare the deployment and privacy controls
Use the pinned tool prerequisites; review infra\main.parameters.json, model, SQL and search configuration. Approve transcript redaction/retention. Some private-network hooks temporarily open data-plane access: stop if tenant policy forbids this and arrange an approved build/data path.
Run the complete hook-driven deployment
Sign in to both CLIs. Select the approved environment, subscription and region. Unlike several other entries, this package automatically builds images, configures SQL roles and launches data setup through its hooks.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Complete the interactive data menu
Select the agreed scenario when prompted; wait for sample upload, search setup and Foundry agent creation. For bring-your-own-data options, obtain index/table/workspace settings and permissions from ConnectDataSource.md first. Keep the generated .env private.
Verify access and application startup
Use the frontend Open URL printed by the hook or its App Service Default domain. Complete the guide's authentication steps and confirm the signed-in user can access only the permitted conversation dataset.
Inspect analytical outputs
Run a known query and inspect summaries, sentiment and aggregate results against a small, manually reviewed transcript set. Check SQL/search/agent errors rather than rerunning unrelated deployment stages.

Verify before sharing

Confirm record counts, SQL joins, sentiment interpretation and grounded answers. Historical semantic defects remain relevant; a successful data pipeline does not establish trustworthy analytics.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Analytics/Fabric specialist
Define measures, schemas and any BYOD connection.
AI application CSA
Evaluate search/SQL tool use and semantic accuracy.
Privacy and platform owners
Approve conversation handling and deployment connectivity.

Bring to the session

De-identified records with human labels
Known KPI definitions and SQL totals
Retention and access policies

Agree how to judge success

Metrics match independently computed totals.
Themes correspond to labeled source records.
Unsupported interpretations and processing failures are visible.

First working session

Trace one recurring issue from raw records to extracted fields, aggregate metrics and supporting evidence.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Pinned revision 8a00aa54bc25fd3624020648c63f2c069172d8ca. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Repair semantic quality, then compare Batch and interactive processing for the actual workload.

Evaluation context

The evaluated output had semantic defects: successful execution did not establish that the analysis meant the right thing.

Validate interpretations against reviewed examples rather than relying on run completion.
Privacy and permission controls are essential for conversation records.

Model capacity and cost

Bulk, nonurgent analysis is a legitimate Batch candidate. PTUs would need a separate case based on latency needs and measured demand.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Content Generation

Develop campaign drafts grounded in product data and brand guidance.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: An internal drafting workspace for marketing campaigns, not official correspondence or policy briefings. A marketer starts with a creative brief instead of a blank prompt.
How it works: Provide the audience, message, tone and call to action. Specialist assistants research product material, draft copy and images, then return feedback against configured brand guidelines.
Use it for: Explore campaign variations and give editors material to refine. Brand feedback is not factual or legal clearance, and the catalog established compilation—not a complete working campaign process.
Example scenario: Draft two campaign concepts for a sample product launch with different audiences, then have an editor compare the wording, images and brand feedback.

From input to useful workIllustrative

BriefInput
DraftProcess
Editorial reviewOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Marketing operations, creative teams and brand reviewers
What you get: Structured creative-brief fields / Draft marketing text and images / Severity-categorized brand feedback
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A drafting workspace for campaigns. You fill in a brief — audience, message, tone, what you need, the call to action — and a set of specialised assistants research the product, write copy, generate images and check the result against your brand guidelines. It produces drafts for an editor, not material ready to publish.

What you actually receive

An internal web application you deploy for drafting marketing material.

What it does

Turns a completed creative brief into a structured request.
Researches the relevant product or catalog material.
Generates draft copy and draft images.
Returns brand-guideline feedback graded by severity.

What you would gain

The blank page disappears: reviewers edit a draft instead of commissioning one.
Brand feedback arrives during drafting rather than at the end of an approval queue.
Variations are cheap, so choices get made by comparison.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Compilation was established. The repository targets marketing content, not controlled briefing or correspondence drafting.

Choose this if

Your work is marketing content and you have brand guidance to check against.
An editor approves everything before it is published.

Consider something else if

You need official correspondence or briefing drafts: that is an unbuilt use-case idea, not this package.
You need factual or legal clearance: brand feedback is neither.

01 / Use it for the right job

Where it earns its place.

A marketing-focused internal application that interprets creative briefs and coordinates Triage, Planning, Research, Text Content, Image Content and Compliance agents through Agent Framework handoffs. It generates copy/images and returns brand-guideline feedback; editorial approval remains a separate responsibility.

Best uses

Draft campaign copy using a structured creative brief and product catalog.
Explore image/copy variations and inspect brand-guideline feedback.

Know the boundary

This is marketing content, not the planned controlled-briefing or official-correspondence workflow.
Brand-compliance agent feedback is not legal clearance, factual certification or permission to publish.

How people use it

An internal conversational content workspace. The brief specifies audience, message, tone, deliverable, visuals and call to action; specialized agents research products, generate drafts and return compliance feedback.

Describe the campaign brief
Provide objectives, audience, tone, deliverables and visual requirements.
Generate grounded drafts
The agent team researches product context and hands off text/image creation tasks.
Review brand feedback
Inspect drafts and Error/Warning/Info feedback, then have a brand/editorial reviewer decide what can be used.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

This package uses an App Service frontend and an Azure Container Instance backend. The agent team fans out to retrieval, data and separate text/image model capabilities.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Creative workspace
App Service frontend
Hosts the content experience with a Node.js proxy.
Creative agent team
Azure Container Instance
Agent Framework HandoffBuilder coordinates six specialist roles.
Text and image models
Microsoft Foundry
Supplies language and image-generation deployments; verify them independently.
Product / brand context
Azure AI Search
Retrieves the enterprise context used for research and generation.
Products + conversation
Azure Cosmos DB
Stores product catalog and conversation history.
Image assets
Azure Blob Storage
Stores source product images and generated images.

Read all 5 connections

Creative workspace to Creative agent team
Brief / draft conversation
Creative agent team to Text and image models
Generate text and images
Creative agent team to Product / brand context
Retrieve grounding
Creative agent team to Products + conversation
Read catalog / save history
Creative agent team to Image assets
Read/write image assets

The reviewed Bicep explicitly separates ACI backend hosting from the App Service frontend; it is not a generic Container Apps stack.

03 / Prepare the inputs

From your data to useful output.

Approved product data, product images, brand guidelines and a creative brief.

Prepare brand/product context
Replace synthetic sample catalogs and guidelines with material approved for the campaign.
Load data services
Search supports retrieval; Cosmos DB holds products/conversation state and Blob holds product/generated images.
Interpret and validate the brief
Agents structure the brief, retrieve context, generate assets and assess them against the supplied brand guidance.

Check product claims, image rights, prohibited content and whether feedback actually corresponds to the brand rules.

04 / Run it in your environment

What you need to get running.

azd provisions the infrastructure with placeholder images. Then run the package build_and_deploy_images script followed by process_sample_data, in that order, using permitted configuration and data.

Code & access

Your team needs

Both required text and image model availability/quotas
Approved brand rules, product data and image usage rights
ACI/App Service network connectivity and a named publishing approver

Bring approved inputs

Approved product data, product images, brand guidelines and a creative brief.

Budget separately for

Text and image-generation usage
App Service and ACI runtime
Search, Cosmos DB, Blob, registry and monitoring

No deployment commands run from this site.

Azure application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/content-generation-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach fa956c9ec374f0f7e9b03ae2873d38e5269186fe
git rev-parse HEAD

Prepare text and image dependencies
Use the linked azd guide's tool versions. Review infra\main.parameters.json and the text/image deployment settings; both model types must be available. Approve brand inputs, image rights and the backend network route.
Provision the environment
Sign in to both CLIs and select the approved subscription. Infrastructure uses placeholder images; do not stop at azd success.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Build images, then load sample data
From the root, activate the Python environment before running the two scripts in order. Review approved feed settings and sample-loading behavior first.
Show commands
```
python -m venv .venv
.\.venv\Scripts\Activate.ps1
.\infra\scripts\build_and_deploy_images.ps1
.\infra\scripts\process_sample_data.ps1
```
Configure authentication
Complete AppAuthentication.md linked by the deployment manual. Open the App Service Default domain after its application and backend are healthy; test allowed and denied sign-ins.
Generate a reviewed draft
Enter an approved creative brief, select Confirm Brief, choose a product and Generate Content. Inspect generated text, images and brand feedback before any publishing.

Verify before sharing

Verify product claims against source facts, check image generation and rights, and require editorial approval. Text PTUs do not include image generation, hosting or storage.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

AI application CSA
Review agent handoffs and model/image integration.
Brand/content specialist
Define the brief, review rubric and publishing process.
Data/application engineer
Connect product data and manage generated asset retention.

Bring to the session

A real creative brief and brand rules
Permitted product facts and images
Examples of acceptable and unacceptable campaign content

Agree how to judge success

Product claims are supported by approved data.
Image rights and brand requirements are reviewed.
No draft is published merely because a compliance agent approved it.

First working session

Follow one brief through research, text/image creation and brand feedback; compare with editorial expectations.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Pinned revision fa956c9ec374f0f7e9b03ae2873d38e5269186fe. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Keep this separate from the planned controlled-drafts implementation; evaluate only for a justified marketing use case.

Evaluation context

Compilation was established. The repository targets marketing content, not controlled briefing or correspondence drafting.

Compilation does not establish usable output or a complete workflow.
The proposed controlled-drafts workflow needs a new implementation with approved sources and review gates.

Model capacity and cost

No validated business-drafting workload or PTU demand was demonstrated by compilation.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Agentic Unified Data Foundation

Explore governed business data through a conversational application.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A web application for asking questions about records already held in Microsoft Fabric, the data and analytics platform. It works with business data, not a folder of documents.
How it works: A signed-in user asks a question in ordinary language. The application works with a Fabric Data Agent to query the configured data and return an answer with data context.
Use it for: Let business teams explore sales, product or other governed records without writing each query themselves. Permissions and answer accuracy need testing; not all reasoning runs on customer PTUs.
Example scenario: Using the sample retail data, ask which products sold most in a period and compare the answer with a known database query.

From input to useful workIllustrative

Fabric dataInput
Data agentProcess
AnswerOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Business analysts, Fabric data owners and AI application teams
What you get: An authenticated data-questioning application / A mapped scenario dataset and agent configuration / Reconciled answers with permission and cost checks
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A conversational way into business data that is already governed in Microsoft Fabric — sales, product or customer questions asked in ordinary language and answered from the records themselves, not from documents about them. Retail and insurance example datasets are included so the shape can be tried before your own data is involved.

What you actually receive

A web application you deploy that answers questions about governed business data.

What it does

Takes a business question through an authenticated web application.
Turns it into governed queries against Fabric data.
Returns an answer with the data context behind it.
Ships example datasets whose answers can be checked against a known query.

What you would gain

Business questions get asked directly instead of queued as report requests.
Answers come from the governed dataset, so permissions and definitions still apply.
Example data makes it possible to verify an answer against a known-correct result.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Historical inventory note, recorded under the different Fabric User Data Functions label: Required prerequisites prevented full validation. Custom model endpoints are possible, but no tested PTU integration is claimed. That record does not validate the pinned Agentic Unified Data Foundation accelerator described here.

Choose this if

Your data already lives in Fabric and is governed there.
The questions are about records and numbers rather than documents.

Consider something else if

Your answers live in documents: see Enterprise Knowledge or Document Knowledge Mining.
You expect all reasoning to run on your reserved capacity: part of this route uses Microsoft-managed AI.

01 / Use it for the right job

Where it earns its place.

The pinned package combines a web application, Foundry agents, Agent Framework and Fabric data access for natural-language business questions. Retail and insurance scenario packs provide synthetic starting data. The Python chat implementation invokes a Foundry agent; structured queries are handled server-side through the Fabric Data Agent MCP integration.

Best uses

Ask governed sales, product or customer questions through a web experience.
Adapt a scenario pack and validate its answers against authoritative queries.

Know the boundary

This pin is Agentic Applications for Unified Data Foundation, not Fabric User Data Functions. The earlier Fabric UDF label is a package mismatch; historical UDF inspection or test evidence must not be transferred to this accelerator.
Fabric Data Agent uses Microsoft-managed AI; adding a Foundry application does not route all Fabric reasoning through customer PTUs. The reviewed template creates Standard/GlobalStandard model deployments, not provisioned deployments.

How people use it

The Foundry option offers a web conversation with streamed answers and data context. A separate documented Copilot Studio/Teams option exists; it is an alternative integration path, not proof that the web deployment includes Teams or Copilot Studio licensing.

Choose a business dataset
Select a scenario pack or approved custom tables and define authoritative business measures.
Ask and inspect
The web API streams a Foundry agent response grounded through configured Fabric tools.
Reconcile and govern
Compare answers with direct queries, verify user-level access and retain human ownership of business decisions.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The reviewed source uses App Service-hosted application containers and a Foundry agent that calls Fabric Data Agent via MCP. Fabric-managed AI is distinct from the application model deployment.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Data conversation
Web frontend
Presents questions and streamed answers to authorized users.
Application API
App Service / FastAPI
Handles chat/history routes and the selected authentication context.
Application reasoning
Foundry + Agent Framework
Invokes the configured Foundry agent and streams its response.
Governed data queries
Fabric Data Agent / MCP
Uses Fabric-managed AI and authorized data access for structured queries.
Business data + history
Fabric data assets / SQL
Stores scenario tables and the configured application history; validate the exact deployed asset set.
Application images
Azure Container Registry
Supplies built frontend/backend images to App Service.

Read all 6 connections

Data conversation to Application API
Authenticated conversation
Application API to Application reasoning
Stream agent request
Application reasoning to Governed data queries
MCP data query
Governed data queries to Business data + history
Authorized query
Application API to Business data + history
Configured session history
Application images to Application API
Container deployment

Some prerequisite/cost prose still describes Container Apps; the reviewed Bicep and architecture identify App Service. Price the selected source configuration, not a stale sample estimate.
This is public-source inspection of the pinned package, not a completed deployment or inherited evidence from a different UDF package.

03 / Prepare the inputs

From your data to useful output.

Structured customer/product/transaction data or approved custom tables; optional documents require their own configured retrieval path.

Prepare the scenario
Map table schemas, relationships and measures instead of treating this as generic file chat.
Configure Fabric assets
Follow the package Fabric setup for the workspace, data agent and required data/ontology assets; replace synthetic samples deliberately.
Connect the application
Build the application images and configure Foundry agent/MCP integration, authentication and any session-history storage.

Reconcile totals, joins, time ranges and access-denied cases against trusted SQL/data-owner answers.

04 / Run it in your environment

What you need to get running.

Pinned Fabric setup and azd/Bicep deployment, followed by the explicitly separate application-image build/push and scenario configuration.

Code & access

Your team needs

Approved Azure subscription permissions, model quota and compatible service regions
Paid Fabric capacity and workspace/data permissions; review required Copilot, Ontology/Graph preview and applicable cross-geo AI tenant settings
Application authentication/OBO design, approved data schemas and independent Azure/Fabric budgets

Bring approved inputs

Structured customer/product/transaction data or approved custom tables; optional documents require their own configured retrieval path.

Budget separately for

Fabric capacity and Fabric-managed AI/query consumption
Application Foundry model usage, embeddings and configured Search
App Service, registry, monitoring and data storage; Copilot Studio/Teams entitlements only for that alternative route

No deployment commands run from this site.

Azure and Fabric application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/agentic-applications-for-unified-data-foundation-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach 28c25024e43884b0a23c996d5cc8d3419f4e448c
git rev-parse HEAD

Prepare Fabric and application settings
Use the guide's Fabric workspace setup and required tenant/capacity permissions. Prepare the local Python, PowerShell, azd and Azure CLI tools. Review infra\main.parameters.json and choose the scenario/runtime, network flavor and model route.
Reuse approved capacity and provision
Set the approved existing Fabric workspace before provisioning to avoid automatic capacity creation. Select the intended subscription and environment; use a new capacity only with explicit purchasing approval.
Show commands
```
azd auth login
az login
azd env new "<environment-name>"
azd env set FABRIC_WORKSPACE_ID "<workspace-id>"
azd up
```
Build and install application images
From the repository root, run the separate API/frontend image stage.
Show commands
```
.\infra\scripts\build\build-and-push-acr.ps1
```
Initialize the Fabric solution
Create/activate .venv and install the pinned post-provision requirements through approved feeds as described in the manual. Then run the build orchestrator and agent check. The default is retail; use its documented scenario option for insurance.
Show commands
```
python infra\scripts\post-provision\00_build_solution.py --from 01
python infra\scripts\post-provision\06_test_agent.py
```
Configure delegated access and open the app
Complete SetupOBOAuthentication.md for the selected user-access route, including app registration, consent and connection settings. Open the frontend App Service Default domain and sign in as a permitted user.

Verify before sharing

Ask a known data question and reconcile the answer/chart with underlying tables. Test delegated access with another user; a working Fabric data agent is not proof that its model calls use the customer's PTUs.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Fabric data specialist
Own schemas, measures, data permissions and tenant settings.
Foundry/application CSA
Review agent/MCP orchestration, hosting and actual model routing.
Identity/licensing specialist
Validate OBO, channel entitlements and separate capacity budgets.

Bring to the session

A small governed dataset with known query answers
Fabric/Foundry access, tenant-setting decisions and cost owners
An explicit choice between web and Copilot Studio/Teams integration

Agree how to judge success

The package identity and evidence boundary are explicit.
Answers reconcile with trusted queries and respect user permissions.
Azure application model usage and Fabric consumption are measured separately.

First working session

Trace one business question across the application and Fabric-managed data agent. Ask the Microsoft account team about joint Fabric/AI assistance; scope, availability and commercial terms require agreement.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
App Service hosting implementation (opens in a new tab)
App Service plan and frontend/backend container modules establish actual hosting despite conflicting Container Apps prose.
Model deployment configuration (opens in a new tab)
The allowed deployment types are Standard and GlobalStandard; this template does not provision a PTU deployment.
Postprovision image-build instructions (opens in a new tab)
Provisioning prints separate application-image build/push steps; infrastructure completion alone is not a running application.
Fabric Data Agent authentication and prerequisites (opens in a new tab)
Fabric uses Microsoft-managed Azure OpenAI, with separate capacity and data-access requirements; it does not take the customer application model key.

Pinned revision 28c25024e43884b0a23c996d5cc8d3419f4e448c. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Clear prerequisites and test the custom model-call path with a bounded data task.

Evaluation context

Historical inventory note, recorded under the different Fabric User Data Functions label: Required prerequisites prevented full validation. Custom model endpoints are possible, but no tested PTU integration is claimed. That record does not validate the pinned Agentic Unified Data Foundation accelerator described here.

Fabric User Data Functions and the Agentic Unified Data Foundation accelerator are different offerings; historical evidence must not be transferred between them.
Platform prerequisites, permissions and model-call behavior must be validated.

Model capacity and cost

A custom endpoint could reach a compatible model deployment. Neither that route nor meaningful PTU demand was proven here.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Fabric solution accelerator

RealTime Operations

Turn operational telemetry into dashboards, alerts and data questions.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A Microsoft Fabric starting point for watching operational activity as it happens, using live dashboards, alert rules and a data-questioning assistant.
How it works: Streams sensor or equipment readings into a real-time data store, displays the readings, sends configured notifications when thresholds are crossed and supports questions about the history.
Use it for: Help operations teams spot unusual patterns and investigate them instead of waiting for a periodic report. It includes a simulator; production monitoring and model routing still need validation.
Example scenario: Run simulated factory readings, configure a temperature threshold and inspect an alert alongside the recent readings to understand what triggered it.

From input to useful workIllustrative

SignalsInput
InvestigateProcess
Human decisionOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Operations analysts, asset-monitoring teams and Fabric engineers
What you get: A configured real-time dashboard / Reviewed alert rules and destinations / A validated Fabric data-agent question set
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A worked example of operational monitoring. Equipment and sensor readings stream in, appear on a live dashboard, and raise an alert when a rule you set is crossed; the history can then be questioned in ordinary language. It arrives with invented factory data and a simulator, so it can be explored before any real telemetry is connected.

What you actually receive

A Fabric-based starting point: live dashboards, alert rules and a data agent to ask questions.

What it does

Streams telemetry into a real-time store and dashboard.
Sends configured notifications when an alert rule is met.
Answers questions over historical and streaming data.
Includes synthetic data and an event simulator for exploration.

What you would gain

Operational patterns become visible in the moment rather than in next week’s report.
Alerts reach the people who can act, through rules you control.
Investigating an anomaly stops being a query-writing exercise.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: The candidate remained gated by prerequisites. No validated end-to-end model-assisted operations workflow was established.

Choose this if

You have streaming operational or sensor data and already use Microsoft Fabric.
Dashboards and alerts are the outcome you want, not a chat interface.

Consider something else if

You need safety-critical or production monitoring: this is a demonstration starting point.
Your data is not telemetry: the pattern will not transfer cleanly.

01 / Use it for the right job

Where it earns its place.

A manufacturing telemetry starting point built around Azure Event Hubs and Fabric Eventstream, Eventhouse/KQL, Real-Time Dashboard, Activator and a Fabric Data Agent. It includes synthetic historical data and an on-demand event simulator. The real user surfaces are Fabric dashboards, configured notifications and the data-agent conversation, not a newly hosted custom chatbot.

Best uses

Monitor asset/sensor trends and investigate threshold anomalies.
Ask operational questions over historical and streaming telemetry.

Know the boundary

Synthetic telemetry and sample rules are demonstration assets, not evidence of production monitoring or safety-critical readiness.
Fabric Data Agent is Microsoft-managed AI, not a customer Azure OpenAI/PTU deployment. Its preview setup can fail independently while core dashboard functionality remains available.

How people use it

Users inspect the Fabric Real-Time Dashboard, query the Fabric Data Agent and receive configured Activator email notifications. Teams notification is an optional rule configuration. The simulator is a separate tool, not a customer-facing application.

Connect telemetry
Map timestamps, assets, sensor types and units to the expected event schema.
Monitor and investigate
Use KQL-backed dashboard tiles and reviewed Activator rules to detect conditions worth investigation.
Ask and act responsibly
Query the Fabric Data Agent and corroborate findings before an authorized operator takes action.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

Azure Event Hubs carries telemetry into Fabric; dashboard, alert and conversational paths branch from the same operational data flow.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Telemetry feed
Simulator / approved source
Emits timestamped JSON events; the supplied Python sender uses Azure CLI credentials.
Streaming ingress
Azure Event Hubs
Receives events; the pinned Fabric connection requires SAS/local authentication.
Event routing
Fabric Eventstream
Routes telemetry to analytics storage and alert rules.
Operational history
Eventhouse / KQL database
Combines seeded historical and incoming events for queries.
Condition notifications
Fabric Activator
Evaluates configured rules and sends email or configured Teams alerts.
Monitoring + questions
Real-Time Dashboard / Data Agent
Uses KQL data for visual monitoring and Fabric-managed conversational answers.

Read all 5 connections

Telemetry feed to Streaming ingress
JSON telemetry
Streaming ingress to Event routing
Fabric connection
Event routing to Operational history
Persist/query events
Event routing to Condition notifications
Evaluate rules
Operational history to Monitoring + questions
KQL analytics + data questions

The Bicep enables Event Hub local authentication for Fabric SAS and includes a policy-override tag. Do not copy a policy bypass into an enterprise deployment; obtain an approved compatible connection design.
No customer-managed model endpoint or Container Apps runtime is established by this architecture.

03 / Prepare the inputs

From your data to useful output.

Synthetic historical and live manufacturing events initially; approved operational feeds require explicit integration.

Load historical context
The deployment seeds historical events in Eventhouse; distinguish generated history from live measurements.
Stream new events
A separately started simulator or approved feed sends JSON to Event Hubs, then Fabric Eventstream forwards it to Eventhouse and Activator.
Configure interpretation
Adapt KQL tables/queries, dashboard tiles, thresholds and data-agent instructions to the actual assets and business measures.

Test stale/out-of-order data, duplicate events, schema drift, missing sensors and false alerts before relying on operational notifications.

04 / Run it in your environment

What you need to get running.

Two-phase azd deployment: Azure Bicep creates/reuses capacity and Event Hub resources; the postprovision Python workflow configures Fabric assets.

Code & access

Your team needs

Azure deployment/RBAC permissions and Fabric workspace-creation access
Paid F2+ or supported P1+ capacity for Data Agent, permitted data access and applicable cross-geo AI tenant settings; automation needs the relevant Fabric REST identity setting
An approved Event Hub-to-Fabric authentication/network design, telemetry schema and notification owner

Bring approved inputs

Synthetic historical and live manufacturing events initially; approved operational feeds require explicit integration.

Budget separately for

Fabric capacity, Eventhouse/Eventstream/Activator and data-agent consumption
Azure Event Hubs ingestion/retention and telemetry-generator runtime
Notification destinations, operational administration and any added integrations; Azure OpenAI PTUs do not cover these services

No deployment commands run from this site.

Fabric operations solution

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/real-time-intelligence-operations-solution-accelerator.git accelerator
Set-Location accelerator
git checkout --detach cfbdb91ee83ed31b5ccc5de7feca7a0b5b2e5f68
git rev-parse HEAD

Prepare Fabric permissions and scope
Use the manual's Azure and Fabric prerequisites, Python, Azure CLI, azd and Bicep. Obtain an approved Fabric capacity/workspace and tenant permissions for the deploying identity. Define synthetic event scope and alert recipients.
Configure reuse before provisioning
Create a new environment and set the approved existing capacity and workspace names. Review the manual's region, administrator and optional Event Hub reuse settings; do not default to buying capacity.
Show commands
```
azd env new "<environment-name>"
azd env set EXISTING_FABRIC_CAPACITY_NAME "<capacity-name>"
azd env set FABRIC_WORKSPACE_NAME "<workspace-name>"
```
Deploy both phases
Authenticate, select the approved subscription and run the Azure infrastructure plus Fabric setup workflow. Inspect Eventhouse, KQL database, Eventstream, dashboard and Activator results individually.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Complete data-agent setup
Open the Fabric workspace and follow FabricDataAgentGuide.md from Step 5 of the manual. If its preview setup fails, report that component as incomplete even if the dashboard works.
Start bounded events and configure alerts
Follow EventSimulatorGuide.md for the separate simulator, with an agreed duration/rate. Use ActivatorGuide.md to enable only approved alerts. Inspect incoming events and dashboard refresh before testing the data agent.

Verify before sharing

Reconcile event counts and time windows, trigger one synthetic alert and check an agent answer against KQL results. Stop the simulator afterward; event volume is not model demand and Fabric costs are separate.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Fabric/streaming specialist
Map Event Hubs, Eventstream and KQL ingestion/query behavior.
Operations owner
Set meaningful rules and own incident response rather than delegating it to generated answers.
Platform identity specialist
Resolve SAS/local-auth policy compatibility and Fabric permissions.

Bring to the session

A telemetry schema and a small synthetic event set
Known normal/anomalous examples with expected KQL results
Approved capacity, connection policy and notification recipients

Agree how to judge success

Event timestamps, dashboard freshness and retention are correct.
Alerts reach approved recipients with an acceptable false-positive rate.
Data-agent setup and answers are verified independently of core deployment success.

First working session

Follow one event through the dashboard, Activator notification and data-agent query. Ask the Microsoft account team about Fabric specialist assistance; availability and commercial terms are not guaranteed.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Event Hub and Fabric capacity implementation (opens in a new tab)
The pinned Event Hub-to-Fabric connection requires SAS/local authentication; review compatibility with enterprise policy rather than copying the policy-override tag.
Fabric postprovision orchestration (opens in a new tab)
azd invokes a separate Python Fabric deployment workflow after the Azure infrastructure stage.
Preview Data Agent setup and table-selection caveat (opens in a new tab)
Data Agent configuration and selected KQL tables require independent verification and may need manual completion in the Fabric portal.
Fabric Data Agent managed AI and capacity requirements (opens in a new tab)
Fabric-managed model authentication, paid capacity and user data permissions are distinct from customer Azure OpenAI PTUs.

Pinned revision cfbdb91ee83ed31b5ccc5de7feca7a0b5b2e5f68. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Define one bounded assistance task, clear prerequisites and measure its model calls.

Evaluation context

The candidate remained gated by prerequisites. No validated end-to-end model-assisted operations workflow was established.

A high volume of telemetry does not imply a high volume of model requests.
Any future operational advice requires permission boundaries and human approval.

Model capacity and cost

Estimate only the actual model-dependent steps, not raw telemetry volume. PTU fit remains unproven.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Reference application

Video workflow

Explore descriptions of permitted videos through sampled frames.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A small developer application that generates descriptions of a video by examining selected still images. It is not continuous video monitoring or an audio-transcription service.
How it works: Upload a permitted clip, choose how many frames to sample and enter a question. The app extracts those frames and returns a model-generated description, frame counts and a representative image.
Use it for: Evaluate whether rough visual summaries are useful for a narrow review task. Sampling can miss brief events, so the generated description must be checked against the full video.
Example scenario: Describe a short sample equipment-demonstration clip at two sampling rates, then compare what each summary captures or misses while watching the original.

From input to useful workIllustrative

Video clipInput
Sample framesProcess
DescriptionOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Application developers, media analysts and teams evaluating permitted visual-description tasks
What you get: Generated video description / Reported frame counts / Representative frame for review
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A developer sample that describes what is in a video by taking still frames from it and asking a model about those pictures. You choose how many frames to sample and what to ask. Because it looks at samples rather than the whole video, brief events between frames can be missed entirely.

What you actually receive

A small reference application developers run and adapt.

What it does

Accepts a video and extracts a chosen number of frames.
Sends the selected frames to a model together with your prompt.
Returns a written description, the frame count and a sample image.
Lets you compare the effect of different sampling settings and prompts.

What you would gain

A rough description of visual material is produced without watching all of it.
The sampling trade-off is visible and adjustable rather than hidden.
It is small enough for a developer to read and understand end to end.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: Only bounded tests were completed, with one safety block. No video service-level agreement (SLA) is established by these results.

Choose this if

You want to judge whether frame-based description is good enough for a narrow task.
Your team works in .NET and wants a readable starting sample.

Consider something else if

You need spoken audio transcribed or events timestamped: it does neither.
You need continuous or reliable detection: sampling will miss things.

01 / Use it for the right job

Where it earns its place.

A collection of .NET multimodal AI samples includes an Aspire/Blazor reference application. Users upload a video, choose a sampled-frame count and prompts, and receive a generated description. OpenCV extracts frames before selected images are sent to a configured multimodal chat model. This is bounded frame-based exploration, not a validated video-investigation platform.

Best uses

Evaluate descriptions of a short synthetic or authorized video.
Compare the effects of frame sampling and prompts on scene descriptions.

Know the boundary

Sampling can miss brief events; fluent descriptions do not establish complete video understanding.
The reviewed workflow does not establish audio transcription, timestamped evidence indexing or continuous event detection.
The catalog evidence remains limited; do not bypass safety controls to expand the task.

How people use it

A Blazor page accepts a local video and exposes frame-count, system-prompt and user-prompt controls. Results include a description, frame counts and an image. Separate console examples demonstrate other provider/library combinations.

Choose permitted media
Select a short synthetic or authorized video and a narrow visual-description task.
Configure frame analysis
Choose the sampling count and prompts, then submit the video through the reference application.
Check the description
Compare the result with the original video, including events between sampled frames.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The reference application performs sampled-frame analysis, not durable media indexing or real-time monitoring.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Permitted video
Local media file
Synthetic or authorized input for a bounded visual task.
Video analysis page
Blazor frontend
Collects video, frame-count and prompt settings.
Analysis endpoint
.NET API service
Coordinates extraction and description.
Frame processing
OpenCV / OpenCvSharp
Extracts, resizes and samples frames.
Multimodal description
Configured chat model
Receives sampled images and prompts.
Description + frame
Application response
Returns description, frame counts and a representative image.

Read all 6 connections

Permitted video to Video analysis page
Select permitted file
Video analysis page to Analysis endpoint
Submit video and settings
Analysis endpoint to Frame processing
Extract and sample
Frame processing to Multimodal description
Provide selected images
Multimodal description to Description + frame
Generate description
Description + frame to Video analysis page
Display for review

The azd configuration targets the Aspire AppHost on Container Apps.
Confirm the provider and authentication used by the selected application path; console examples are separate integrations.
Durable media storage, access controls and operational hardening require separate design.

03 / Prepare the inputs

From your data to useful output.

A video file, requested sample-frame count and system/user prompts.

Receive the video
The reference API accepts video bytes and analysis settings.
Extract and sample frames
OpenCV reads and resizes frames; the processor selects images using a calculated sampling interval.
Request a description
Selected images and prompts are passed to the configured multimodal chat model.

Compare claims with the full video and record missed events, unsupported details and sampling effects.

04 / Run it in your environment

What you need to get running.

Follow the pinned Aspire/Blazor guide for local prerequisites and the azd Container Apps deployment route.

Code & access

Your team needs

Compatible .NET/Aspire tooling and a container runtime
Approved multimodal model availability and authentication
Permitted media, a bounded task and a service budget

Bring approved inputs

A video file, requested sample-frame count and system/user prompts.

Budget separately for

Multimodal model usage for sampled images
Container Apps and registry
Monitoring and separately designed media retention

No deployment commands run from this site.

Aspire / Blazor application

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/Azure-Samples/netaivideoanalyzer.git accelerator
Set-Location accelerator
git checkout --detach 1d8ed2ece3ee4c05441f98a0e06965c0207f21e7
git rev-parse HEAD

Prepare the selected sample
Use the pinned guide's .NET/Aspire SDK, azd, Azure CLI and container tooling. Review AppHost configuration and the API's OpenCV-compatible base image. The Blazor path is distinct from console samples; review and pin external images/dependencies before deployment.
Initialize from the AppHost
From the repository root, enter the AppHost directory and initialize azd. Choose Use code in the current directory, not a new remote template.
Show commands
```
Set-Location srcBlazor\AspireVideoAnalyserBlazor.AppHost
azd init
```
Configure and deploy
Review the generated configuration, model deployment and approved Azure subscription before continuing. Default model creation is not reuse of existing PTUs.
Show commands
```
azd auth login
az login
az account set --subscription "<subscription-id>"
azd up
```
Open the frontend and check connectivity
Use deployment output to open the Container Apps/Aspire dashboard and webfrontend endpoint. Confirm API access, exact allowed CORS origin and model identity permissions. Do not enable anonymous dashboard access or wildcard origins as a fix.
Analyze permitted media
Upload one short authorized video in Blazor, set the frame count and prompts, then submit analysis. Inspect the description, reported frames and representative image.

Verify before sharing

Compare the description with the full clip, including brief events between sampled frames. Confirm image-capable model routing; audio transcription and complete event detection are not provided by this sample.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

.NET application engineer
Review Aspire, Blazor, API and OpenCV integration.
AI application specialist
Evaluate model compatibility and description reliability.
Media/data owner
Approve input rights, retention and acceptable tasks.

Bring to the session

Short synthetic or authorized video
Reference description and known brief events
Sampling budget and prohibited-use boundaries

Agree how to judge success

Descriptions are checked against the original media.
Sampling gaps and unsupported claims are recorded.
Safety restrictions and media permissions remain intact.

First working session

Analyze the same permitted clip with two sampling settings and compare descriptions against the complete video.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Blazor video-analysis controls (opens in a new tab)
Exposes frame-count, system-prompt, user-prompt, file-selection and analysis controls; displays frame counts and a representative image.
Video-analysis request and response (opens in a new tab)
Receives video bytes and settings, invokes frame extraction and description generation, and returns description, frame counts and an image reference.

Pinned revision 1d8ed2ece3ee4c05441f98a0e06965c0207f21e7. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Clarify the permitted task and supported deployment; evaluate without bypassing safety controls.

Evaluation context

Only bounded tests were completed, with one safety block. No video service-level agreement (SLA) is established by these results.

Do not extrapolate the tests to general video reliability or availability.
Respect safety controls; confirm model modality and deployment support separately.

Model capacity and cost

PTU compatibility must be checked for the exact model, API and modality. Text capacity is not a blanket video entitlement.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Application accelerator

Planetary Explorer

Ask a place-and-time question, then inspect the imagery behind the answer.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A map-based assistant for exploring satellite imagery and environmental change. It puts a conversation beside the geographic evidence, rather than answering from ordinary business documents.
How it works: Ask about a place and time period. The application searches public geospatial datasets, loads relevant imagery as map layers and helps interpret what those scenes show.
Use it for: Help research teams find imagery for questions about vegetation, surface water or changes over time. A domain specialist still needs to check the data and interpretation.
Example scenario: Choose a region and two time periods, find relevant surface-water imagery, then inspect the scenes to investigate whether visible water coverage changed.

From input to useful workIllustrative

Place + timeInput
Find imageryProcess
Map layersOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Earth-science researchers, environmental analysts and geospatial specialists
What you get: Dataset and scene selections / Interactive map layers and analysis context / An interpretation that can be checked against imagery
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

An Earth-observation explorer. You ask about a place and a time period in ordinary language — vegetation, surface water, how somewhere has changed — and it finds suitable satellite imagery, loads it onto a map and helps interpret what you are seeing. It is an open-source project, not a supported Microsoft product.

What you actually receive

A web application you deploy: a map beside a conversation.

What it does

Turns a place-and-time question into a search across public geospatial datasets.
Loads the matching imagery as layers on an interactive map.
Helps interpret the result alongside the imagery it used.
Keeps the underlying scenes available so the answer can be inspected.

What you would gain

Finding the right imagery, normally a specialist task, starts from an ordinary question.
The answer and the picture behind it stay side by side, so an interpretation can be challenged.
Non-specialists can take part in an analysis that would otherwise need an expert to drive.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: This candidate is represented in the existing inventory only. No new functional or PTU verification is claimed.

Choose this if

You have genuine Earth-science or environmental questions and a specialist who can sanity-check answers.
Satellite imagery is your evidence base.

Consider something else if

Your data is business data rather than imagery: see Agentic Unified Data Foundation.
You need a supported product with a support agreement behind it.

01 / Use it for the right job

Where it earns its place.

Planetary Explorer is a public Microsoft open-source application combining a map, natural-language interaction and geospatial tools. Agents translate a question into dataset discovery and STAC queries, load geospatial layers and help interpret results. Start with civilian Earth-science tasks such as vegetation, surface water or imagery comparison.

Best uses

Find suitable imagery for an area and date range, then compare conditions.
Explore land cover, vegetation or water-related questions with a geospatial analyst.

Know the boundary

Imagery coverage, resolution, clouds, acquisition dates and dataset licenses constrain the answer.
The repository is not a supported Microsoft product. Optional integrations and weather stubs are not evidence of validated scientific forecasting.

How people use it

A React/TypeScript application combines an Azure Maps view with a conversational interface. Users investigate actual datasets, locations and map layers. There is no fictional map grid or nonfunctional specialist-review tab on this page; use the upstream application overview for real UI material.

Frame a geographic question
Specify an area, time range and phenomenon, such as comparing surface-water extent between two periods.
Discover and load imagery
The agent/tool backend queries public STAC catalogs and selects relevant scenes or datasets for the map.
Inspect the spatial result
Review rendered layers and interpretation with an analyst, checking dates, resolution and data quality.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The app is distinct from Planetary Computer: App Service hosts the frontend; a Container Apps backend orchestrates geospatial tools, model calls and catalog access.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Map + conversation
React / App Service
Presents the Azure Maps view, questions and returned geospatial context.
Geospatial agents/API
FastAPI / Container Apps
Coordinates dataset discovery, clarification and geospatial tools using the documented agent frameworks.
Public STAC catalogs
Planetary Computer / VEDA
External metadata and imagery sources, subject to each dataset license.
Reasoning and vision
Microsoft Foundry
Interprets questions and analysis context; language output is not a substitute for scientific validation.
Raster and tile tools
GDAL / Rasterio / TiTiler
Processes and renders selected imagery. Inspect the pinned package for the selected tool path.
Basemap and geocoding
Azure Maps
Provides geographic display and location services to the frontend.
Raster artifacts
Azure Blob Storage
Stores intermediate results and ingestion artifacts.
Tenant geospatial data
Optional GeoCatalog / Fabric / optional
Optional customer data routes, not prerequisites for public-catalog exploration.

Read all 7 connections

Map + conversation to Geospatial agents/API
Submit place/time question
Geospatial agents/API to Public STAC catalogs
Search STAC scenes
Geospatial agents/API to Reasoning and vision
Plan and interpret
Geospatial agents/API to Raster and tile tools
Load / analyze / render
Map + conversation to Basemap and geocoding
Display and locate
Raster and tile tools to Raster artifacts
Read/write raster artifacts
Geospatial agents/API to Tenant geospatial data
Optional governed data access

The deployment includes supporting Search, Key Vault, ACR and monitoring; optional Fabric capacity and MPC Pro need explicit configuration.
The optional weather server is documented as a stub. Do not present it as a validated forecast model.
Authentication requires deliberate configuration. Review deployment defaults and do not use region auto-selection without tenant approval.

03 / Prepare the inputs

From your data to useful output.

A location/time question and licensed geospatial data. Public Planetary Computer and NASA VEDA catalogs are documented starting points.

Discover metadata
STAC tools search collections and scene metadata before retrieving imagery; this is not a generic PDF-to-vector ingestion pipeline.
Load and process imagery
Raster tools use geospatial processing and tile rendering to turn selected assets into map-ready layers and intermediate results.
Add tenant data only if needed
Planetary Computer Pro/GeoCatalog and Fabric are optional routes that require their own setup, permissions and live data configuration.

Record dataset, scene date, coordinate reference assumptions, processing choices and any missing/cloud-obscured data.

04 / Run it in your environment

What you need to get running.

The pinned Quick Deploy guide documents GitHub Actions/OIDC and a local PowerShell deployment route.

Code & access

Your team needs

Approved dataset licenses, intended region and model availability
Deployment and app-registration permissions, plus an explicit sign-in design
Separate approvals for any optional Fabric capacity or GeoCatalog integration

Bring approved inputs

A location/time question and licensed geospatial data. Public Planetary Computer and NASA VEDA catalogs are documented starting points.

Budget separately for

App Service, Container Apps and geospatial compute
Foundry models, Azure Maps, Search, storage and monitoring
Optional GeoCatalog/Fabric services and any externally licensed data

No deployment commands run from this site.

GitHub Actions application deployment

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Planetary-Explorer.git accelerator
Set-Location accelerator
git checkout --detach cadb0b0631844bec9bf369ea2a46024dc2bd4cf3
git rev-parse HEAD

Prepare an approved fork and deployment identity
Use QUICK_DEPLOY.md with Azure CLI and GitHub Actions access. In your fork create a deployment branch at the pinned revision. Have the Azure administrator approve the OIDC identity and minimum deployment/RBAC scope; do not automatically grant broad subscription rights.
Configure the GitHub environment
Create the dev environment matching the federated credential subject. Add AZURE_CLIENT_ID, AZURE_TENANT_ID and AZURE_SUBSCRIPTION_ID using its secret settings. Set an approved RESOURCE_GROUP variable; keep ENABLE_AUTO_DEPLOY off during review.
Configure sign-in and infrastructure inputs
Register the single-tenant authentication application and provide AUTH_CLIENT_ID as described in Step 8.3. Confirm the callback URL, allowed users and network posture. Review model creation/routing; leave Fabric capacity, weather services and other paid extensions disabled unless separately approved.
Run the reviewed workflow
In your fork, open Actions > Deploy Planetary Explorer > Run workflow. Select the branch at the reviewed revision and Force deploy all components. Select only approved model and networking inputs. Do not run a mutable default branch or assume the default model uses existing PTUs.
Open the deployed frontend
Wait for all required workflow jobs and runtime services to succeed. Use the application URL from workflow output; test Entra sign-in, map loading and one permitted satellite-search question. Resolve missing permissions or model quota without bypasses.

Verify before sharing

Confirm actual imagery/catalog results, grounded explanation and denied access for an unauthorized user. Verify provider routing and independently record any optional features that were not deployed.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Geospatial/domain specialist
Choose datasets, validate spatial methods and interpret imagery.
AI application CSA
Trace agent/tool calls and distinguish model interpretation from computed results.
Azure platform/data CSA
Review hosting, Maps, storage and optional Fabric/GeoCatalog integration.

Bring to the session

One civilian Earth-science question with an area and time range
Dataset licenses and a known reference result
The analyst who will validate spatial outputs

Agree how to judge success

The selected scene matches the requested geography/time.
Map layers and derived values agree with an independent geospatial check.
Optional/demo data cannot be mistaken for a live tenant integration.

First working session

Trace a question from catalog discovery to a rendered layer, then check the answer against scene metadata and imagery.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Public geospatial catalog adapter (opens in a new tab)
Implements collection listing and scene searches with collection, bounding-box and date/time parameters.
Public and tenant catalog routing tests (opens in a new tab)
Exercises catalog-mode selection and tenant-catalog configuration, guarding against silently substituting public results.

Pinned revision cadb0b0631844bec9bf369ea2a46024dc2bd4cf3. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Identify a bounded specialist use case and validate the actual model-dependent steps.

Evaluation context

This candidate is represented in the existing inventory only. No new functional or PTU verification is claimed.

It is a specialist option, not a general staff-work starting point.
Domain expertise, data availability and permissions determine practical value.

Model capacity and cost

A geospatial workload is not automatically a language-model workload. No PTU demand has been established.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Integration pattern

Bring Your Own Key pilot

Bring an approved model into the developer experience you already use.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A way to use an organization-chosen AI model inside supported developer tools, such as Visual Studio Code or GitHub Copilot. It is configuration, not a new application.
How it works: Add an approved model connection so supported coding requests go to that model. Local developer setup and centrally managed enterprise setup have different authentication, licensing and feature coverage.
Use it for: Let developers keep their familiar editor while the organization evaluates model choice, governance and billing. Confirm the supported route before assuming requests can consume existing PTUs.
Example scenario: Pilot a custom model on explaining a function and drafting its tests, comparing answer quality and available features with the default model.

From input to useful workIllustrative

Developer toolInput
Model routeProcess
AssistanceOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Developer productivity leads, GitHub administrators and platform teams
What you get: A configured model in the chosen client / A route-specific feature and permission matrix / Usage and cost observations for real development tasks
Source & ownership: Microsoft / GitHub platform guidance. View source basis

More on fit, scope and evidence

A way to point developer tools such as Visual Studio Code or GitHub Copilot at a model your organization chooses, instead of only the default one. Two different routes exist — one a developer configures locally, one an enterprise manages centrally — and they differ in licensing, network path and which features keep working.

What you actually receive

A configuration choice inside tools developers already use. There is no application to deploy.

What it does

Adds an organization-chosen model to the model picker in a supported client.
Sends developer requests to that model instead of the default one.
Lets administrators manage which custom models the enterprise may use.

What you would gain

Developers keep the tool they know while the organization decides which model does the work.
Model choice and provider billing become an administrative decision rather than an individual one.
A bounded pilot can compare a preferred model against real development tasks before any rollout.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: No completed integration test establishes an enterprise-ready BYOK path for this portfolio.

Choose this if

Your developers already use a supported client and the only question is which model answers.
You need central control over model choice or provider billing.

Consider something else if

You want a new application for staff rather than a change to developer tooling.
You expect every Copilot feature to work unchanged: coverage depends on the route and the client.

01 / Use it for the right job

Where it earns its place.

BYOK is a model-integration choice, not a separately deployed developer application. GitHub documents two different routes: locally configured models in supported clients, and enterprise-managed custom models served through Copilot. Choose the client and route before making statements about licensing, network paths or feature coverage.

Best uses

Make a preferred model available to a bounded developer pilot.
Centralize enterprise custom-model availability and provider billing controls.

Know the boundary

Enterprise BYOK is public preview, is served through the Copilot API and requires a Copilot Business/Enterprise license and internet access.
Local VS Code BYOK chat and utility tasks can work without a GitHub sign-in or Copilot plan; semantic search, inline suggestions and embedding-dependent features still require a GitHub account. Organization policy can disable local BYOK.

How people use it

Developers use the real model picker in their IDE or supported Copilot client. Enterprise administrators configure custom models in AI controls; local VS Code users configure providers in Manage Language Models.

Choose the integration route
Decide whether the organization centrally exposes models or developers configure approved providers locally.
Select the model in the client
Use the model picker and check that the chosen model supports the tools and context required for the task.
Review the engineering result
Review code changes and run the repository checks. Record feature gaps rather than assuming model substitution preserves every capability.

02 / Under the hood

Components and how they connect.

Two alternatives, not a single pipeline: enterprise-managed requests use the Copilot service; locally configured models are handled client-side.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Repository + IDE
Developer workspace
Provides authorized source context and receives suggested changes.
Enterprise model route
GitHub Copilot service
Serves administrator-configured custom models to licensed enterprise/organization users.
Local model route
Client-side provider
Handles locally configured provider access, subject to client capabilities and organization policy.
Approved model
Foundry / other provider
Receives model requests through the selected route; localhost models are an option on supported local clients.
Engineering acceptance
Review + test environment
Source control, tests and human review determine whether generated code is accepted.

Read all 5 connections

Repository + IDE to Enterprise model route
Enterprise option
Repository + IDE to Local model route
Local option
Enterprise model route to Approved model
Server-side model request
Local model route to Approved model
Client-side model request
Repository + IDE to Engineering acceptance
Review proposed changes

This is a documented integration-path diagram, not new Azure application infrastructure.
A provider choice does not establish provisioned capacity usage; verify the exact deployment, API and geography.

03 / Prepare the inputs

From your data to useful output.

Authorized repository context selected by the developer and the client, not a separate document-ingestion service.

Apply workspace policy
Agree which repositories and files may be included and how client trust/policy settings are enforced.
Configure model access
Use approved credential storage and the documented provider/deployment configuration for the chosen route.
Observe the actual route
Check provider-side usage and task behavior. Enterprise traffic passes through the Copilot service; local BYOK is client-side.

Test chat, editing, tool use and any required context features separately; verify what leaves the developer environment.

04 / Run it in your environment

What you need to get running.

Client/admin configuration using official GitHub and VS Code instructions; no application repository to deploy.

Code & access

Repository not verified for this catalog entry. Use the platform or custom-implementation path below, not a standalone app installer.

Your team needs

The exact client/version and required features; agent chat needs a tool-calling model
Organization model policies and an approved provider route; local models alone do not make every client feature offline
Route-specific licensing, access and credential management; enterprise Foundry configuration needs a deployment URL and model ID

Bring approved inputs

Authorized repository context selected by the developer and the client, not a separate document-ingestion service.

Budget separately for

Provider/model usage
Copilot licensing where required by the selected route
Developer tooling and administration

No deployment commands run from this site.

Platform configuration

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Choose the client and route
Agree whether the pilot uses centrally managed enterprise custom models or local VS Code BYOK. Record client version, licensing, policy owner and required chat/tool-calling features; this does not replace inline completions.
Prepare the approved model endpoint
The Azure owner supplies the deployment URL, deployment/model ID, supported API and authentication through an approved secret channel. Verify geography and PTU deployment type; a Foundry account name alone is insufficient.
Configure enterprise custom models
An enterprise administrator follows the linked guide: open enterprise AI controls, add the provider credential and models, then grant the intended organizations access. Enable applicable custom-model policies; do not distribute the provider key in source code.
Or configure local VS Code
In Chat, open the model picker and Manage Language Models, select the provider and enter its required endpoint/model/authentication settings. Use the linked VS Code guide for provider-specific fields. Local configuration remains subject to organization policy.
Select the model and perform a bounded task
Reopen the client if needed, select the configured model and use a permitted repository for chat and one reviewed agent/tool task. If the model is absent, resolve policy, provider or API compatibility rather than claiming setup succeeded.

Verify before sharing

Correlate the task with usage on the intended Azure deployment. Test organization restrictions and credential rotation. Record which client features worked; do not infer all Copilot features or offline operation.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

GitHub specialist
Clarify supported clients, enterprise policies and feature coverage.
Developer productivity CSA
Choose tasks and measure engineering usefulness.
Identity/network engineer
Review credential handling and the local versus service-mediated data path.

Bring to the session

Client versions and GitHub plan/policies
An approved provider and intended model deployment
Representative edit, test and tool-use tasks

Agree how to judge success

The client uses the intended model route.
Required features work or their gaps are documented.
Code quality, provider cost and governance are measured separately.

First working session

Draw the chosen network/data route and create a feature matrix before configuring the first pilot user. Ask the Microsoft account team about GitHub/developer-productivity assistance; availability and commercial terms must be agreed.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Platform references explain the integration or design option only; they do not verify a portfolio-specific package.

Deployment notes & implementation considerations

Package and integration

Test a bounded developer pilot with approved credentials handling and a documented feature matrix.

Evaluation context

No completed integration test establishes an enterprise-ready BYOK path for this portfolio.

Local configuration and enterprise-managed deployment are different integration problems.
BYOK does not provide all GitHub Copilot features; feature availability depends on the tool and supported model path.

Model capacity and cost

A supported tool may use a compatible provisioned deployment. Authentication, API support and enterprise policy need validation.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Guided enablement workshop

MCP security workshop

Teach engineers to secure the tool connections that every AI agent depends on.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A guided training workshop on securing the connections between AI assistants and their tools or data, using Model Context Protocol (MCP). It is learning material, not a business app.
How it works: Engineers work through progressive exercises: inspect an intentionally insecure example, observe the weakness, apply an identity, gateway or safety control, then check that the control blocks the problem.
Use it for: Build practical skills for reviewing agent integrations before rollout. Exercises must stay in disposable, isolated environments with no production connectivity; they are not a PTU-utilization workload.
Example scenario: In an isolated lab, compare a tool connection before and after an access control is applied, then document what changed and how it was verified.

From input to useful workIllustrative

Lab serverInput
Inspect risksProcess
Practice controlsOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Application security engineers, platform teams and any developer exposing tools to an AI agent
What you get: Hands-on experience of a realistic attack and its fix / A reviewed security checklist for agent tool integrations / A shared risk vocabulary across the engineering team
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A security course for engineers, built as a climb through progressive camps. Its subject is the connection between an AI agent and the tools or data it reaches — the Model Context Protocol, or MCP, now the common way to make that connection. Each camp stands up something insecure, attacks it, fixes it with an Azure control, then proves the attack no longer works.

What you actually receive

A hands-on training workshop in a repository. It is deliberately not a product.

What it does

Walks engineers through staged exercises covering identity, gateway controls, input and output safety, and monitoring.
Deploys deliberately vulnerable servers and supplies working exploits against them.
Applies the control that defeats each attack, then re-runs the attack to prove it.
Maps its exercises to a published list of the top MCP risks.

What you would gain

Engineers who have broken something insecure themselves review agent tooling differently afterwards.
A team gains shared vocabulary and a checklist, so security review stops depending on one person.
Weaknesses are found in a training environment instead of a shared one.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: This is a guided training workshop rather than a deployable business application. It was reviewed from public source; no camp was deployed or exploited here.

Choose this if

Your teams are exposing tools or data to AI agents, or are about to.
You can provide a disposable, isolated environment with no production connectivity.

Consider something else if

You are looking for software to deploy: this produces skilled engineers, not an application.
You cannot isolate the environment: it deploys working vulnerabilities by design.

01 / Use it for the right job

Where it earns its place.

A staged, hands-on workshop for securing Model Context Protocol servers on Azure. MCP is the emerging standard by which AI applications reach external tools and data, which makes it a security boundary worth treating seriously. The workshop is organised as a climb through progressive camps covering identity, gateway controls, input and output safety, and monitoring, and it aligns its exercises to a published list of the top MCP risks.

Best uses

Run a time-boxed engineering enablement session before agent tooling reaches a shared environment.
Give a team a shared vocabulary and checklist for reviewing a proposed agent tool integration.

Know the boundary

It deliberately deploys insecure servers and working exploits so that learners can break them. Run it only in a disposable, isolated environment with no production connectivity and no real data.
It is training, not a product: it produces skilled engineers, not a deployable business application.
Completing the workshop does not certify any application, environment or organisation as secure.
Its exercises reflect a fast-moving protocol and a published risk list at a point in time; both will continue to change.

How people use it

Engineers work through numbered camps in a repository, each following the same rhythm: stand up something vulnerable, attack it from an ordinary agent tool client, apply the Azure control that prevents the attack, then re-run the attack to confirm it now fails.

Deploy the weak version
Stand up the deliberately vulnerable server for the camp in an isolated environment.
Break it on purpose
Run the provided exercise from an agent tool client and observe exactly what an attacker gains.
Apply and prove the fix
Introduce the Azure control for that risk, then repeat the attack and confirm it is now blocked.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

A deliberately weak tool server sits at the centre; each camp adds a further layer of control and then re-tests the original attack.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Workshop participant
Engineer in a guided session
Works through each camp and performs the exercises.
Agent tool client
Editor-based MCP client
Connects to the practice server exactly as a real AI agent would.
Guided attack exercises
Provided exploit scripts
Demonstrate concretely what each weakness allows.
Practice tool server
MCP server, weak and hardened
The exercise target; each camp ships an insecure and a secured version.
Gateway and traffic controls
API gateway and network isolation
Mediates access and restricts who can reach the tool server.
Identity and secret handling
Entra ID, managed identity, Key Vault
Replaces shared secrets with verified identity and managed credentials.
Logging and detection
Monitoring and threat detection
Makes attacks visible after the preventive controls are in place.

Read all 6 connections

Workshop participant to Agent tool client
Work through each camp
Agent tool client to Practice tool server
Call the practice tools
Practice tool server to Guided attack exercises
Expose the deliberate weakness
Practice tool server to Identity and secret handling
Apply identity and secret controls
Identity and secret handling to Gateway and traffic controls
Add gateway and traffic restrictions
Identity and secret handling to Logging and detection
Emit security signals for detection

The camps are cumulative: identity, gateway, input and output safety, and monitoring are layered rather than alternatives.
The vulnerable servers are a teaching device, not a template. Never promote workshop code into a shared environment.
This entry describes a reviewed public workshop; no camp was deployed or exploited in this evaluation.

03 / Prepare the inputs

From your data to useful output.

Disposable exercise environments and synthetic tool data only. No production system, credential or real record should be reachable from the workshop.

Isolate the environment
Use a throwaway environment with no route to production services or real data.
Work the camps in order
Each stage assumes the controls from the previous one, building layered defence.
Tear it down
Remove the vulnerable exercise deployments as soon as the session ends.

The measure of success is that the previously working attack fails after the fix, demonstrated live rather than asserted.

04 / Run it in your environment

What you need to get running.

Clone the pinned workshop and work through the camps locally against a disposable Azure environment, following the published guide.

Code & access

Your team needs

A disposable, isolated environment with no production connectivity and no real data
An editor with an agent tool client, plus Azure CLI, Python and Node tooling
An agreed facilitator, time box and teardown owner

Bring approved inputs

Disposable exercise environments and synthetic tool data only. No production system, credential or real record should be reachable from the workshop.

Budget separately for

Modest, short-lived Azure resources for the exercise environments
Engineering time for the guided session
Little or no model usage; this is a security workshop rather than a model workload

No deployment commands run from this site.

Isolated training environment

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/Azure-Samples/sherpa.git accelerator
Set-Location accelerator
git checkout --detach 12be921ec85bd915105d9c6b5335cffe8c680966
git rev-parse HEAD

Verify isolation before setup
Use a disposable environment with synthetic data and no production connectivity. The workshop intentionally contains vulnerable servers. Prepare the pinned prerequisites, including Python 3.10+, uv and an MCP-capable editor; later Azure camps need their own permissions/budget.
Prepare Base Camp
From the repository root, enter camps\base-camp and use its shared uv environment. Review package feeds first; do not start any vulnerable server on a shared/public host.
Show commands
```
Set-Location camps\base-camp
uv sync
```
Run the local exercise
Use the linked Base Camp Setup instructions to start the vulnerable server and its provided test in separate terminals inside the isolated environment. Keep the exercise target local and use only its synthetic fixtures.
Apply the secure counterpart
Stop the vulnerable process, configure secure-server from its .env.example as documented, start it and run the supplied secure validation. Keep tokens in the isolated environment, not in source or reports.
Continue and close deliberately
Proceed camp by camp using each README and its Azure setup instructions. Record the before/after control result; stop local processes and have the teardown owner remove only the authorized exercise resources when the session ends.

Verify before sharing

Show that the intended attack fails after the control, then confirm no vulnerable endpoint or billable exercise resource remains. Workshop completion is training evidence, not production security certification or a PTU workload.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Application security engineer
Facilitate the exercises and translate them into review criteria.
Platform or identity engineer
Map the workshop controls onto the tenant’s approved identity and network patterns.
Engineering lead
Own the resulting checklist and require it for new agent tool integrations.

Bring to the session

A disposable environment approved for deliberately vulnerable deployments
A real proposed agent tool integration to assess afterwards
An agreed facilitator and teardown owner

Agree how to judge success

Every attack demonstrated is shown to fail after its fix is applied.
No vulnerable exercise deployment survives the session.
The team leaves with written criteria applied to its own agent tool integrations.

First working session

Complete one camp end to end, then assess a real proposed tool integration against the control that camp introduced.

06 / Inspect the basis

Code, guides and references.

Public source review: 2026-09-15. Documentation and code inspection are not functional testing or deployment certification.

Application overview and upstream experience (opens in a new tab)
Deployment instructions (opens in a new tab)
Architecture and processing design (opens in a new tab)
Hosting and runtime source (opens in a new tab)
Base camp environment setup (opens in a new tab)
Each camp is a self-contained exercise environment. The starting camp contains both a deliberately weak server and a hardened counterpart so learners can compare them directly.

Pinned revision 12be921ec85bd915105d9c6b5335cffe8c680966. Public upstream starting point, not the tested private adaptation. Review its license and operating requirements.

Deployment notes & implementation considerations

Package and integration

Run it as an isolated, time-boxed engineering enablement session in a disposable environment with no production connectivity.

Evaluation context

This is a guided training workshop rather than a deployable business application. It was reviewed from public source; no camp was deployed or exploited here.

It intentionally deploys insecure servers so learners can exploit them; it must never be run in a shared, production or internet-reachable environment.
Completing a workshop teaches practices; it does not certify any application or tenant as secure.

Model capacity and cost

A training workshop consumes little or no model capacity and is not a basis for reserved capacity. Its value is reducing the risk of the agent and tool integrations that other candidates depend on.

A reference design is not a deployment certification. Confirm licensing, supported components, identity, network design and operations ownership for your tenant.

Platform accelerator

Private platform baseline

Establish an approved environment before onboarding an AI application.

1 / Understand the solutionProblem, people, workflow and architecture 2 / Run it in your environmentPrerequisites, costs, setup and assistance

What it is: A set of infrastructure templates for the cloud environment behind an AI application. It gives platform engineers a starting design, not a chatbot or staff-facing tool.
How it works: Engineers review configuration for hosting, identity, networking, monitoring, AI and search services, plus optional data and governance integrations, before provisioning an approved environment.
Use it for: Make platform decisions explicit and reusable when onboarding AI workloads. Prefer an existing approved foundation; this upstream is unmaintained and needs a maintenance owner or replacement.
Example scenario: Before hosting a document assistant, compare its service requirements with the template and your existing environment, then identify which approved components can be reused.

From input to useful workIllustrative

RequirementsInput
InfrastructureProcess
ValidationOutput to evaluate

Intended workflow, not a product screenshot or a verified result. See the guide for limitations.

Who it helps: Azure platform engineers, AI application architects and data platform owners
What you get: Reviewed infrastructure configuration / Application onboarding plan / Operational acceptance checklist
Source & ownership: Microsoft-owned public repository. View source basis

More on fit, scope and evidence

A reference for the groundwork an AI application needs: network, identity, monitoring, AI and search services, expressed as configuration your platform team can read and challenge. Prefer the existing approved tenant foundation. This package is neither a turnkey production platform nor proof of production readiness, and a new deployment needs someone explicitly accountable for maintenance or an approved replacement.

What you actually receive

Infrastructure reference templates for engineers, not a business application. Upstream is no longer maintained; new deployment requires a named maintenance owner or approved replacement.

What it does

Provisions a configurable Azure environment from reviewed templates.
Sets up AI and search services for an application to use.
Offers optional data-platform and governance integrations, each with its own prerequisites.
Leaves the business application itself to be onboarded separately.

What you would gain

Environment decisions are made once, reviewably, instead of improvised per project.
Platform responsibilities and application responsibilities stay clearly separated.
The configuration can be argued with before anything is created.

How much of that is proven?

Historical evaluation, not a guarantee for your deployment: The platform baseline compiled. That is a build result, not an end-to-end outcome or a validated user experience.

Choose this if

Your platform team needs an infrastructure reference to compare with the approved tenant foundation.
Any new deployment has a named maintenance owner or approved replacement and separate application acceptance checks.

Consider something else if

You are looking for something staff can use: this has no end-user experience at all.
Your tenant already has an approved landing-zone pattern: reuse it instead of duplicating services.
You need a supported turnkey production platform: choose an approved maintained foundation, not this reference alone.

01 / Use it for the right job

Where it earns its place.

An Azure deployment foundation built around AI Landing Zone, with Foundry, Search and configurable data, networking and governance services. Fabric and Purview integrations require deliberate configuration and prerequisites. This is infrastructure for hosting an application, not a turnkey business application or proof of production readiness.

Best uses

Review an application landing environment with the tenant platform team.
Plan AI and retrieval services with optional Fabric and Purview integration.

Know the boundary

The repository name does not establish production certification or application readiness.
Checked-in parameters are opinionated; do not assume every service has private networking enabled.
Fabric, Purview and PostgreSQL mirroring have separate prerequisites and configuration.

How people use it

An engineering deployment workflow using azd, Bicep, configuration files and Azure service interfaces. It is not a packaged business-user application.

Define application requirements
Identify dependencies, identity boundaries, data access and the operating model.
Review infrastructure configuration
Inspect active parameters, the AI Landing Zone submodule and provisioning hooks before selecting services.
Validate the approved environment
Check connectivity, identity, observability and application onboarding in an authorized pilot.

Open public repository (pinned)Arrange access or deployment help

02 / Under the hood

Components and how they connect.

The package provisions a platform foundation; business-application delivery and acceptance remain separate responsibilities.

Source-informed component architectureArrows show data or control flow. Scroll the diagram on narrow screens, or read the component responsibilities and connections below.

Reviewed configuration
azd + Bicep parameters
Controls deployment scope and optional integrations.
Infrastructure foundation
AI Landing Zone
Provides configurable hosting, identity, network and supporting resources.
AI and retrieval services
Foundry + Azure AI Search
Supplies configured AI and search capabilities for an application.
Optional data platform
Microsoft Fabric / optional
Capacity, workspace and lakehouse automation require explicit prerequisites.
Optional catalog integration
Microsoft Purview / optional
Requires an existing account and appropriate collection permissions.
Application onboarding
Separate application workload / optional
Proposed integration boundary; the foundation is not the business application.

Read all 5 connections

Reviewed configuration to Infrastructure foundation
Provision approved configuration
Infrastructure foundation to AI and retrieval services
Configure platform services
Infrastructure foundation to Optional data platform
Optional Fabric automation
Optional data platform to Optional catalog integration
Optional governance integration
AI and retrieval services to Application onboarding
Connect the selected application

Review active parameter values as well as template defaults. The checked-in configuration enables network isolation while separately configuring PostgreSQL without isolation.
Successful provisioning and optional integrations are not evidence of production certification.

03 / Prepare the inputs

From your data to useful output.

Approved deployment configuration and application requirements. Business-data ingestion depends on the selected integrations.

Select platform scope
Decide which AI, retrieval, storage and optional data-platform capabilities are required.
Configure optional data routes
Review Fabric workspace, lakehouse, Search and Purview automation only for integrations explicitly in scope.
Validate access
Confirm identities and data permissions before loading permitted data.

Provisioned resources and completed scripts do not prove that application data access works correctly.

04 / Run it in your environment

What you need to get running.

azd/Bicep provisioning with an initialized AI Landing Zone submodule and package automation hooks.

Code & access

Your team needs

Named maintenance owner or approved replacement for this no-longer-maintained accelerator before any new deployment
Approved deployment identity, service availability and budget
Required azd, Azure CLI and PowerShell tooling plus initialized submodules
Separate permissions and configuration for selected Fabric or Purview integration

Bring approved inputs

Approved deployment configuration and application requirements. Business-data ingestion depends on the selected integrations.

Budget separately for

Selected Azure hosting and AI services
Search, storage and networking
Optional Fabric, governance and database services

No deployment commands run from this site.

Infrastructure foundation - maintenance gate

Instructions reviewed 2026-09-25; source-inspected, not deployment-tested. Open full deployment manual (opens in a new tab)

Approval required; commands do not run here. Read the shared execution and recovery guidance.

Open the step-by-step setup guide

Get the reviewed source revision (PowerShell)

git clone https://github.com/microsoft/Deploy-Your-AI-Application-In-Production.git accelerator
Set-Location accelerator
git checkout --detach 1ed62d982f777b85f3fe281adfd7150921ccd9ce
git rev-parse HEAD

Resolve ownership and initialize pinned submodules
Prefer the tenant's existing foundation. If this unmaintained reference is approved, assign a maintenance owner and use PowerShell 7+, Azure CLI, azd and Bicep. Initialize the recorded submodule commits; never pull their latest main.
Show commands
```
git submodule update --init --recursive
```

Initialize the approved environment

Sign in to both CLIs. Use the intended tenant, subscription and approved principal; the principal value is an Entra object ID, not an application client ID.

Show commands

azd auth login
az login
azd env new "<environment-name>"
azd env set AZURE_TENANT_ID "<tenant-id>"
azd env set AZURE_PRINCIPAL_ID "<principal-object-id>"
azd env set AZURE_SUBSCRIPTION_ID "<subscription-id>"

Review active feature flags
Edit infra\main.bicepparam and review hooks. Explicitly choose Fabric capacity/workspace presets (none or approved existing resources where appropriate), optional Purview and database integrations. Check PostgreSQL networking separately from general network isolation.
Provision and inspect hook results
Run only after cost/network approval. Validate every enabled hook, not just Azure resource creation. Use an authorized private-network workstation for private data-plane operations; do not temporarily open protected services.
Show commands
```
azd up
```
Validate the selected onboarding path
Use the manual's post_deployment_steps.md. For an enabled Fabric/Search route, load approved PDFs into the bronze lakehouse Files/documents location, check indexing and configure the Foundry playground data connection. Application publishing is a separate linked step.

Verify before sharing

Check identity, connectivity, indexing and enabled integrations. Record disabled features explicitly. This delivers an infrastructure foundation, not a completed business application or production certification.

Interested in this solution?

Use the runbook with your engineers, or take this solution and its requirements into a scoped implementation discussion.

05 / From selection to adoption

Deploy with your team—or with our help.

Azure platform architect
Own landing-zone integration, networking and deployment permissions.
AI application architect
Define workload dependencies and acceptance checks.
Data platform specialist
Review optional Fabric, Purview and database integration.

Bring to the session

Intended application architecture
Approved network and identity requirements
Service budget and operating owners

Agree how to judge success

Every enabled service has an approved purpose and owner.
Connectivity and authorization are tested for the intended workload.
Optional integrations are verified or explicitly excluded.

First working session

Trace one application requirement through active parameters, provisioning hooks and operational acceptance checks.