Microsoft publicó el 25 de septiembre de 2026 una pieza que puede ser más importante de lo que parece para quienes construyen productos con agentes: AG-UI ya tiene un SDK .NET de primera clase.

Fuente principal: Microsoft .NET Blog — AG-UI Protocol now has a first-class .NET SDK

El anuncio no consiste simplemente en “otro paquete NuGet”. La propuesta es que cualquier servicio .NET pueda hablar directamente el protocolo AG-UI y que una aplicación pueda consumir un agente remoto mediante las abstracciones normales de Microsoft.Extensions.AI.

Eso abre una arquitectura interesante:

interfaz
   │
   │ AG-UI
   ▼
agente / runtime

La interfaz deja de necesitar una integración privada con cada framework de agentes. Y el runtime deja de tener que conocer cómo se representa visualmente cada evento.

A partir de ahí aparece una combinación especialmente atractiva para prototipos y herramientas internas:

Streamlit
   │
   │ AG-UI
   ▼
adaptador
   │
   ▼
Codex

La idea de este artículo es recorrer primero el SDK .NET que acaba de presentar Microsoft y después responder dos preguntas prácticas: ¿puede Streamlit actuar como cliente AG-UI? y ¿puede Codex integrarse detrás de ese protocolo?

La respuesta corta a ambas es sí, pero con matices importantes.

Estado verificado el 27 de septiembre de 2026. AG-UI y Codex evolucionan rápido; conviene revisar los enlaces oficiales antes de fijar una arquitectura de producción.

Primero: qué trae exactamente el SDK .NET de AG-UI

Microsoft desarrolló el SDK junto con CopilotKit y lo aportó al repositorio principal de AG-UI, donde vive junto a los SDK de TypeScript y Python. Se publica en NuGet bajo licencia MIT.

El SDK se divide en cinco paquetes:

PaqueteFunción
AGUI.AbstractionsTipos del protocolo: eventos, mensajes, herramientas, capacidades, interrupciones, estado y serialización
AGUI.FormattingFormatos de transporte; incluye la implementación SSE por defecto
AGUI.ProtobufCodec protobuf opcional para un subconjunto de eventos
AGUI.ClientConsume endpoints AG-UI
AGUI.ServerExpone un agente como endpoint AG-UI

Fuente: Microsoft .NET Blog — The packages

Para la mayoría de aplicaciones, el desarrollador solo necesita decidir de qué lado está.

Si está construyendo el backend:

dotnet add package AGUI.Server

Si está construyendo el consumidor:

dotnet add package AGUI.Client

El punto de integración es IChatClient

Una de las decisiones más interesantes del SDK es apoyarse en Microsoft.Extensions.AI.IChatClient.

Eso significa que el agente no tiene que adoptar una API completamente distinta para hablar AG-UI. Puede mantener la abstracción que ya utiliza el ecosistema .NET.

En el servidor, un IChatClient puede producir un stream y transformarlo en eventos AG-UI.

Conceptualmente:

IChatClient
   │
streaming response
   │
   ▼
AGUI.Server
   │
SSE / eventos AG-UI
   ▼
cliente

En el sentido contrario, AGUI.Client incluye AGUIChatClient, que también implementa IChatClient.

Por tanto:

aplicación .NET
      │
   IChatClient
      │
AGUIChatClient
      │
    AG-UI
      │
agente Python / TypeScript / C#

La aplicación puede consumir un agente remoto sin que el resto del código tenga que conocer el lenguaje o framework de ese agente.

Microsoft muestra una inicialización del cliente de este estilo:

using AGUI.Client;

using var httpClient = new HttpClient();

var chatClient = new AGUIChatClient(
    new(httpClient, "http://localhost:5001"));

Fuente: Microsoft .NET Blog — AG-UI .NET quickstart

Microsoft Agent Framework ahora se apoya en este SDK

Microsoft Agent Framework ya soportaba AG-UI, pero ahora su implementación .NET depende de los paquetes AGUI.* comunes.

El modelo de programación queda muy compacto:

builder.Services.AddAGUIServer();

AIAgent agent = chatClient.AsAIAgent(
    name: "AGUIAssistant",
    instructions: "You are a helpful assistant.");

app.MapAGUIServer("/", agent);

La migración conserva el formato del protocolo. Microsoft señala que un frontend existente debería seguir funcionando contra un backend actualizado.

Esto es importante porque AG-UI deja de ser una integración encerrada dentro de un framework concreto y pasa a ser una capa reutilizable por cualquier servicio .NET.

Qué problema intenta resolver AG-UI

Los agentes rompen el clásico patrón HTTP de petición-respuesta.

Un agente puede:

  • trabajar durante minutos;
  • emitir texto progresivamente;
  • invocar herramientas;
  • pedir aprobación humana;
  • actualizar estado;
  • delegar a subagentes;
  • pausar y continuar;
  • producir resultados intermedios.

