AUI: el mundo construye copilotos. Nosotros invertimos quién tiene el timón.

Una Agentic User Interface es un programa donde una persona y una inteligencia artificial trabajan sobre lo mismo, al mismo tiempo, viendo lo mismo. No es un asistente al lado. Es una cabina compartida. Y cambia quién hace el trabajo y quién decide.

20 de julio de 2026· Actualizado el 22 de julio· Juan Amaya — FractAIll· 13 min

El problema que nadie estaba resolviendo

Cuando le pides a una inteligencia artificial que haga un trabajo real —no que escriba un texto, sino que opere un programa profesional— te encuentras con que solo existen dos caminos, y los dos están rotos.

El primero es automatizarlo todo. Le entregas el trabajo completo y esperas. El problema no es que la máquina se equivoque; es que se equivoca con total seguridad. No levanta la mano. No duda. Te entrega el error con la misma confianza con la que te entrega el acierto, y tú te enteras cuando ya es tarde.

El segundo es ponerle un chat al lado. Tú trabajas y la máquina comenta. Suena razonable hasta que lo haces ocho horas seguidas: te pasas el día describiendo con palabras lo que estás viendo en pantalla, y la máquina adivinando a qué te referías. Son dos mundos separados unidos por un traductor lento: tú.

Al medir una jornada real de trabajo descubrimos algo incómodo: lo lento no era el trabajo. Era la conversación sobre el trabajo. Explicarle a la máquina qué estábamos mirando costaba más que hacer la tarea.

Qué es una AUI

Una AUI elimina esa conversación haciendo algo aparentemente simple: pone a los dos a mirar exactamente lo mismo, con las mismas referencias, en el mismo instante.

No hay que describir nada porque no hay nada que traducir. Cuando la persona ve algo mal, señala. Cuando la máquina hace algo, aparece explicado, en el momento, en palabras normales. Los dos operan el mismo programa. Ninguno está esperando al otro.

La diferencia con un asistente es el valor por defecto. Con un copiloto, si tú no haces nada, no pasa nada: la máquina sugiere y tú ejecutas. En una AUI, si tú no haces nada, el trabajo igual avanza. Tú apareces para corregir, vetar y darle criterio. Cambia quién lleva el timón.

Fig 1 · las tres topologías de colaboración
Automatización total «entrego y espero» persona agente (opaco) bucle cerrado error silencioso ✕ Copiloto / chat al lado «describo, comenta» persona agente canal = prosa trabajo (traducido) costo = describir ⚠ AUI «señalo el punto» persona agente estado compartido mismas coordenadas corrige señalando ✓
En automatización el juicio humano sale del bucle y el error se descubre tarde. En el copiloto, persona y máquina se hablan por prosa: cada corrección cuesta una traducción. En la AUI ambos direccionan el mismo estado por un sistema de coordenadas común — la corrección es una operación más, de costo marginal ≈ 0.

Para qué sirve

Para el trabajo donde la máquina es superior ejecutando y ciega juzgando. Que es casi todo el trabajo creativo profesional.

Nosotros lo construimos sobre un editor de video. Una inteligencia artificial puede revisar once horas de material y encontrar cada momento en que aparece un objeto, sin cansarse y sin saltarse nada. Ningún humano hace eso. Pero no tiene ni idea de cuál de esos momentos es bonito. Y lo bonito es el producto.

El mismo patrón aparece en cualquier oficio donde el volumen es inhumano pero el criterio es irremplazable: revisar contratos, diagnosticar, auditar cuentas, diseñar, investigar. La máquina barre; la persona decide qué importa.

Por qué esto cambia las cosas

Porque invierte el papel del humano

Hoy la industria trata a la persona como un costo que hay que eliminar. La meta declarada es reducir la intervención humana hasta cero; el humano es una muleta temporal mientras el modelo mejora.

Una AUI parte de lo contrario: el criterio de la persona es el activo escaso, el único insumo que no se puede comprar ni descargar. Todo lo demás —velocidad, resistencia, memoria, precisión— la máquina ya lo tiene de sobra.

Porque no es un andamio, es una cabina

