Python | The .NET Blog

¿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.

CodeAct en Agent Framework: Cómo Reducir la Latencia de tu Agente a la Mitad

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

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

Hay un momento en todo proyecto de agentes en que miras el trace y piensas: “¿por qué tarda tanto esto?” El modelo está bien. Las herramientas funcionan. Pero hay siete round trips para obtener un resultado que podría calcularse de una sola vez.

Ese es exactamente el problema que resuelve CodeAct — y el equipo de Agent Framework acaba de publicar soporte alpha para ello a través de un nuevo paquete agent-framework-hyperlight.

¿Qué es CodeAct?

El patrón CodeAct es elegantemente simple: en lugar de darle al modelo una lista de herramientas y dejar que las llame una por una, le das una única herramienta execute_code y le permites expresar el plan completo como un programa Python corto. El agente escribe el código una vez, el sandbox lo ejecuta, y obtienes de vuelta un único resultado consolidado.

Un plan de cinco pasos que antes requería cinco turnos del modelo ahora se convierte en un turno execute_code que contiene un script Python que llama a tus herramientas vía call_tool(...).

El benchmark del repositorio lo hace concreto. Ocho usuarios, docenas de pedidos, cinco herramientas (listar usuarios, obtener pedidos, tasa de descuento, tasa de impuesto, calcular total de línea). Mismo modelo, mismas herramientas, mismo prompt — solo cableado diferente:

Cableado	Tiempo	Tokens
Tradicional	27.81s	6.890
CodeAct	13.23s	2.489
Mejora	52,4%	63,9%

Eso no es un micro-benchmark. Es una carga de trabajo realista con overhead de orquestación real.

La pieza de seguridad: micro-VMs de Hyperlight

Aquí está lo que me entusiasmó realmente: la seguridad ha sido históricamente el talón de Aquiles de CodeAct. Si estás ejecutando código generado por el modelo, ¿exactamente dónde se ejecuta? ¿Contra tu proceso? ¿En un contenedor compartido?

El paquete agent-framework-hyperlight resuelve esto con micro-VMs de Hyperlight. Cada llamada execute_code obtiene su propia micro-VM recién creada — con su propia memoria, sin acceso al sistema de archivos del host más allá de lo que montes explícitamente, y sin acceso a la red más allá de los dominios que permitas. El arranque se mide en milisegundos. El aislamiento es prácticamente gratuito.

Tus herramientas siguen ejecutándose en el host (son tu código, con tu acceso). El pegamento generado por el modelo — el Python que decide qué herramientas llamar y en qué orden — se ejecuta en el sandbox. Esa es la división correcta.

Cómo conectarlo

La configuración mínima es sencilla:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

result = await agent.run(
 "Get the weather for Seattle and Amsterdam and compare them."
)

El proveedor registra execute_code en cada ejecución e inyecta las instrucciones de CodeAct en el prompt del sistema automáticamente.

Mezclando CodeAct con herramientas que requieren aprobación

Aquí se pone interesante. No todas las herramientas deberían ejecutarse dentro del sandbox sin aprobación. Puede que quieras aprobar send_email o charge_credit_card individualmente. El framework maneja esto de forma limpia:

@tool(approval_mode="always_require")
def send_email(to: str, subject: str, body: str) -> str:
 """Send an email. Requires approval on every call."""
 ...

agent = Agent(
 client=client,
 name="MixedToolsAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
 tools=[send_email], # invocado directamente, con aprobación
)

Herramientas en el proveedor → el modelo las alcanza vía call_tool(...) dentro del sandbox, baratas y encadenables.
Herramientas directamente en el agente → el modelo las llama como herramientas de primera clase, la aprobación aplica individualmente.

Cuándo usar CodeAct (y cuándo no)

Usa CodeAct cuando:

La tarea encadena muchas llamadas pequeñas a herramientas (búsquedas, joins, cálculos, formateo)
Te importa la latencia y el costo de tokens
Quieres aislamiento fuerte por llamada en código generado por el modelo por defecto
Las herramientas son baratas y seguras para invocar en secuencia

Quédate con el tool-calling tradicional cuando:

El agente solo hace una o dos llamadas a herramientas por turno
Cada llamada a herramienta tiene efectos secundarios que quieres aprobar individualmente
Las descripciones de herramientas son escasas o ambiguas — CodeAct depende de buenos docstrings

Pruébalo ahora

pip install agent-framework-hyperlight --pre
# o
uv add --prerelease=allow agent-framework-hyperlight

Los ejemplos están en python/packages/hyperlight/samples/. El ejemplo de benchmark es el mejor punto de partida.

Vale la pena mencionar: Linux y Windows son compatibles hoy. El soporte para macOS está en camino. Un equivalente para .NET también está llegando.

Resumiendo

CodeAct no es magia — es un patrón sensato que era demasiado arriesgado de usar sin sandboxing adecuado. Hyperlight cambia esa ecuación. Aislamiento en micro-VM por llamada, arranque en milisegundos, mejora de latencia del 50%+ en las cargas de trabajo adecuadas. Vale la pena experimentar.

Consulta el post completo en el blog de Agent Framework para cobertura más profunda sobre montajes de sistema de archivos, política de red y el cableado independiente de HyperlightExecuteCodeTool.

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.