Sin un protocolo común, cada backend inventa su propio formato.

La UI termina escribiendo lógica específica para cada framework:

LangGraph events ─┐
CrewAI events ────┼── lógica propia de UI
framework X ──────┤
runtime Y ────────┘

AG-UI intenta mover esa complejidad a un contrato común.

La documentación oficial lo describe como un protocolo abierto, ligero y orientado a eventos para conectar agentes con aplicaciones de usuario.

Fuente: AG-UI — README

Sus eventos se agrupan por propósito:

  • ciclo de vida de una ejecución;
  • mensajes de texto;
  • llamadas a herramientas;
  • sincronización de estado;
  • actividad y progreso;
  • subagentes;
  • eventos especiales o personalizados.

Fuente: AG-UI — Events

Por ejemplo, el texto no llega como una cadena ambigua, sino como una secuencia explícita:

TEXT_MESSAGE_START
        ↓
TEXT_MESSAGE_CONTENT
        ↓
TEXT_MESSAGE_CONTENT
        ↓
TEXT_MESSAGE_END

Las herramientas tienen su propio ciclo:

TOOL_CALL_START
      ↓
TOOL_CALL_ARGS
      ↓
TOOL_CALL_END
      ↓
TOOL_CALL_RESULT

Y el estado puede transmitirse mediante snapshots y deltas.

AG-UI no sustituye a MCP

Conviene separar responsabilidades.

usuario
  │
  ▼
interfaz
  │
AG-UI
  │
  ▼
agente
  ├── MCP ── herramientas y datos
  │
  └── A2A ── otros agentes

El propio proyecto AG-UI presenta esa división de responsabilidades: MCP conecta agentes con herramientas, A2A conecta agentes entre sí y AG-UI conecta agentes con aplicaciones orientadas al usuario.

Fuente: AG-UI — protocol stack

Los protocolos pueden coexistir en una misma aplicación.

¿Y Streamlit?

Aquí aparece el primer matiz importante.

Streamlit no figura actualmente entre los clientes oficiales soportados de AG-UI.

El repositorio principal lista clientes como CopilotKit, terminal, plataformas de chat y React Native.

Fuente: AG-UI — Clients

Existe además una discusión específica de la comunidad preguntando por soporte para Streamlit o Gradio.

Fuente: AG-UI discussion #538 — Streamlit or Gradio frontend support thoughts

Eso no significa que Streamlit sea incompatible.

La documentación de AG-UI aclara algo fundamental: un cliente no tiene que ser una aplicación web React. Cualquier programa capaz de consumir el stream de eventos y presentarlo al usuario puede actuar como cliente.

Fuente: AG-UI — Build clients

Por tanto, Streamlit puede convertirse en cliente mediante un adaptador.

Streamlit
   │
   │ HTTP / SSE
   ▼
AG-UI endpoint
   │
   ▼
agente

Cómo mapear AG-UI a Streamlit

Una primera versión podría limitarse a unos pocos eventos:

AG-UI                         Streamlit

TEXT_MESSAGE_CONTENT   →     st.chat_message / st.empty
TOOL_CALL_START        →     st.status
TOOL_CALL_RESULT       →     st.expander / st.json
STATE_DELTA            →     st.session_state
RUN_STARTED            →     indicador de ejecución
RUN_FINISHED           →     finalizar estado

Conceptualmente:

async for event in agui_stream:
    match event["type"]:
        case "TEXT_MESSAGE_CONTENT":
            render_text_delta(event)

        case "TOOL_CALL_START":
            show_tool_started(event)

        case "TOOL_CALL_RESULT":
            show_tool_result(event)

        case "STATE_DELTA":
            update_session_state(event)

        case "RUN_FINISHED":
            finish_run(event)

Para un prototipo, esto cubre una parte grande del valor.

El desafío aparece cuando queremos interacción realmente rica: múltiples agentes, interrupciones, herramientas ejecutadas en el frontend, approvals complejos o actualizaciones concurrentes. Streamlit funciona con un modelo de ejecución distinto a un frontend React tradicional, por lo que algunas experiencias requieren componentes personalizados o una capa adicional de estado.

AG-UI no elimina ese problema. Lo que sí hace es evitar que además tengamos que inventar el protocolo.

¿Puede Codex vivir detrás de AG-UI?

Sí.

La forma más sencilla de verlo es tratar Codex como otro runtime que produce eventos.

Streamlit
   │
 AG-UI
   │
adapter
   │
Codex
   │
repo / shell / tools

La pregunta real es qué superficie de Codex usamos.

Hoy hay tres caminos especialmente relevantes.

Opción 1: codex exec —json