La objeción obvia es: «esto sirve mientras la IA aprende; después se automatiza todo y la interfaz sobra». Creemos que es exactamente al revés.

Cuando la máquina hace dos acciones por minuto, puedes revisar cada una. Cuando haga dos mil, no. Es justo entonces cuando saber qué está haciendo, con qué está tocando tu trabajo y qué tan bien está respondiendo deja de ser un lujo y pasa a ser la única forma racional de delegar. Nadie entrega el control de algo que no puede auditar.

Los aviones tienen piloto automático hace ochenta años y siguen teniendo pilotos. El trabajo del piloto cambió: dejó de mover el timón y pasó a decidir. La cabina no desapareció — le pusieron mejores instrumentos.

Porque amplifica a una persona en vez de reemplazar a un equipo

Esta es la parte que cambia el modelo de negocio. La automatización clásica optimiza para sustituir mano de obra: cincuenta personas cuestan mucho, hay que bajar eso.

Una AUI optimiza otra cosa: que el criterio de una sola persona alcance para el trabajo de cincuenta, sin diluirse. No produce un producto sin autor. Produce un producto que sigue teniendo el autor de siempre, hecho a una escala que antes era imposible.

Lo que de verdad es innovador

Que un humano corrija a una máquina no es una idea nueva: así funciona todo sistema serio de inteligencia artificial. Lo que sí es nuevo —y es lo difícil— es dónde ocurre esa corrección.

En la industria, corregir pasa aparte y después: el sistema trabaja, alguien exporta los errores, otra persona los revisa en otra herramienta, semanas más tarde el modelo se reentrena. Hay dos mundos: el producto y la fábrica de datos que lo alimenta.

Nosotros los volvimos uno solo. La corrección ocurre dentro de la misma pantalla donde se trabaja, en el mismo instante, sin abrir nada más. No hay una tarea de revisión: la revisión es el trabajo.

El efecto es que corregir sale gratis. No cuesta tiempo extra porque no es una actividad aparte — es un gesto dentro de la actividad que ya estabas haciendo. Y como sale gratis, ocurre. Que es más de lo que puede decir cualquier proceso de anotación del mundo.

Por qué eso importa tanto

Durante nuestras pruebas, el sistema identificó un rascacielos, una camiseta azul y el letrero de una empresa como si fueran un teléfono celular. Con una seguridad de entre 98 y 100 por ciento.

Ningún proceso automático habría detectado eso jamás, porque para el sistema esos casos encajaban perfecto. Hizo falta un ojo humano, mirando, durante el trabajo normal, diciendo «eso no es».

El sistema no había aprendido qué es un teléfono. Había aprendido qué es un rectángulo vertical oscuro. Y estaba absolutamente convencido.

Cuatro correcciones humanas valieron más que mil ejecuciones correctas. Ese es el argumento entero, en una frase.

Cómo se ve un día de trabajo

La teoría se entiende mejor con lo que pasó de verdad. Este es un fragmento real de una jornada seleccionando material para un video.

El agente revisa once minutos de grabación y marca 1.542 momentos donde cree que aparece el objeto que buscamos. Ningún humano hace eso: son horas de trabajo mecánico, y las hace en minutos, sin saltarse un solo cuadro.

Entonces empieza la parte humana. La persona recorre el material y va señalando. No escribe reportes ni llena formularios: mira y dice. En una sesión de menos de una hora aparecieron seis observaciones:

Lo que habíaLo que el sistema dijoTipo de falla
El objeto, ya visibleLo marcó medio segundo tardeOmisión — se pierde material bueno
El objeto, pero con una personaCorrectoRegla de negocio, no error
Un grafiti en un muro100% de confianzaFalso positivo
Una camiseta azul98% de confianzaFalso positivo
El letrero de una empresa100% de confianzaFalso positivo
Un rascacielos de vidrio99% de confianzaFalso positivo

Puestos en fila, los cuatro falsos positivos cuentan una historia que ningún número por separado contaba: un muro, una camiseta, un letrero y un edificio. Todos rectangulares. Todos verticales. Todos oscuros.

El sistema no había aprendido qué es un teléfono. Había aprendido qué es un rectángulo vertical oscuro. Y estaba absolutamente convencido.

