Modelos
¿Qué cambió en Orán 3.6?
La sexta versión de la tercera generación no supone un salto de capacidades. Es la versión donde las piezas construidas desde 3.1 dejaron de ser características separadas y comenzaron a comportarse como un solo sistema.
Equipo Yaju · 2 septiembre 2026
Cada versión de Orán ha añadido una cosa. Atribución de costos en 3.1, presupuestos que bloquean en 3.2, evaluación en 3.3, optimización en 3.4, Agent Hub en 3.5. Útil individualmente, y hasta hace poco todavía eran cinco cosas que un equipo tenía que reunir.
3.6 es la versión donde dejan de ensamblarse y comienzan a asumirse.
Múltiples integraciones
El mayor cambio práctico es el alcance. Un agente que sólo puede actuar dentro de un sistema es una demostración de un flujo de trabajo más que un participante en él, y la mayor parte del trabajo real cruza tres o cuatro sistemas antes de finalizar.
3.6 amplía a qué se puede conectar un agente, aplicando la misma gobernanza en todos los límites. Una conexión no es un permiso: un agente al que se le concede acceso de lectura a un repositorio y no tiene acceso de escritura no puede enviar, y eso se aplica donde ocurre la acción en lugar de solicitarse en un mensaje.
Conciencia de la situación
Las versiones anteriores ejecutaron un plan. 3.6 realiza un seguimiento de lo que ya sucedió dentro de una ejecución y de lo que cambió debajo mientras la ejecución estaba en progreso.
Esto es importante para el fracaso poco glamoroso que desperdicia la mayor cantidad de dinero: un agente que continúa ejecutando un plan basado en un Estado que desde entonces se ha movido. Repetir un paso que ya tuvo éxito, o actuar sobre un registro que alguien más ha cambiado desde entonces, produce un trabajo que una persona debe deshacer. Darse cuenta es más barato que reparar.
Gestión avanzada de agentes
La consolidación es más visible aquí. Ahora llega un agente con propiedad, límites, presupuesto y evaluación como propiedades en lugar de ejercicios de configuración separados.
En la práctica, esto es lo que cambia el patrón de noventa días sobre el que seguimos escribiendo. La expansión que aparece en la cuarta semana sólo es un problema cuando la atribución y la propiedad se adaptan posteriormente. Cuando tienen la forma predeterminada de un agente, treinta agentes es más un inventario que un misterio.
Visibilidad y control de costes, juntos
3.1 hizo visible el gasto. 3.2 lo hizo detenible. 3.6 coloca a ambos en el mismo lugar que la evaluación que determina si un ahorro fue real.
Esa combinación es el punto. Reducir costos sin evaluación produce productos más baratos y de calidad desconocida, lo que no es un ahorro sino un aplazamiento. El Optimizador propone cambios de modelo, avisos y herramientas, y cada propuesta se califica según sus propias evaluaciones antes de que se valide.
lo que no hace
No fusiona su código, no aprueba su gasto ni decide que una verificación fallida es aceptable. Las acciones con consecuencias reales todavía son una pausa para una persona, y consideramos que es una elección de diseño más que una brecha que cerrar en 3.7.
Tampoco convierte en gobernado un despliegue no gobernado. La versión que ejecute importa mucho menos que si los agentes tienen propietarios, límites, presupuestos y criterios. Un equipo con esos cuatro en una versión anterior está en mejor forma que un equipo sin ellos en esta.
Actualización
Las implementaciones existentes se mueven sin agentes de reconstrucción. Cuando los datos no pueden salir de su infraestructura, 3.6 se ejecuta de forma autohospedada, en su propia nube o completamente aislada, con la misma gobernanza.
Siguiente
La página de versiones enumera todas las versiones desde Keter 1.0 en adelante y lo que cada una agregó. Las páginas del Sistema de orquestación de agentes cubren la capa operativa que consolida esta versión.