Es la integración más sencilla para automatización y procesos headless.

Codex puede ejecutarse en modo no interactivo y emitir eventos estructurados en JSONL.

Un adaptador puede lanzar:

codex exec --json --ephemeral "Diagnose the failing tests"

y leer cada línea de stdout como un evento.

Después traduce eventos Codex a eventos AG-UI.

Conceptualmente:

Codex                         AG-UI

thread.started        →       metadata / inicio
turn.started          →       RUN_STARTED
agent_message         →       TEXT_MESSAGE_*
command_execution     →       TOOL_CALL_*
file_change           →       state/custom event
turn.completed        →       RUN_FINISHED
turn.failed           →       RUN_ERROR

El adaptador podría parecerse a esto:

proc = await asyncio.create_subprocess_exec(
    "codex",
    "exec",
    "--json",
    "--ephemeral",
    prompt,
    stdout=asyncio.subprocess.PIPE,
)

async for line in proc.stdout:
    codex_event = json.loads(line)
    for agui_event in translate(codex_event):
        yield agui_event

Esta ruta tiene varias ventajas:

  • muy poca infraestructura;
  • buena para CI y jobs independientes;
  • fácil de ejecutar en un host de herramientas;
  • permite desacoplar el frontend de Codex;
  • —ephemeral evita persistir una sesión que no necesita reanudarse.

Pero exec JSONL no expone todo

Este punto es importante para no confundir “eventos estructurados” con “protocolo completo de UI”.

Hay issues abiertos en Codex que documentan pérdida de información al proyectar el estado interno hacia la salida de exec.

Por ejemplo, el issue #30190 señala que la salida exec no conserva el campo phase que distingue mensajes intermedios de commentary frente a final_answer.

Fuente: openai/codex #30190

El issue #35415 documenta limitaciones en los metadatos estructurados de búsqueda web expuestos por codex exec —json.

Fuente: openai/codex #35415

Y el issue #45773 describe otros casos en los que la proyección JSON pierde información de web_search.

Fuente: openai/codex #45773

Por tanto:

codex exec —json es una excelente superficie de automatización, pero no debemos asumir que representa con fidelidad absoluta todo el estado interno que podría necesitar una UI sofisticada.

Opción 2: @openai/codex-sdk

OpenAI mantiene además un SDK TypeScript para incrustar Codex en aplicaciones.

Fuente: Codex TypeScript SDK

El SDK es revelador porque envuelve el propio Codex CLI: lanza el proceso y se comunica mediante eventos JSONL por stdin/stdout.

La API permite trabajar con un Thread:

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();

const turn = await thread.run(
  "Diagnose the test failure and propose a fix"
);

Para una UI, la parte interesante es runStreamed():

const { events } = await thread.runStreamed(
  "Diagnose the failure"
);

for await (const event of events) {
  // traducir event → AG-UI
}

OpenAI documenta que esta ruta permite reaccionar a progreso intermedio, tool calls, respuestas en streaming y notificaciones de cambios de archivos.

Eso elimina bastante código de subprocess y parsing.

Pero existe una consideración práctica para automatizaciones masivas: el issue #34760 pide que el SDK exponga una opción ephemeral equivalente a codex exec —ephemeral. La solicitud describe que, sin esa opción, startThread puede persistir sesiones en CODEX_HOME incluso para jobs independientes.

Fuente: openai/codex #34760

Para un servicio que crea cientos o miles de ejecuciones desechables, ese detalle operacional importa.

Opción 3: Codex App Server

Para una integración profunda, App Server es probablemente la superficie más interesante.

Codex tiene un protocolo de aplicación más rico alrededor de threads, turns, items, approvals y eventos.

El esquema actual de thread/start, por ejemplo, permite configurar:

  • modelo;
  • cwd;
  • política de aprobación;
  • sandbox;
  • instrucciones;
  • configuración;
  • ephemeral.

Fuente: Codex app-server protocol — ThreadStartParams

Una arquitectura podría ser:

Streamlit
   │
 AG-UI
   │
AG-UI ↔ Codex adapter
   │
Codex App Server
   │
repo / shell / MCP / tools

Aquí el adaptador ya no está limitado a la proyección simplificada de codex exec. Puede trabajar con una superficie que representa directamente threads y turns y que contiene conceptos relevantes para una UI interactiva.

Es una mejor base si necesitamos:

  • conversaciones persistentes;
  • interrupciones;
  • approvals;
  • reanudación;
  • estado granular;
  • varios turnos;
  • UI que muestre con precisión fases y herramientas.

Pero tampoco debemos asumir perfección. Por ejemplo, el issue #21982 documenta un caso en el que una solicitud de aprobación de sandbox no llegó correctamente al cliente de App Server.

Fuente: openai/codex #21982