Ese diagnóstico no salió de revisar el código ni de auditar los datos de entrenamiento. Salió de una persona mirando su propio trabajo y comentando de paso. Costó cero tiempo extra, porque revisar el material era el trabajo que había que hacer de todas formas.

Y hay un detalle que resultó ser el más importante de todos: el sistema se había entrenado únicamente con aciertos. Miles de ejemplos de lo que sí era. Ni uno solo de lo que no era. Por eso aprendió la forma en vez del concepto — y por eso las correcciones de esa hora valen más que ampliar el conjunto de entrenamiento al doble.

Para quién es esto

Una AUI rinde cuando se cumplen tres condiciones a la vez. Si falta una, probablemente no la necesitas:

Edición y producción audiovisual. Revisión legal. Diagnóstico. Auditoría. Investigación. Diseño. Cualquier oficio donde alguien pasa el día diciendo «este sí, este no» sobre un montón demasiado grande para mirarlo entero.

Cómo saber si tu software está listo

La conversión a AUI suele ser mucho más barata de lo que parece, porque el trabajo pesado ya está hecho. Tres preguntas lo dicen casi todo:

1. ¿Tu lógica sustantiva puede correr sin la interfaz? Si al quitar la ventana el motor sigue funcionando, ya tienes el 90% del camino. La mayoría lo tiene y no lo sabe: la interfaz está en la ruta por costumbre, no por necesidad.

2. ¿Existe una forma inequívoca de nombrar un punto exacto de tu contenido? Un segundo, una línea, una celda, una coordenada. Si dos personas pueden señalar el mismo sitio sin discutir, tienes espacio de referencia compartido.

3. ¿Corregir un error es hoy un trabajo aparte? Si hay que exportar, abrir otra herramienta y etiquetar, esa es toda la distancia que hay que cerrar — y es donde está el valor.

Lo que aprendimos equivocándonos

Vale la pena contarlo porque son los errores que va a cometer cualquiera que intente esto.

Creímos que el modelo estaba mal, y estaba bien. Al ver las etiquetas en pantalla dedujimos que se estaba usando un modelo genérico en vez del nuestro. Falso: el rótulo lo escribía nuestro propio código. La lección es incómoda y general — leímos un cartel que nosotros mismos habíamos colgado y construimos una teoría encima. En sistemas con IA la evidencia visible casi nunca es la evidencia real.

Quisimos esconder el síntoma en vez de mover la causa. Un indicador tapaba la línea de tiempo y la primera reacción fue ocultarlo en el modo nuevo. Eso habría dejado el problema intacto para el modo normal y para el futuro. La causa era que ese elemento flotaba en vez de ocupar espacio propio. Arreglarlo de raíz costó lo mismo y resolvió las dos versiones a la vez.

Elegimos por el usuario donde debíamos preguntarle. Escogimos un sonido de aviso y resultó insoportable. La corrección no fue cambiarlo por otro que también elegimos nosotros: fue hacerlo configurable. En una AUI, cada vez que el sistema decide algo que es cuestión de gusto, está tomando una decisión que no le corresponde.

La capa técnica

Cómo funciona por dentro

Lo que sigue es la arquitectura conceptual, no el plano de construcción. Describimos qué propiedades tiene el sistema y qué invariantes sostiene, porque creemos que las ideas deben circular. La implementación es nuestra.

Los cinco invariantes

Invariante I

Espacio de referencia compartido

Persona y agente operan sobre un mismo sistema de coordenadas determinista, persistente y siempre visible, con resolución suficiente para ser reproducible: cualquiera de los dos puede nombrar un punto y el otro llega exactamente ahí, sin ambigüedad ni negociación. Sin este invariante no hay AUI; hay dos monólogos sincronizados por casualidad.

Fig 2 · direccionamiento común sobre la línea de tiempo
00:00 02:15 04:44 07:50 09:13 11:37 agente → t=[2.24,4.74] persona → t=3.83 estado residente (segmentos)
Ambos apuntan a la misma coordenadat = 3.83 s, un rango, un píxel. La referencia es determinista y reproducible: idéntica orden ⇒ idéntico referente, sesión tras sesión. Esa es la condición que colapsa la conversación.
Invariante II

