Building a Smart Conference Assistant with .NET’s Composable AI Stack: Your Questions Answered

Introduction

The latest .NET ecosystem introduces a unified, composable set of AI building blocks that let you create intelligent applications without juggling multiple unrelated libraries. In this Q&A, we dive into ConferencePulse—a live conference assistant built with these tools. We’ll explain how Microsoft.Extensions.AI, VectorData, data ingestion pipelines, the Model Context Protocol (MCP), and the Agent Framework work together to make an interactive session app that generates polls, answers questions in real time, and produces session summaries. Each question below tackles a core aspect of the app, from architecture to live AI features.

1. What is ConferencePulse and what problem does it solve?

ConferencePulse is a Blazor Server application designed for live conference sessions. It replaces traditional slide‑driven presentations with an interactive experience where attendees join via QR code, participate in AI‑generated polls, and ask questions that are answered in real time using a Retrieval‑Augmented Generation (RAG) pipeline. The app solves the challenge of keeping audiences engaged while providing presenters with immediate insights from engagement data. It automates the preparation process: point the app at a GitHub repository, and it downloads markdown content, processes it through an ingestion pipeline, and builds a searchable knowledge base. Polls, talking points, and Q&A answers are all grounded in that content, ensuring relevance and consistency. By leveraging .NET’s composable AI stack, ConferencePulse demonstrates how developers can build sophisticated AI features without stitching together incompatible libraries from different ecosystems.

2. Which components make up the .NET composable AI stack used in this app?

The app relies on six key components from the .NET composable AI stack:

• Microsoft.Extensions.AI – Provides a unified IChatClient abstraction that works across providers like OpenAI, Azure OpenAI, Ollama, and Foundry Local.
• Microsoft.Extensions.DataIngestion – Handles the pipeline that downloads and processes markdown content from GitHub into a vector‑searchable format.
• Microsoft.Extensions.VectorData – Offers a consistent abstraction for vector databases (Qdrant is used here) to store and retrieve embeddings.
• Model Context Protocol (MCP) – Standardizes tool definitions and client‑server communication for AI agents.
• Microsoft Agent Framework – Enables the creation of multi‑agent workflows that run concurrently for tasks like generating insights and summaries.
• .NET Aspire – Orchestrates cloud dependencies such as Qdrant, PostgreSQL, and Azure OpenAI services.

These building blocks allow the app to swap providers, scale ingestion, and coordinate agents without breaking changes when underlying libraries update.

3. How does the app generate live polls based on session content?

When a presenter starts a session, the app uses Microsoft.Extensions.AI to call an LLM with a prompt that includes the session’s knowledge base (extracted from the GitHub repository). The model generates multiple‑choice poll questions that are relevant to the current topic. Polls are displayed in real time via SignalR, and attendees vote through the Blazor UI. The AI is instructed to create questions that both test understanding and spark discussion. As the session evolves, the presenter can request new polls on the fly, and the system re‑fetches the latest context from the vector database to keep questions current. The entire process is abstracted behind IChatClient, so the app can switch between Azure OpenAI and a local Ollama model simply by changing configuration—no code changes required.

4. How does the audience Q&A feature work with RAG and vector search?

Attendees submit questions through the app, which are then processed using a Retrieval‑Augmented Generation (RAG) pipeline. First, the question is embedded using the same embedding model used during ingestion. Microsoft.Extensions.VectorData performs a similarity search in Qdrant against the session knowledge base (which includes Microsoft Learn docs and GitHub wiki content). The top matching chunks are retrieved. Next, those chunks and the original question are passed to an LLM via IChatClient with a prompt instructing the model to answer based solely on the retrieved context. The answer is returned to the attendee in real time. This ensures answers are grounded in verified content and reduces hallucination. The entire RAG orchestration is handled by the DataIngestion and VectorData extensions, keeping the code clean and provider‑agnostic.

5. How are auto‑generated insights and session summaries created?

Two agentic workflows run concurrently using the Microsoft Agent Framework. One agent analyzes poll results and identifies trends (e.g., shifting opinions or common misconceptions). Another agent examines audience questions for recurring themes or difficult topics. Each agent uses a specific set of tools exposed through Model Context Protocol (MCP) to query the vector store and call LLMs. When the presenter ends the session, a third orchestrator agent merges the findings from these agents into a concise session summary. The summary includes key discussion points, notable insights, and an overall engagement score. The multi‑agent design allows parallel processing, making the summary available almost instantly after the session concludes.

6. What is the overall architecture of ConferencePulse?

ConferencePulse is built as a .NET Aspire application with five main projects:

• ConferenceAssistant.Web – Blazor Server UI handling live updates via SignalR and orchestrating user interactions.
• ConferenceAssistant.Core – Contains domain models, interfaces, and session state management.
• ConferenceAssistant.Ingestion – Implements the data ingestion pipeline and vector search operations using Microsoft.Extensions.DataIngestion and VectorData.
• ConferenceAssistant.Agents – Hosts the multi‑agent workflows and tools for insights/summary generation.
• ConferenceAssistant.Mcp – Provides MCP server endpoints and client integration for tool definitions.
• ConferenceAssistant.AppHost – The Aspire orchestrator that wires up Qdrant, PostgreSQL, and Azure OpenAI services.

The app runs on .NET 10 and leverages Aspire for cloud resource management and local development. This modular structure makes each component independently testable and deployable.

7. How does the .NET composable AI stack simplify development compared to stitching separate libraries?

Traditionally, adding AI features to .NET apps meant juggling different SDKs for each AI provider, vector database, and agent framework. Each had its own API patterns and breaking changes. The composable stack solves this by offering stable abstractions: IChatClient for LLMs, IVectorStore for vector databases, and DataIngestionPipeline for ingestion. These interfaces are designed to be provider‑agnostic. For example, you can swap from Azure OpenAI to Ollama by changing a configuration entry, without altering any application code. The Model Context Protocol standardizes agent tool definitions, while the Agent Framework provides a consistent way to orchestrate multi‑agent workflows. The result is drastically reduced code coupling, easier testing, and faster iteration. ConferencePulse itself was built in weeks, not months, precisely because the building blocks work seamlessly together.

Back to top