Agent Harness y CodeAct resuelven problemas distintos, pero complementarios. El primero gobierna la planificación, el estado, las herramientas y las aprobaciones; el segundo permite ejecutar de forma compacta tareas intensivas en datos y llamadas a herramientas. En este artículo construimos una demo con C#, .NET 10, Microsoft Foundry y Bicep.
El mismo agente, la misma región, la misma cuota, el mismo Key Vault, el mismo sobre de recursos del contenedor — y una única variable de verdad: el runtime. Uno es C# 14 sobre .NET 10 LTS, el otro es CPython 3.12. Todo lo demás está clavado a propósito, porque un benchmark que cambia dos cosas a la vez no mide nada. Este mide una: el coste del lenguaje/runtime dentro del hosting de Foundry.
Y el resultado, adelantándolo sin ceremonia: C# sobre .NET 10 sale entre un 22% y un 30% más rápido en media, con esa ventaja sostenida a las 10, 100 y 1000 peticiones, tanto con modelo como sin él. Ahora el «cómo lo he medido», que es donde un benchmark se gana o se pierde la credibilidad.
Parte I — Fundamentos, arquitectura limpia y estrategia de testing
Parte II — Control plane de IA: APIM, seguridad y escalado real en Azure
Cada vez más aplicaciones empiezan a usar LLMs. Integrar un modelo es sencillo: haces una llamada HTTP y listo.
El problema aparece cuando la IA pasa a producción.
Entonces necesitas …
Uno de los bloqueos más comunes que escucho en empresas cuando proponemos usar Dapr sobre Azure —por ejemplo con Azure Service Bus o Azure Blob Storage bindings — es que los building block estan en versión alpha. Veamos que significa esto.
Durante años, en distintos foros, revisiones técnicas, comunidades internas y sesiones de arquitectura, he repetido siempre lo mismo:
el code coverage NO es una métrica fiable de calidad de tests. Y aun así, periódicamente alguien vuelve a preguntar.
En mis pruebas reales con modelos de razonamiento (o1) y datos de negocio no cocinados, TOON no fue “mágico”, pero sí consistentemente útil: frente a JSON compacto, TOON-RAW redujo ~25% de tokens sin perder precisión ni aumentar la latencia. Ese ahorro aparece justo donde más duele —en los tool-results entre MCP y los agentes— y se multiplica en arquitecturas AI-native con decenas de llamadas por flujo. La conclusión no es cambiar tus APIs a TOON, sino usar JSON mini en el backend y reservar TOON para la frontera MCP ↔ LLM, donde optimizar tokens sin perder estructura sí importa.
Azure IoT Operations es el nuevo plano industrial de Microsoft para plantas que necesitan algo más que un IoT “de laboratorio”. Es una plataforma edge-native, basada en Kubernetes y habilitada por Azure Arc, capaz de procesar millones de señales por segundo, integrar OPC UA de forma nativa, operar sin conexión durante horas y gobernar todo el ciclo de vida del dato desde el propio perímetro. En este monográfico exploro cómo IoT Operations se diferencia de IoT Hub y de IoT Edge, cuándo tiene sentido dar el salto, y qué implica en términos de arquitectura, seguridad, gobernanza y coste operativo (FinOps). También incluyo un despliegue paso a paso, varios casos de uso reales en manufactura, ejemplos de DataFlows, módulos propios (Python/.NET), integración con Microsoft Fabric y un análisis totalmente práctico de cómo operar esta plataforma en producción.
Si trabajas en entornos OT/IT, si necesitas alta frecuencia, resiliencia offline o un modelo de operación declarativo, este artículo te ayudará a entender por qué IoT Operations no es una evolución de IoT Edge… sino el siguiente plano lógico para plantas modernas.
Como exponer tus APIS en 5 minutos a un modelo MCP Server; sin trampa ni cartón.