Architecture | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se celebra del 11 al 15 de mayo de 2026 en el Barbican Centre de Londres. La conferencia principal de 3 días es de martes a jueves, con talleres opcionales de día completo el lunes y el viernes.

Con 78 sesiones y 14 talleres, es una de las conferencias más completas para desarrolladores en Europa.

Temas

Pensamiento Arquitectónico
Código Funcional en C# 13
Diseño Serverless
IA Semántica
Azure Kubernetes Services
Estrategias Lean DevOps
The Model Context Protocol (MCP)
IA Agéntica en .NET
Refactorizando el Monolito
Programar Más Rápido con LLMs
Criptografía en un Mundo Post-Cuántico
Desarrollo Local First

Ponentes

Elenco de primer nivel incluyendo a Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm y Raju Gandhi.

Entradas e información

El 98% de los asistentes de SDD 2025 calificaron la experiencia general como buena, muy buena o excelente.

Crear una app de conferencias con IA usando la pila componible de .NET

Emiliano Montesdeoca — Wed, 06 May 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Crear una app de conferencias con IA usando la pila componible de .NET — Microsoft creó ConferencePulse, una app Blazor Server para sesiones de conferencias en vivo, combinando cinco bibliotecas de extensión de .NET. La usaron en el MVP Summit.

Qué hace ConferencePulse

ConferencePulse se ejecuta durante las sesiones en vivo y proporciona: encuestas generadas por IA a partir del contenido de la sesión, preguntas y respuestas del público con un pipeline RAG que extrae de una base de conocimiento en vivo, insights generados automáticamente y resúmenes de sesiones producidos por múltiples agentes de IA concurrentes. La pila es .NET 10, Blazor Server, Aspire, dividida en cinco proyectos: Web, Core, Ingestion, Agents, Mcp y AppHost.

Microsoft.Extensions.AI: una abstracción para todo

IChatClient es la abstracción unificada — se configura una vez y la misma interfaz funciona para Azure OpenAI, OpenAI, Anthropic o cualquier otro proveedor. Seis líneas para obtener un cliente totalmente configurado con invocación de funciones, rastreo OpenTelemetry y middleware de registro:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

El mismo IChatClient se reutiliza más adelante para el paso de enriquecimiento de la ingesta de datos — no se necesita un cliente separado para eso.

Pipeline de DataIngestion

El contenido de la sesión fluye a través de un pipeline: MarkdownReader → HeaderChunker (500 tokens, 50 tokens de solapamiento) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Los enriquecedores usan el mismo IChatClient para generar resúmenes y extraer palabras clave antes de la indexación. Las preguntas del público, los pares de preguntas y respuestas y los resultados de las encuestas se ingieren en tiempo real a medida que avanza la sesión — la base de conocimiento crece durante la charla.

VectorData: búsqueda independiente del proveedor

VectorStoreCollection.SearchAsync() funciona igual tanto si el almacén subyacente es Qdrant como Azure AI Search. La búsqueda híbrida (vector + texto completo) es compatible. El pipeline RAG para preguntas y respuestas del público consulta esta colección y obtiene fragmentos relevantes para pasar como contexto al cliente de chat.

MCP: contenido de la sesión como herramientas

El contenido de la sesión se expone a través de MCP para que cualquier cliente compatible con MCP pueda acceder a él. Tanto el servidor como el cliente están implementados — el servidor expone el conocimiento de la sesión como herramientas MCP, y el cliente permite llamar a esas herramientas desde dentro del pipeline del agente.

Agent Framework: resumen multi-agente en paralelo

El resumen de la sesión es generado por tres agentes que se ejecutan de forma concurrente — PollSummaryAgent, QuestionSummaryAgent e InsightSummaryAgent — y luego se fusionan. Esto utiliza el patrón de chat en grupo o ejecución paralela de Microsoft Agent Framework. Cada agente maneja una preocupación; el orquestador fusiona las salidas.

El principio de diseño

El post hace un punto que vale la pena recordar: usa la herramienta más simple que se adapte. Llamadas directas a IChatClient para tareas de generación simples. Llamada de herramienta/función para la extracción de datos estructurados. Agentes completos solo cuando necesitas razonamiento autónomo de múltiples pasos. La superposición de bibliotecas lo enforza — puedes usar Microsoft.Extensions.AI sin incluir el Agent Framework completo.

Consulta el post completo para la estructura completa del proyecto y los enlaces al código fuente.

¿Dónde Recuerda las Cosas tu Agente? Guía Práctica sobre el Almacenamiento del Historial de Chat

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Cuando construyes un agente IA, dedicas la mayor parte de tu energía al modelo, las herramientas y los prompts. La pregunta de dónde vive el historial de conversación parece un detalle de implementación — pero es una de las decisiones arquitectónicas más importantes que tomarás.

Determina si los usuarios pueden bifurcar conversaciones, deshacer respuestas, reanudar sesiones después de un reinicio, y si tus datos salen alguna vez de tu infraestructura. El equipo de Agent Framework publicó un análisis en profundidad y vale la pena entender el panorama completo.

Dos patrones fundamentales

Gestionado por el servicio: el servicio de IA almacena el estado de la conversación. Tu app mantiene una referencia (un ID de hilo, un ID de respuesta) y el servicio incluye automáticamente el historial relevante en cada solicitud. Más simple de configurar. Menos control.

Gestionado por el cliente: tu app mantiene el historial completo y envía mensajes relevantes con cada solicitud. El servicio no tiene estado. Controlas todo.

Gestionado por servicio: lineal vs bifurcación

Lineal (hilo único): los mensajes forman una secuencia ordenada. Puedes añadir pero no bifurcar. Ideal para chatbots y flujos simples. Malo para “inténtalo de nuevo” o exploración paralela.

Con capacidad de bifurcación: cada respuesta tiene un ID único, y las nuevas solicitudes pueden referenciar cualquier respuesta anterior como punto de continuación. Esto es lo que soporta la API de Responses (Microsoft Foundry, Azure OpenAI, OpenAI). Permite bifurcar conversaciones y construir flujos de “deshacer”.

Cómo Agent Framework abstrae esto

// C# — funciona igual independientemente del proveedor
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Me llamo Alice.", session);
var second = await agent.RunAsync("¿Cuál es mi nombre?", session);

# Python
session = agent.create_session()
first = await agent.run("Me llamo Alice.", session=session)
second = await agent.run("¿Cuál es mi nombre?", session=session)

La sesión maneja las diferencias subyacentes. Este desacoplamiento es valioso para experimentar con diferentes proveedores sin reescribir tu código.

Referencia rápida de proveedores

Proveedor	Almacenamiento	Modelo	Compactación
OpenAI/Azure Chat Completions	Cliente	N/A	Tú
Foundry Agent Service	Servicio	Lineal	Servicio
Responses API (por defecto)	Servicio	Bifurcación	Servicio
Responses API (`store=false`)	Cliente	N/A	Tú
Anthropic Claude, Ollama	Cliente	N/A	Tú

Cómo elegir

¿Necesitas bifurcación o “deshacer”? → Responses API gestionado por servicio
¿Necesitas soberanía total de datos? → Gestionado por cliente con proveedor respaldado por base de datos
¿Es un chatbot sencillo? → Lineal gestionado por servicio está bien
¿Necesitas portabilidad entre proveedores? → Gestionado por cliente da portabilidad

Lee el post completo para el árbol de decisión completo y los detalles de la API de Conversations.