Desacople entre motor y presentación

La capa de presentación deja de estar en la ruta crítica de ejecución: pasa de ser el medio por el que se opera a ser un observador del estado. La consecuencia práctica es que la capacidad del sistema deja de estar acotada por el costo de dibujar la interfaz — un techo que la mayoría de las aplicaciones profesionales tiene sin saberlo.

Fig 3 · ruta crítica de ejecución · antes vs después
Antes · presentación en la ruta agente presentación(medio) motor cuello: cada orden cruza el dibujo Después · presentación como observador agente motor presentación(observador) ruta directa: agente → motor
La GUI deja de ser el conducto obligatorio y pasa a reflejar el estado. El mismo motor sirve al humano (por la pantalla) y al agente (por el canal de control) sin divergir — y sin estar en la ruta de ejecución. Cerca del 90% de la lógica ya estaba, sin diseñarlo, fuera de la GUI.
Invariante III

Legibilidad de la intención en tiempo real

Toda operación del agente se traduce a lenguaje natural en el momento en que se recibe, con una distinción explícita entre operaciones de lectura y operaciones de mutación. El sistema declara cuando no sabe traducir algo, en vez de aproximar: un traductor que infiere es una superficie de confianza falsa.

Invariante IV

Observabilidad de la conexión

Identidad del cliente, latencia disgregada por tramo, caudal de operaciones, superficie de capacidades alcanzable y traza de uso — todo instrumentado y expuesto al usuario final, no a un panel de operaciones. Las magnitudes no medibles se reportan como ausentes. Una métrica inferida en un panel de auditoría es peor que ninguna métrica.

Invariante V

La corrección como entrada de primera clase

El canal de corrección no es telemetría ni un formulario aparte: es una entrada del sistema con el mismo estatus que cualquier orden, emitida desde la superficie de producción y con costo marginal cercano a cero para el operador. Se capturan los dos signos —falso positivo y omisión— porque un modelo entrenado solo con aciertos aprende la forma, no el concepto.

Fig 4 · los cinco invariantes y sus dependencias
AUI 5 invariantes Ireferencia compartida IImotor ⊥ presentación IIIintención legible IVconexión observable Vcorrección 1ª clase — — línea punteada: «habilita» · I→III · II→IV · V cierra el lazo hacia I
No es un stack ni un producto: es un conjunto de invariantes. Cualquier software que los satisface es una AUI, con independencia de su implementación. La referencia compartida (I) habilita la legibilidad (III); el desacople (II) habilita la observabilidad (IV); la corrección (V) cierra el lazo de vuelta al espacio de referencia.
Fig 5 · Invariante V · el lazo de corrección
operación del agente veredicto humano ✓ correcto → se conserva ✕ falso positivo ø omisión (recuperado) dataset de corrección reentreno del modelo aprende el concepto, no la forma
Se capturan los dos signos: falso positivo (marcó algo que no era) y omisión (dejó pasar algo que sí era). Cada marca es una entrada de coordenada de costo ≈ 0 que alimenta el reentrenamiento. Un modelo entrenado solo con aciertos aprende la forma; con los dos signos aprende el concepto.

El hallazgo contraintuitivo

Instrumentamos el enlace agente–aplicación como un canal de plano de control disjunto del plano de datos. Su primera implementación exhibió una distribución de latencia y caudal que no anticipábamos:

476 ms
latencia extremo a extremo
~0 ms
de eso, cómputo real
83 B
tamaño de una orden
10 kbit/s
caudal efectivo

La latencia extremo a extremo estaba dominada por transporte, no por cómputo. Descomponiendo Ltotal = Ltransporte + Lejecución, el término de ejecución es ≈ 0: cada operación es una referencia de tamaño O(1) despachada contra estado residente — no serializa ni transfiere el operando. En esa primera versión el transporte era un buzón NDJSON mediado por el sistema de archivos y sondeado a intervalo fijo, de modo que el término dominante de Ltransporte era el período de sondeo, no la serialización ni la ejecución. El sistema parecía acotado por capacidad de proceso y estaba acotado por una decisión de mecanismo — trivial y corregible.