La conclusión no es evitar App Server, sino tratar estas superficies como APIs activamente evolucionando y cubrir la integración con tests.

La arquitectura que elegiría

Para un experimento inicial:

Streamlit
   │
   │ AG-UI
   ▼
Python adapter
   │
codex exec --json --ephemeral
   │
workspace

Tiene muy pocas piezas y permite validar rápidamente:

  1. streaming;
  2. visualización de herramientas;
  3. archivos modificados;
  4. finalización y errores.

Después, si la UI necesita interacción bidireccional compleja:

Streamlit
   │
   │ AG-UI
   ▼
adapter
   │
Codex App Server
   │
workspace

Y si el resto de la aplicación está en TypeScript y queremos una integración de aplicación más cómoda:

UI
 │
AG-UI
 │
adapter TypeScript
 │
@openai/codex-sdk
 │
Codex CLI

El punto más importante es que Streamlit no debería conocer el esquema privado de Codex.

Debe conocer AG-UI.

Así podemos cambiar:

Codex → otro agente

sin reescribir la interfaz.

Y también podemos cambiar:

Streamlit → React / móvil / terminal

sin reescribir el runtime del agente.

¿Dónde entra .NET en esta arquitectura?

Precisamente aquí se vuelve útil el nuevo SDK de Microsoft.

Podemos construir un adaptador en ASP.NET Core:

Streamlit
   │
 AG-UI
   │
ASP.NET Core
   │
Codex adapter
   │
Codex

O utilizar .NET como cliente:

aplicación .NET
   │
AGUI.Client / IChatClient
   │
AG-UI
   │
backend Codex

O mantener Microsoft Agent Framework como backend principal y utilizar Codex para determinadas tareas especializadas:

UI
 │
AG-UI
 │
Microsoft Agent Framework
 ├── herramientas normales
 ├── MCP
 └── Codex worker

La gran ventaja es que las fronteras quedan explícitas.

AG-UI como “ABI” de la experiencia agéntica

La analogía no es perfecta, pero resulta útil.

En software nativo, una ABI permite que componentes compilados independientemente cooperen siguiendo un contrato común.

AG-UI intenta hacer algo parecido para la interacción entre agentes y aplicaciones:

UI               runtime
 │                  │
 └──── AG-UI ───────┘

Si el contrato se mantiene estable, ambos lados pueden evolucionar con mayor independencia.

Esto resulta especialmente valioso ahora que tenemos muchos runtimes de agentes y muchas superficies de usuario.

El objetivo no debería ser que cada combinación tenga una integración diferente:

Streamlit × Codex
Streamlit × LangGraph
React × Codex
React × MAF
móvil × Codex
terminal × LangGraph
...

La alternativa es reducir el problema a dos adaptaciones:

cada UI       → AG-UI
cada runtime  → AG-UI

Ese es el potencial real del protocolo.

Qué construiría primero

Un MVP razonable no necesita implementar todo AG-UI.

Empezaría con:

  1. RUN_STARTED / RUN_FINISHED / RUN_ERROR;
  2. TEXT_MESSAGE_*;
  3. tool calls;
  4. estado mínimo;
  5. cancelación.

En Streamlit eso ya permitiría mostrar una experiencia del estilo:

Usuario: arregla los tests fallidos

Codex está trabajando...
 ├─ inspeccionó 12 archivos
 ├─ ejecutó pytest
 ├─ modificó parser.py
 ├─ ejecutó 84 tests
 └─ todos pasaron

Respuesta:
Corregí la condición de carrera...

Después añadiría approvals e interrupciones.

Y solo después intentaría generative UI o sincronización sofisticada de estado.

Conclusión

El anuncio del SDK .NET de AG-UI es importante porque convierte el protocolo en una pieza mucho más natural dentro del ecosistema de Microsoft: IChatClient puede producir o consumir AG-UI, Microsoft Agent Framework se apoya en el SDK común y cualquier backend .NET puede exponer agentes sin inventar su propio wire protocol.

Streamlit, por su parte, todavía no tiene una integración oficial de primera clase, pero puede actuar como cliente porque AG-UI estandariza eventos, no una tecnología de rendering concreta.

Y Codex encaja detrás de esa frontera de varias maneras:

MVP / automatización
→ codex exec --json --ephemeral

aplicación TypeScript
→ @openai/codex-sdk

integración profunda y bidireccional
→ Codex App Server

La pieza arquitectónica más valiosa no es ninguna de esas tres por separado.

Es mantener esta frontera:

interfaz
   │
 AG-UI
   │
runtime del agente

Si esa frontera funciona, podemos experimentar con Streamlit hoy, movernos a otra UI mañana y cambiar el runtime del agente después sin volver a inventar toda la integración.

Esa es precisamente la clase de desacoplamiento que el ecosistema de agentes necesita.