Argentic Kernel explora una idea sencilla: los modelos pueden cambiar, equivocarse o perder una sesión; la intención, el contexto, la evidencia y la autoridad no deberían desaparecer con ellos. El Kernel organiza esas piezas fuera del modelo para convertir trabajo asistido por IA en operaciones revisables, verificables y auditables.
La tesis: el modelo puede interpretar, razonar y proponer; el sistema debe conservar por separado qué se pidió, con qué contexto, qué se verificó, quién autorizó y qué ocurrió realmente.
Un chat puede resolver una tarea. El problema aparece cuando esa conversación empieza a cargar decisiones, código, reglas, permisos, memoria del proyecto y cambios reales. Entonces ya no alcanza con que el modelo “recuerde” o parezca seguro de su respuesta.
El lenguaje técnico existe para nombrar responsabilidades distintas. Ningún término debería ser necesario antes de entender la idea humana que representa.
Material crudo: conversaciones, documentos, código, decisiones o ideas todavía sin refinar.
Una representación procesada y reutilizable del RAW. Puede seguir siendo candidate hasta revisión.
Algo que el sistema no sabe o no debe inventar. La incertidumbre se registra en vez de esconderse.
Una unidad de trabajo delimitada: objetivo, inputs, outputs, contexto, restricciones y validación.
Una capacidad declarada que el sistema puede intentar ejercer bajo reglas.
Información concreta que una operación necesita, con procedencia y freshness cuando corresponde.
Una comprobación independiente de la propuesta del modelo.
El rastro auditable de qué se hizo, con qué inputs, qué se verificó y qué resultado se observó.
Una propuesta o resultado todavía no promovido a verdad estable ni autorizado por defecto.
Una propuesta concreta de cambio material que puede verificarse, autorizarse y aplicarse por etapas separadas.
AK también necesita reglas para no convertirse en otra capa de complejidad difícil de justificar.
La arquitectura puede contemplar continuidad, múltiples proyectos y dispositivos. La implementación debe demostrar valor primero en unidades pequeñas, reales y gobernables.
Un unknown explícito es mejor que una certeza inventada. El sistema debe poder decir “esto falta” y detenerse cuando esa falta importa.
Que una propuesta parezca correcta, pase tests o provenga de un modelo potente no la convierte automáticamente en una decisión humana.
Regla de peso: si el método se vuelve más difícil que el problema que intenta resolver, el Kernel falló.
El runtime actual ya materializa una separación que antes era principalmente una intención de diseño.
Un modelo produce un cambio candidate. Puede estar bien, mal o incompleto.
Se comprueba identidad, estructura, contexto, hashes y condiciones gobernadas.
Una persona autoriza un sujeto exacto; el Kernel revalida y recién entonces puede aplicar.
No equivalencias: candidate ≠ verified ≠ authorized ≠ applied ≠ stable. Cada palabra describe algo distinto.
AK toma ideas conocidas —trazabilidad, policy-as-code, provenance, zero trust, CI/CD, control de cambios— y las aplica a una unidad nueva: trabajo con modelos probabilísticos que necesitan contexto, límites y autoridad explícitos.
Reglas explícitas y verificables en vez de depender sólo del prompt.
No confiar por defecto en la propuesta, el contexto ni la autoridad.
Identidad, hashes, provenance y observación del resultado.
Validación automatizable sin convertir CI en aprobación humana.
Puede convivir con agentes y tools; el foco de AK es el gobierno semántico.
Una tool puede ejecutar una capacidad sin convertirse en la fuente de verdad.
No como botón decorativo: la autoridad debe tener sujeto, alcance e identidad.
Memoria y recuperación ayudan al modelo, pero no reemplazan evidencia ni autoridad.
Si intención, conocimiento, estado, evidencia y autoridad están representados fuera del modelo, una persona o un equipo podría cambiar de proveedor, modelo, sesión o máquina sin reconstruir todo desde cero.
El runtime local ya tiene una primera noción productiva de identidad de proyectos y sus ubicaciones locales.
La visión futura agrega usuarios, grants, sincronización, Relay y clientes como móvil o IDE sin trasladar autoridad material al transporte.
La visión sigue, pero el átomo manda. Lo futuro sólo tiene sentido si el núcleo local continúa demostrando operaciones pequeñas, reales, verificables y gobernables.
No. Es un runtime experimental en desarrollo activo. Ya existen operaciones gobernadas reales y AK puede evaluar si una intención revisada tiene base suficiente para avanzar hacia una misión, pero todavía faltan la derivación gobernada de requirements, la materialización de la Mission y otras capacidades de continuidad.
No exactamente. Puede coordinar modelos y tools, pero su foco es conservar contexto, contratos, evidencia y autoridad alrededor del trabajo que esos componentes realizan.
Sí. Existe un camino experimental donde un modelo propone un cambio, el Kernel lo verifica, una persona autoriza el cambio exacto y luego el runtime puede aplicarlo con re-verificación, rollback y observación. Eso no convierte al proyecto en production-ready.
No en el camino gobernado. Propuesta, verificación, autorización y aplicación son responsabilidades separadas.
Porque una duda importante no debería desaparecer sólo porque el modelo puede redactar una respuesta plausible. Un unknown conserva explícitamente aquello que todavía necesita evidencia o decisión humana.
El Kernel ya puede reconocer si una intención revisada tiene suficiente significado relevante y un objetivo anclado para avanzar. El principal puente pendiente es derivar requirements sin inventarlos y materializar esa base como una Mission suficientemente delimitada, sin pedirle al usuario que haga manualmente esa traducción.
No como promesa universal. Una hipótesis de investigación es que mejor contexto, memoria externa, tools y validators pueden permitir que modelos más pequeños resuelvan tareas útiles con menos dependencia de escala. Se mide caso por caso.
Porque el runtime todavía contiene código experimental, RAW, evidencia y decisiones de distribución que no deberían confundirse con una release pública estable. La presencia pública avanza primero con documentación, estado verificable y ejemplos sanitizados.
No debería. Una UI, un cliente móvil o una integración de IDE deben ser superficies sobre el mismo gobierno: contexto visible, candidate identificable, verificación, evidencia y autoridad explícita. Cambiar la interfaz no debe crear un camino paralelo que saltee esas reglas.
Es una forma de pensar el conjunto durable de proyectos, conocimiento, relaciones, roles y capacidades que una persona o equipo podría llevar entre sesiones, modelos y dispositivos. La versión compartida y federada sigue siendo visión.
Argentic Kernel no intenta reemplazar a las personas ni convertir una IA en autoridad. Intenta que el trabajo con inteligencia artificial pueda conservar intención, contexto, evidencia y control aunque cambie la inteligencia que lo ejecuta.