La corregimos. Sustituimos el sondeo por entrega dirigida por eventos, colapsando Ltransporte al piso del round-trip de IPC. Remedido sobre el mismo hardware:

3 ms
latencia extremo a extremo
~0 ms
de eso, cómputo real
16–66 B
tamaño de una orden
64 kbit/s
caudal efectivo

La misma referencia de O(1) bytes, entregada ≈150× más rápido: Ltransporte pasó de 476 a 3 ms y el caudal del canal de control de 10 a 64 kbit/s. No se tocó el motor ni la arquitectura conceptual — únicamente la capa de entrega, exactamente donde el diagnóstico ubicaba el término dominante.

Fig 6 · Ltotal por versión · escala logarítmica
1 ms 10 100 1000 primera versión · NDJSON sondeado L_transporte (período de sondeo) 476 ms hoy · entrega dirigida por eventos 3 ms piso round-trip IPC ≈ 158× más rápido L_ejecución ≈ 0 en ambas — el motor nunca fue el cuello
El sistema parecía acotado por capacidad de proceso y estaba acotado por una decisión de mecanismo. Sustituir el sondeo por entrega dirigida por eventos colapsó Ltransporte al piso del round-trip de IPC — sin tocar el motor ni la arquitectura.

El caudal del plano de control (≤ 102 kbit/s) es independiente del volumen de datos que gobierna (109–1010 B residentes). La complejidad de la interacción es O(decisiones), no O(|datos|): el operando nunca atraviesa el canal, solo lo hace la referencia que lo selecciona. Ese desacople es la propiedad estructural del modelo:

Una orden pesa decenas de bytes y direcciona gigabytes residentes. Por el canal no viaja el operando sino su referencia —la intención codificada como coordenada—: el volumen permanece estacionario y solo se transmite el selector de la decisión.
plano de control (intención) plano de datos (operando residente)
Fig 7 · topología control / datos
AGENTE emite órdenes canal de control órdenes ≈ 10¹–10² B · 64 kbit/s APLICACIÓN motor ejecuta ref. estado residente 10⁹–10¹⁰ B estacionario no cruza el canal la referencia selecciona una coordenada del estado; el dato no se transmite
El operando (gigabytes de material) vive junto al motor y jamás atraviesa el enlace. La orden es un puntero: «conservar t=[2.24, 4.74]» pesa decenas de bytes y moviliza gigabytes residentes. La complejidad de la interacción es O(decisiones), no O(|datos|): duplicar el proyecto no cambia la carga del canal.

Bajo ese desacople, escalar deja de ser un problema de capacidad de canal. Con Ltransporte en el piso del round-trip y órdenes de 101–102 B, el caudal sostenible de órdenes queda acotado por la tasa de round-trips (~102–103 ops/s): del orden de cinco órdenes de magnitud de headroom sobre la utilización observada. La cota superior efectiva no es la capacidad del canal sino la tasa semántica — cuántas decisiones por segundo tiene sentido emitir.

Fig 8 · utilización · capacidad · techo semántico (escala log)
10⁻¹10⁰10¹ 10²10³10⁴ ops/s utilización real capacidad del canal techo semántico ≈ 5 órdenes de headroom físico
La capacidad de transporte excede en órdenes de magnitud lo que se usa. El techo operativo real es cuántas decisiones por segundo tienen sentido — una cota semántica, no de infraestructura. Escalar deja de ser un problema de canal.

Lo que descubrimos sobre el motor

Cerca del 90% de la lógica sustantiva de nuestra aplicación —detección, transformación, composición, exportación— ya era completamente independiente de la interfaz gráfica. Nadie lo había diseñado así: simplemente estaba mal enrutado, obligado a pasar por la capa de dibujo por convención, no por necesidad.

Presumimos que esto es general. La mayoría del software profesional ya contiene, sin saberlo, el motor que una AUI necesita. Lo que falta no es reescribirlo: es dejar de obligar a que todo pase por la pantalla.

Sobre la evolución sin regresión

