Puntos clave
- Guarda por cada turno de la sesión un esquema normalizado de eventos de actividad; las burbujas del chat son solo una representación.
- Trata los chips y contadores de la interfaz únicamente como proyecciones de ese almacén, nunca como incrementos de un spinner.
- Cuenta las búsquedas de conocimiento MCP aparte de las herramientas genéricas; las preguntas sobre el corpus necesitan su propia etiqueta.
- Propaga los ids de correlación para que el shell, la API, Foundry y App Insights cuenten una sola historia.
- Publica un panel de depuración protegido por roles que muestre los eventos junto a los spans de la plataforma.
- Deja por escrito la retención, el enmascaramiento y el acceso para auditoría antes del lanzamiento.
Soporte abre una sesión. La interfaz dice dos búsquedas y seis herramientas. Las trazas de Foundry muestran otra cosa. App Insights cuenta una tercera historia. Nadie sabe si el agente buscó en el conocimiento, alucinó una ruta de cita o si el contador mintió. Eso no es un bug cosmético. Es una superficie del producto que falta.
Las líneas de tiempo de actividad tienen que cuadrar las trazas de la plataforma, las búsquedas de conocimiento MCP y los contadores de la interfaz. Guarda eventos normalizados, no solo burbujas de chat. Cuenta las búsquedas de conocimiento aparte de las invocaciones de herramientas genéricas. En los agentes de conocimiento de alto riesgo, la trazabilidad forma parte de la política escrita.
Modelo con nombre: guardar → proyectar → cuadrar
- Guardar: eventos de actividad estructurados por turno (nombre de la herramienta, conocimiento o genérica, estado, latencia, ids de correlación y argumentos enmascarados según permita la política).
- Proyectar: los chips y agregados de la interfaz se calculan solo a partir de ese almacén. Simplificar, todo lo que quieras. Inventar, nunca.
- Cuadrar: las trazas de Foundry y las transacciones de App Insights tienen que coincidir con los mismos ids y recuentos; las pruebas detectan la deriva cuando una ruta nueva de herramienta se olvida de emitir.
- Registro: los eventos son el sistema de registro para soporte. Las burbujas y los chips de resumen son proyecciones de ese registro.
Figura 1. Guardar, proyectar, cuadrar. Si no puedes explicar las llamadas a herramientas, tienes una piel de chat sobre un runtime opaco.
Contexto y restricción
Imagina un shell de agentes en el que el panel de depuración y los chips de actividad pulidos no coinciden. Los ingenieros confían en las trazas. Los usuarios confían en los chips. Soporte no confía en ninguno. El tiempo de los incidentes se dispara porque el producto no puede explicarse a sí mismo.
Las trazas de Foundry (o equivalente), las búsquedas de conocimiento MCP y los resúmenes de la interfaz tienen que compartir un modelo de eventos normalizado. La interfaz puede simplificar. No puede inventar. Un panel de depuración apoyado en Foundry más App Insights solo acorta los incidentes cuando los mismos identificadores cosen el chat, las herramientas y los spans de la plataforma.
Los chips del shell solo sirven cuando el mapa de la aplicación y el almacén de eventos cuentan la misma historia. Los contadores de la interfaz por sí solos no son un registro de auditoría. Guarda los eventos y cuádralos con las trazas de la plataforma. El mapa y las vistas de transacciones de Application Insights solo sirven para soporte cuando los ids de operación cosen los spans del shell, la API y Foundry. Consulta Microsoft Learn: correlación en Application Insights y la introducción a Application Insights.
Diseño
1. Trata los contadores de la interfaz como proyecciones de eventos guardados
"2 búsquedas / 6 herramientas" tiene que calcularse a partir de eventos de actividad guardados, no incrementarse en React porque se ejecutó un spinner. Si la plataforma rechaza una llamada a herramienta, la interfaz no puede mantener el recuento optimista. Los bugs de proyección son bugs de modelado.
2. Guarda eventos de actividad normalizados
Almacena una línea de tiempo estructurada: nombre de la herramienta, búsqueda de conocimiento o herramienta genérica, estado, latencia, ids de correlación y argumentos enmascarados según permita la política. Las burbujas del chat son una representación. Los eventos son el sistema de registro para soporte. Sin persistencia, no puedes reconstruir una sesión después de que muera el websocket. La figura 1 muestra ese contrato como tres tareas.
3. Cuenta aparte las búsquedas de conocimiento MCP
Una búsqueda de conocimiento es un riesgo distinto y una pregunta de soporte distinta de "ejecutó la calculadora" o "exportó un CSV". Separa contadores y filtros. Los usuarios cuidadosos preguntan qué corpus se consultó. Agruparlo todo como "herramientas" oculta la respuesta. La figura 2 hace visible la separación.
Figura 2. La búsqueda de conocimiento no es una herramienta más. Los contadores separados responden a las preguntas sobre el corpus. Un único cajón de herramientas convierte las auditorías en teatro.
4. Publica un panel de depuración sobre Foundry + App Insights
Da a los usuarios internos (y a roles de soporte protegidos con cuidado) un panel que muestre los spans de la plataforma junto a los eventos normalizados. Las vistas de transacciones de extremo a extremo en App Insights se vuelven útiles cuando propagas los ids de operación a través del shell y de la API. En agentes empresariales esto no es un pulido opcional. La figura 3 muestra la costura.
Figura 3. Un solo id de operación en el shell, la API, Foundry y App Insights. Sin la costura tienes tres islas y tres verdades.
5. Convierte la trazabilidad en un punto de la política escrita
Escribe qué conservas, durante cuánto tiempo, quién puede ver las trazas en bruto y cómo funciona el enmascaramiento. Si la promesa del producto es "fundamentado con citas", la historia de operaciones tiene que incluir "podemos mostrar qué búsqueda se ejecutó". Si no, las auditorías se convierten en teatro.
6. Cuadra a propósito en las pruebas
Las pruebas automatizadas deberían comprobar que una sesión de herramientas guionizada produce agregados en la interfaz y recuentos de eventos guardados que coinciden. Haz un snapshot de la forma de la línea de tiempo. Detecta la deriva cuando alguien añade una ruta de herramienta que se olvida de emitir eventos.
Enmascaramiento frente a utilidad
Guardar los argumentos de las herramientas ayuda a depurar y crea riesgo de fuga. Por defecto, enmascara el texto libre y los secretos, y conserva los nombres de herramientas, los estados, los tiempos y los identificadores de corpus que permita la política. Documenta el perfil de enmascaramiento junto al esquema de eventos. Soporte debería saber qué no va a ver antes de abrir un ticket esperando una reproducción completa del prompt.
Qué debería poder responder soporte en cinco minutos
¿Qué búsquedas de conocimiento se ejecutaron, con qué pista de corpus y con qué estado? ¿Qué herramientas genéricas se ejecutaron? ¿Coinciden los chips de la interfaz con los eventos guardados de ese turno? ¿Podemos abrir la transacción correlacionada en App Insights? Si alguna respuesta exige leer tres sistemas desconectados y adivinar, el producto todavía no se puede operar. Construye el panel y el esquema hasta que esas respuestas sean aburridas.
Al añadir una herramienta nueva, la checklist del PR incluye la emisión de eventos, la proyección en la interfaz y una prueba de cuadre. Las herramientas que se saltan la checklist recrean la mentira original con otro disfraz.
Cualquier persona del equipo debería poder leer el esquema de eventos sin tener que aprender antes la consola de Foundry.
Errores comunes
Contadores optimistas en la interfaz. Los spinners suman; los fallos no restan.
Solo burbujas. No hay almacén de eventos; soporte lee capturas de pantalla.
Un único cajón de "herramientas". Las preguntas sobre el acceso al conocimiento se vuelven imposibles de responder. La figura 2 hace visible ese fallo.
Trazas sin ids de correlación. Islas en App Insights, islas en Foundry, islas en la interfaz. La figura 3 es la costura que lo evita.
El panel de depuración como ocurrencia tardía. Se construye durante una caída y nunca se mantiene.
Prometer auditabilidad sin diseñar la retención. Los revisores preguntan; ingeniería se encoge de hombros.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Esquema normalizado de eventos de actividad guardado por cada turno de la sesión.
- Los agregados de la interfaz son solo proyecciones de ese esquema.
- Las búsquedas de conocimiento MCP se cuentan y etiquetan aparte de las herramientas genéricas.
- Los ids de correlación cosen el shell, la API, Foundry y App Insights.
- Panel de depuración para soporte con control por roles.
- Política escrita de retención, enmascaramiento y acceso para auditoría.
Adáptalo antes de usarlo
Guardar eventos normalizados cuesta almacenamiento y diseño del enmascaramiento. A cambio obtienes velocidad en los incidentes y confianza. Los contadores de conocimiento separados añaden complejidad a la UX. Encajan con cómo piensa la gente sobre el riesgo. Los paneles de depuración necesitan control de acceso para no convertirse en una fuga de datos. Las pruebas de cuadre ralentizan un poco los ciclos de PR y evitan las mentiras silenciosas de los contadores. Habrá debate sobre cuánto enmascarar los argumentos frente a cuánto se puede depurar. Escribe la política una vez.
Referencias principales: Microsoft Learn sobre la correlación en Application Insights y la documentación de trazas y observabilidad de Microsoft Foundry para la versión de tu stack. Acompáñalas de un esquema de eventos escrito en el repo.
Guarda la línea de tiempo. Cuadra los contadores. Separa las búsquedas de conocimiento. Si no puedes explicar las llamadas a herramientas, pausa el lanzamiento y construye el producto de observabilidad que ya prometiste.