Kontext: control plane de Kubernetes para agentes IA
En pocas palabras: Kontext es un control plane open source que corre agentes de IA como recursos nativos de Kubernetes. Su alpha, publicada el 22 de julio de 2026 en la imagen ghcr.io/mfs-code/kontext-echo:v0.1.0-alpha.2, agrega dos custom resources y soporta tres tipos de agente: task, scheduled y service.
Kontext es un control plane de Kubernetes para agentes de IA y ya salió en versión alpha: la imagen pública ghcr.io/mfs-code/kontext-echo:v0.1.0-alpha.2 marca el alpha release del 22 de julio de 2026. Agrega dos recursos al cluster y deja el resto en manos de Kubernetes.
Kontext es un plano de control open source que corre agentes de IA como objetos nativos de Kubernetes. Vos aplicás un manifiesto, el controlador lo reconcilia en Pods reales, mirás los logs del runtime en vivo y leés el resultado como cualquier otro recurso del cluster. El proyecto vive en el repositorio MFS-code/Kontext y su sitio oficial es kontext.run.
En 30 segundos
- Dos recursos, cero plataforma nueva. Kontext no te pide aprender otro stack: agrega custom resources que el controlador reconcilia en Pods, y scheduling, secretos, RBAC y restarts los sigue haciendo Kubernetes.
- Tres tipos de agente. Task (plantilla one-shot reutilizable), scheduled (corridas one-shot que salen de slots de cron) y service (se vuelven a levantar solos cuando mueren).
- Presupuesto wallclock en el controlador. El límite de tiempo real lo enforza el controller, no el código del agente. Es la diferencia entre un agente colgado y un agente cortado.
- Cualquier contenedor es un agente. Ship your own image, o arrancá con los runtimes echo y reference que vienen con el release.
- Estado alpha, versión v0.1.0-alpha.2. Se instala sin clonar el repo y los resultados quedan consultables como objetos del cluster.
¿Por qué un agente de IA no entra bien en un Deployment común?
Porque un agente autónomo necesita cosas que un Deployment no modela: un presupuesto de tiempo antes de que lo corten, un resultado que alguien pueda leer después, y un ciclo de vida que no es “corré para siempre” ni “corré una vez y morite”. La lista que arma el propio proyecto es corta y honesta: scheduling, secretos, RBAC, presupuestos, logs y restarts.
Ponele que armás un agente que revisa un release y te devuelve las fallas. Con las piezas nativas te queda un Job, un ConfigMap con el prompt, un Secret con la API key, un CronJob si querés repetirlo, y un lugar inventado por vos para dejar la respuesta. Funciona. También es artesanal, y cada equipo lo resuelve distinto.
La postura de Kontext es la contraria a la moda de armar una plataforma paralela. El texto oficial lo dice sin vueltas: los agentes necesitan lo que Kubernetes ya hace, así que Kontext agrega dos recursos y le deja el resto al cluster. Esto se conecta con lo que analizamos en automatizar despliegues de Kubernetes.
¿Cómo funciona Kontext por dentro?
Kontext funciona como cualquier operador de Kubernetes: definís un custom resource, el controlador lo reconcilia en Pods reales, y a partir de ahí usás las herramientas de siempre. Aplicás el manifiesto, seguís los logs del runtime mientras corre, y leés el resultado cuando termina. No hay dashboard propietario en el medio ni un runtime que tengas que aprender aparte.
Armás el YAML, lo aplicás, el controlador crea el Pod, el agente arranca, hace lo suyo, escribe el resultado, y cuando volvés a mirar el cluster tenés un objeto con estado consultable en vez de un log perdido en una máquina que ya se recicló.
En los ejemplos oficiales aparece la pieza que más me gusta: un get agentrun review. Ahí se ve que la corrida del agente es un objeto de primera clase, con nombre propio, que consultás igual que un Pod o un ConfigMap. Los resultados viven en el recurso, no en un servicio externo al que tengas que pegarle.
¿Qué tipos de agentes soporta Kontext?
Kontext define tres formas de correr un agente: task, scheduled y service. Los task agents son plantillas one-shot reutilizables. Los scheduled agents generan corridas one-shot a partir de slots de cron. Los service agents se vuelven a levantar de forma automática cuando se caen. Los tres terminan en Pods, cambia el disparador y qué pasa cuando el proceso muere. Tema relacionado: alternativas para orquestar despliegues.
| Tipo de agente | Cómo se dispara | Qué pasa al terminar | Análogo mental en K8s nativo |
|---|---|---|---|
| Task | A mano, desde una plantilla reutilizable | Queda el resultado en el objeto de la corrida | Job |
| Scheduled | Slots de cron que crean corridas one-shot | Una corrida independiente por slot | CronJob |
| Service | Corre continuo | Se vuelve a levantar solo si muere | Deployment |
El caso de uso se elige solo. Análisis de un release: task. Reporte de errores de todos los lunes: scheduled. Agente que escucha eventos del cluster y reacciona: service.
¿Cómo maneja Kontext los secretos, el RBAC y los presupuestos?
Los delega al cluster, con una excepción: los presupuestos wallclock los enforza el controlador de Kontext. Secretos, RBAC, scheduling y restarts los sigue manejando Kubernetes con sus propios mecanismos, así que las políticas que ya tenés escritas aplican al agente sin traducción. El límite de tiempo real es la pieza que Kubernetes no traía y Kontext agrega.
Ese detalle no es menor. Un agente que se cuelga esperando una respuesta de un modelo puede quemar plata durante horas sin que nadie mire, y el corte tiene que venir de afuera del proceso (confiar en que el propio agente se autolimite es optimismo puro).
Sobre el resto del ecosistema hay que ser honesto: no tengo, de las fuentes disponibles, una comparación técnica publicada entre Kontext y otros planos de control para agentes. Lo que sí se puede decir sin inventar nada es que Ray resuelve cómputo distribuido y KServe resuelve serving de modelos. Kontext ataca otra capa: el ciclo de vida y el gobierno de la corrida del agente. Cubrimos ese tema en detalle en ejecutar agentes completamente locales.
¿Se puede usar un runtime propio con Kontext?
Sí. Cualquier contenedor puede ser un agente en Kontext: subís tu propia imagen y listo. Si querés probar antes de escribir código, el release trae dos runtimes de referencia, echo y reference, publicados en el registry como ghcr.io/mfs-code/kontext-echo:v0.1.0-alpha.2. No hay un SDK obligatorio ni un framework de agentes al que tengas que casarte.
Para el que ya tiene un agente andando en Python con su propio orquestador, esto significa que el trabajo de migración es empaquetar y declarar. Nada de reescribir la lógica.
¿Cómo se instala Kontext y qué hace falta para probarlo?
Se instala sin clonar el repositorio, según el sitio oficial, y necesitás lo mismo de siempre: un cluster de Kubernetes con permisos para registrar CRDs y correr un controlador. Después de eso, el flujo es aplicar el recurso, mirar los logs del runtime y consultar el resultado. La documentación oficial está en docs.kontext.run.
¿Sirve un cluster chico para probarlo? Debería, porque el peso real lo pone el contenedor de tu agente, no el controlador. Si no tenés dónde levantar el entorno, cualquier VPS o instancia de nube alcanza para un cluster de prueba, y en Argentina lo podés armar sobre infraestructura de donweb.com sin depender de una cuenta afuera.
Sobre precio y licencia: el proyecto es open source y está publicado en GitHub, pero las fuentes disponibles no traen una tabla de precios ni un plan comercial. Si alguien te muestra un pricing de Kontext, pedile la URL.
Errores comunes al probar el kontext alpha release
- Tratar un alpha como producción. La versión publicada es
v0.1.0-alpha.2. Los CRDs de un proyecto en alpha cambian de forma entre releases, así que si escribís mucho YAML ahora, asumí que lo vas a reescribir. - Esperar que Kontext piense por vos. No trae modelo ni lógica de agente adentro. El runtime echo hace exactamente lo que dice el nombre: la inteligencia la ponés en tu imagen.
- No definir el presupuesto wallclock. El controlador lo enforza, pero alguien tiene que declararlo. Un agente sin límite de tiempo es un agente que puede quedarse colgado toda la noche esperando una API que no responde.
- Elegir mal el tipo de agente. Usar un service agent para una tarea one-shot te deja un proceso que se relanza para siempre, porque es lo que un service agent hace por diseño. Para eso está el task agent.
- Meter las credenciales en el manifiesto. Kontext delega secretos y RBAC al cluster justo para que no hagas esto. Si hardcodeás la API key en el YAML del agente, perdiste la mitad de la ventaja de correrlo en Kubernetes.
Preguntas Frecuentes
¿Qué es Kontext?
Kontext es un control plane de Kubernetes para agentes de IA. Agrega dos custom resources que el controlador reconcilia en Pods reales, y deja scheduling, secretos, RBAC, logs y restarts en manos del cluster. El código está en el repositorio MFS-code/Kontext y el sitio oficial es kontext.run. En privacidad y seguridad en infraestructura profundizamos sobre esto.
¿Qué versión de Kontext está disponible?
La imagen publicada en el registry es v0.1.0-alpha.2, o sea un estado alpha temprano. Es una versión para probar en entornos de desarrollo, no para poner a manejar cargas críticas todavía.
¿Cuánto cuesta Kontext?
El proyecto es open source y está publicado en GitHub, sin un esquema de precios anunciado en las fuentes oficiales. El costo que sí vas a pagar es el de cómputo del cluster donde corran los agentes y el de las APIs de modelos que use tu runtime.
¿Kontext reemplaza a Ray o a KServe?
No, resuelven capas distintas. Ray se ocupa de cómputo distribuido y KServe de servir modelos, mientras que Kontext se ocupa del ciclo de vida de la corrida de un agente dentro de Kubernetes: cuándo arranca, con qué permisos, cuánto tiempo tiene y dónde queda el resultado.
¿Dónde está la documentación de Kontext?
En docs.kontext.run está la documentación oficial, y el código con los issues abiertos en github.com/MFS-code/Kontext. Al ser un proyecto en alpha, el repositorio es el lugar donde vas a ver primero los cambios de los CRDs.
Para entender mejor cómo Docker orquesta servicios automáticamente, tenemos este artículo sobre Kubernetes service orchestration.
Conclusión
La mayoría de las herramientas para correr agentes de IA en 2026 arrancan construyendo una plataforma nueva alrededor del cluster. Kontext hace lo opuesto: dos recursos, reconciliación en Pods, y todo lo demás resuelto por lo que Kubernetes ya sabe hacer. Si tu equipo tiene un cluster andando y tres scripts caseros lanzando agentes, esa decisión de diseño te ahorra la peor parte del trabajo.
Eso sí: es un alpha en v0.1.0-alpha.2, y las fuentes públicas todavía no traen benchmarks, casos de producción ni un roadmap detallado. Mi recomendación concreta: levantá un cluster de prueba, corré el runtime echo para entender el flujo de agentrun, y recién ahí evaluá migrar un agente propio. Con presupuesto wallclock definido desde el primer manifiesto.
Fuentes
- Kontext – sitio oficial del proyecto, con la descripción de los tipos de agente y los runtimes incluidos
- MFS-code/Kontext en GitHub – código fuente, releases e issues
- docs.kontext.run – documentación oficial e instalación
- InfoQ – Securing Autonomous AI Agents on Kubernetes
- Tigera – The Rise of AI Agents (contexto de agentes en Kubernetes)