Cada capacidad nueva ingresa acompañada de su propia verificación ejecutable. La compuerta de integración valida el comportamiento observable del sistema completo antes de permitir que una versión se instale; si un solo criterio falla, la versión se descarta y se restituye automáticamente la última buena. No es política de equipo: es una condición mecánica.

El resultado es que una AUI puede evolucionar rápido sin que la confianza del operador se degrade — que es, al final, el único recurso que el sistema no puede reconstruir solo.

Estado

Implementado y en producción sobre FullFrame Studio, nuestra suite de edición de video nativa para macOS. No se construyó una aplicación nueva: se añadió un modo de operación a la que ya existía.

Ese es, probablemente, el hallazgo más transferible de todo el proyecto. Una AUI no reemplaza tu producto. Le agrega una forma de operarse.

Preguntas que nos han hecho

¿Esto no es simplemente human-in-the-loop?

El principio es el mismo y no pretendemos haberlo inventado: todo sistema serio de IA tiene humanos corrigiéndolo. La diferencia está en la ubicación y el costo de esa corrección. En la práctica habitual ocurre fuera del producto, después, en otra herramienta y a cargo de otra persona. Aquí ocurre dentro, durante, en la misma pantalla y a cargo de quien ya estaba trabajando. Esa distancia es toda la diferencia entre un proceso que se hace a veces y uno que se hace siempre.

¿No es más lento tener a una persona metida en el proceso?

Al contrario, y es lo que más sorprende al medirlo. La persona no ejecuta: decide. El tiempo humano se gasta únicamente donde hace falta criterio, que resulta ser una fracción pequeña del trabajo total. Lo que sí es lento es lo otro: descubrir tres semanas después que un proceso automático venía produciendo resultados equivocados con toda seguridad.

¿Qué pasa cuando el modelo mejore?

Sube la altura de la conversación, no desaparece. Se pasa de «corta en este punto» a «arma esto con este criterio». Cada escalón automatiza el anterior, y en cada escalón sigue haciendo falta alguien que diga si el resultado sirve. Lo que no cambia es que la responsabilidad tiene dueño, y el dueño necesita ver.

¿Cuánto cuesta convertir un producto existente?

Menos de lo que parece, y casi todo el costo está en un solo sitio: sacar la lógica de la ruta crítica de la interfaz. No es reescribir el producto — es dejar de obligar a que todo pase por la pantalla. En nuestro caso, el motor ya estaba listo sin que nadie lo hubiera planeado.

Hacia dónde va

Cuando publicamos esto por primera vez, el siguiente escalón era que el agente viera el lienzo mientras corre, al mismo tiempo que la persona, en vez de pedir una captura y esperar. Ese canal ya está construido: no solo comparten coordenadas, comparten la misma imagen, en el mismo instante. Se acabó el «mándame una captura del minuto siete».

El frente nuevo es más ambicioso: sacar los sentidos del agente fuera del programa compartido. Hasta ahora la cabina era una sola —el editor—, y un agente que solo puede ver y tocar la ventana que tiene delante trabaja con anteojeras. Le dimos dos sentidos que funcionan sobre cualquier programa de la máquina, con una regla intocable: nunca robarle el foco a la persona.

Puede ver la ventana de cualquier aplicación aunque esté detrás, minimizada o en otro escritorio —leyendo lo que el sistema ya dibujó, sin traerla al frente— y puede operarla: apretar un botón o entrar a un menú directamente, sin mover el cursor de la persona. Mientras alguien trabaja en una cosa, el agente vigila un proceso en otra, comprueba un resultado o dispara un paso, y no interrumpe. Con un freno de mano deliberado: por defecto describe lo que haría antes de hacerlo; solo actúa cuando se le autoriza.

Es la misma idea de la AUI, estirada: no un agente que te arrebata el volante del computador, sino uno que comparte la percepción de toda la máquina sin quitarte el control de ninguna parte. La cabina deja de ser una ventana y pasa a ser el escritorio entero.

Cuando todo esto se asiente, la última asimetría que queda entre una persona y un agente operando el mismo trabajo no será la velocidad, ni la memoria, ni el alcance. Será el criterio. Que es exactamente donde queremos que esté.