Aviso: Este contenido fue traducido automáticamente. Enviar feedback

Usuario Headless

16 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

Cuando el usuario principal del software empresarial pasa a ser un agente de IA, el marco principal-agente de 1976 de Jensen y Meckling deja de ser una metáfora. La clase verificadora que emerge al otro lado es la próxima anomalía de fijación de precios del mercado laboral.

De usuario-como-persona a usuario-como-agente: la redenominación que está reconfigurando el software y el trabajo

A mediados de abril de 2026, Salesforce anunció Headless 360 en TDX: una reestructuración de la plataforma en torno a APIs, herramientas de Model Context Protocol e interfaces de línea de comandos (Salesforce; VentureBeat). El lanzamiento no fue un refresh de UX. Fue el reconocimiento de que el usuario principal del software empresarial ya no es un ser humano.

La elección de las palabras importa. Una década de ortodoxia del diseño convirtió "usuario" en sinónimo de "persona". Los perfiles tenían nombre, foto y objetivos; los design sprints empezaban con mapas de empatía; los wireframes imaginaban la mirada de alguien recorriendo una pantalla. Headless 360 no refina esa ortodoxia. La desagrega. El navegador se convierte en una superficie heredada. La vista de hoja de cálculo pasa a ser una entre muchas salidas, no la salida. La pantalla es opcional.

La prensa del sector leyó el cambio con la misma claridad que Salesforce. VentureBeat describió el lanzamiento como infraestructura para agentes de IA, mientras que PPC.land lo presentó como un movimiento que elimina el navegador como interfaz obligatoria (VentureBeat; PPC.land). Salesforce dijo que el lanzamiento incluía más de sesenta MCP tools y más de treinta coding skills, además de un conjunto más amplio de superficies orientadas a agentes (Salesforce). Esa es la escala de un giro de plataforma, no de un lanzamiento de producto.

El cambio también se ve en otras partes de la capa de tooling. The New Stack observó este mes que Cursor, Claude Code y el Codex de OpenAI se estaban "fusionando en una sola stack de AI coding que nadie planeó" (The New Stack). Las plataformas adyacentes también están sumando sus propias capas para construir agentes, como deja claro la documentación de Rovo de Atlassian (Atlassian). Cada uno de esos productos presupone un operador capaz de leer, editar y confiar en artefactos generados sin examinarlos línea por línea. El artefacto ya no es el dashboard. El artefacto es el comportamiento.

Lo que está ocurriendo no es un paso adelante en user experience. Es una redenominación de quién es el usuario. Durante tres décadas, el software empresarial trató al humano como principal: la entidad cuya atención, aprobación y error constituían el bucle de feedback del sistema. El humano hacía clic; el software respondía. El bucle era estrecho porque la latencia entre intención e input era baja. Las empresas de software optimizaron cada centímetro de ese circuito: formularios más rápidos, menos clics, dashboards más bonitos.

Ese bucle se está rompiendo. No porque el humano esté siendo eliminado. El humano sigue siendo la fuente de la intención, el propietario de la cuenta, quien paga la factura. Pero el humano ya no es la entidad sentada en la consola. Hay otra cosa ahí. Escribe. Hace llamadas de API. Opera el software.

Llamar "usuario" a esa cosa fuerza la palabra. Más exactamente, es un agente que opera en nombre de un usuario. Y es en la distancia entre ambos, entre principal y agente, donde se abre el nuevo terreno.

La interfaz que desaparece

La trayectoria venía preparándose desde hace tiempo. En Lenny's Newsletter, Marc Andreessen describió el lenguaje natural como la siguiente capa de abstracción por encima de los lenguajes de más alto nivel, después de que el código máquina y el assembly cedieran paso a C y Python (Lenny's Newsletter). Andrej Karpathy, ex Tesla y OpenAI, formalizó el movimiento más reciente con su taxonomía Software 1.0, 2.0 y 3.0, donde los prompts en inglés se convierten en una forma de programar LLMs (Y Combinator podcast). Cada capa hizo que el ordenador fuera accesible para una población más amplia y volvió obsoleta otra más estrecha.

Guillermo Rauch, fundador de Vercel, expresó la implicación en términos tajantes en ese mismo podcast: muchos trabajos de programación que antes eran especializados se están convirtiendo en tareas de traducción, sobre todo de la intención o el diseño hacia la implementación (Lenny's Newsletter). La traducción, del diseño al código, de la política a la configuración, de la especificación al schema, ha sido la capa intermedia del trabajo de software de cuello blanco durante dos generaciones. La tesis de Rauch no es que programar desaparezca. Es que desaparecen los traductores.

Headless 360 es la versión enterprise del mismo movimiento, y no es un caso aislado. En la misma ventana, Oracle, SAP, Workday, y ServiceNow lanzaron movimientos paralelos de plataforma para agentes. El navegador era una capa de traducción: intención humana expresada mediante clics en formularios que escribían en tablas a través de middleware que llamaba APIs. Elimina el navegador y la cadena se contrae: la intención pasa a la llamada de API, con el agente haciendo la traducción. El administrador que sabía recorrer diecisiete pantallas para configurar una regla de compliance pierde el foso que le daban esas pantallas. También lo pierde el especialista de operaciones que había memorizado el orden de los checkboxes. También el formador que enseñaba la ruta de clics a las nuevas incorporaciones.

¿Qué sustituye a esos fosos? No otros nuevos en la misma capa. La capa misma se está disolviendo. En su lugar aparece un conjunto distinto de artefactos (el system prompt, el schema de la herramienta, el harness de evaluación) y un conjunto distinto de profesionales que los producen. Anthropic, OpenAI y Salesforce están, cada una a su manera, desplegando los elementos básicos de esa capa de sustitución (Anthropic MCP docs; OpenAI function calling; Salesforce).

Lo contraintuitivo de una interfaz que desaparece es que el trabajo no desaparece con ella. El trabajo se traslada. Alguien todavía tiene que decidir qué significa una regla de compliance, cuáles son las excepciones aceptables y qué debe pasar cuando la propuesta del agente roza el límite de la política. Esa persona ya no está haciendo clic. Cada vez más, está revisando.

La pregunta es cómo llamarla.

El problema principal-agente, en versión máquina

La literatura económica tiene un marco de hace cincuenta años para exactamente esta situación. En 1973, Stephen Ross publicó un artículo en el que introducía lo que llamó el problema del principal: una situación en la que una parte delega una acción en otra y el agente posee información privada que el principal no puede observar por completo (Ross 1973). Tres años después, Michael Jensen y William Meckling formalizaron el marco en Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, definiendo los costes de agencia como la suma del gasto de monitoreo del principal, el gasto de bonding del agente y la pérdida residual (Jensen and Meckling 1976). La distancia entre lo que quería el principal y lo que entregaba el agente es toda la lógica del marco.

Durante medio siglo, el marco se aplicó a agentes humanos. Los accionistas delegaban en los ejecutivos. Los clientes delegaban en los abogados. Los pacientes delegaban en los médicos. Cada elaboración de la teoría (compensación ligada al rendimiento, deber fiduciario, comités de auditoría, reglas de independencia del consejo) era un intento de reducir la pérdida residual remodelando el monitoreo.

En 2026, el marco se aplica con una literalidad poco habitual. El software no tiene interés propio ni deber fiduciario, así que la analogía no es perfecta, pero los supuestos estructurales encajan lo bastante bien como para que las categorías de coste se trasladen sin demasiado esfuerzo. Dos artículos recientes de management, Humberd and Latham (2026) en el Journal of Management Studies y Jarrahi and Ritala (2025) en la California Management Review, hacen el mismo movimiento de forma independiente: tratan la IA como un nuevo tipo de agente dentro de la empresa y preguntan cómo son el monitoreo y el bonding cuando el agente es software.

La información privada, en el marco original, era el conocimiento superior del agente sobre condiciones que el principal no podía observar. En la versión máquina, la información privada es el razonamiento interno del modelo: la cadena de activaciones que produjo la salida y que no puede inspeccionarse desde la superficie de la API. La divergencia de intereses, en el original, era el agente persiguiendo beneficio personal a costa del principal. En la versión máquina, es el objetivo de entrenamiento divergiendo de la intención del usuario: el modelo optimiza la plausibilidad en lugar de la corrección, la apariencia de utilidad en lugar de la sustancia. El coste de monitoreo, en el original, era el precio de auditar las acciones del agente. En la versión máquina, es el coste de verificar salidas del modelo a escala de producción, un coste que escala con el volumen de salida y no con la importancia de la tarea. La pérdida residual, en el original, era la diferencia entre el resultado previsto y el resultado real. En la versión máquina, es alucinación, deriva de alcance, fallo silencioso: toda la taxonomía de errores que un principal quizá nunca detecte.

La teoría anticipó cada dinámica que los equipos que despliegan agentes están redescubriendo ahora. Lo que no anticipó fue la escala. Un abogado humano produce un documento cada vez. Un ejecutivo humano toma una decisión cada vez. Supervisar ese volumen es caro, pero acotado. Un agente de software produce documentos, decisiones y efectos laterales a una velocidad que ningún principal puede inspeccionar por defecto. El coste de monitoreo, en el marco clásico, era una cuestión de diligencia. En la edición máquina, es una cuestión de capacidad.

Esa capacidad, allí donde existe, se concentra en un grupo pequeño y sin nombre. Son el cuello de botella. Son, aunque todavía nadie lo haya dicho, una clase.

La clase verificadora

Alexander Embiricos, del equipo de Codex de OpenAI, describió el cuello de botella actual como validación humana y code review, no generación bruta de código (Lenny's Newsletter). Embiricos estaba describiendo un workflow específico (agentes de coding asíncronos que arrancan, producen cambios y los devuelven para aprobación), pero el diagnóstico se generaliza. En distintos dominios, el paso que determina si la salida de un agente entra en producción es la pasada humana que viene después.

Esa pasada es más difícil de lo que parece. Hamel Husain y Shreya Shankar, investigadores de AI evals, sostuvieron que los criterios de evaluación cambian a medida que la gente inspecciona más salidas, lo que significa que la rúbrica no puede fijarse por completo de antemano (Lenny's Newsletter). El verificador no solo está contrastando el trabajo del agente con una especificación; está construyendo la especificación en tiempo real, en respuesta a la distribución de salidas que el agente realmente produce. Evaluar, en este régimen, no consiste en aplicar una test suite. Consiste en inventar una bajo presión.

En la práctica, esto adopta la forma de un suelo de defectos que el generador introduce de forma consistente y un techo de capacidad de revisión que el verificador puede aportar de forma consistente, con la brecha entre ambos ampliándose a medida que escala el uso. El suelo es medible: la actualización de primavera de 2026 de Veracode encontró que el 55 por ciento de las tareas evaluadas de generación de código con IA eran seguras, lo que implica una tasa aproximada del 45 por ciento de fallos de seguridad conocidos en el conjunto analizado (Veracode). Un debate de Y Combinator sobre su cohorte W25, recogido por TechCrunch, dijo que alrededor de una cuarta parte de la promoción tenía codebases generadas por IA en un 95 por ciento (TechCrunch). Generación de alto volumen chocando con producción apenas auditada no es una predicción; ya es habitual.

Nada de esto es exclusivo del código. El patrón se repite en revisión legal, en toma de notas médicas, en análisis financiero, en copy de marketing. En cada dominio, el agente produce en volumen; un humano revisa; el revisor es la restricción. El detalle específico cambia según el sector. La forma de la función, no.

Este rol no tiene título. No tiene carrera definida. No aparece en organigramas. Hoy lo ocupan quienes casualmente están cerca: el ingeniero sénior que se suponía que debía estar escribiendo features, la staff lawyer que se suponía que debía estar asesorando a clientes, la lead designer que se suponía que debía estar creando. Su puesto formal es otra cosa. Su trabajo real es revisar lo que produjo un agente y decidir si se publica.

Son la Clase Verificadora. El nombre es nuevo; la función, no. Pero las condiciones sí lo son.

Lo que distingue a un verificador de un revisor, editor, auditor o aprobador no es el acto de revisar. Es la concurrencia de tres condiciones.

La cola aguas arriba no tiene tope: la salida la produce un sistema cuyo throughput escala con gasto en API, no con las horas de trabajo de otro humano. El throughput del propio verificador no: está limitado por el ancho de banda cognitivo humano y no escala con la misma palanca. La rúbrica es emergente: como describen Husain y Shankar, tiene que formarse en respuesta a la distribución de salidas que el sistema realmente produce, no definirse de antemano.

Los editores y auditores cumplen una o dos de esas condiciones. El verificador cumple las tres a la vez. Ese es el núcleo económico del rol.

La cuestión distributiva

La narrativa dominante sobre el efecto de la IA en el trabajo se ha centrado en el desplazamiento: los sistemas generativos comprimirán la mitad de la distribución de habilidades, volverán redundantes a los trabajadores del conocimiento de rango medio y concentrarán las ganancias en los propietarios del capital y en el talento de frontera. Esa narrativa asume el caso sin fricción: un agente que pone su propia salida en producción sin revisión.

La verificación cambia la forma del problema. A diferencia de la generación, la verificación está cargada de dominio. Un agente de propósito general puede redactar una solicitud de patente, un informe radiológico, un comunicado trimestral de resultados y una aprobación de crédito. El verificador de cada uno debe poseer el conocimiento de dominio de un abogado de patentes, un radiólogo, un controller y un analista de crédito, respectivamente. Ese conocimiento no es transferible. No se sintetiza rápido. Se adquiere a lo largo de años de formación específica en un contexto específico, y es lo más difícil de externalizar.

La consecuencia contraintuitiva es que la verificación puede relocalizar ciertos tipos de expertise. La deslocalización, en décadas anteriores, dependía de que la ejecución estuviera desacoplada del contexto: la especificación se escribía una vez, en el país de origen, y se ejecutaba muchas veces en el extranjero. La verificación no puede desacoplarse. Cada salida es un juicio nuevo. Cada juicio exige el contexto que el agente no aportó.

El State of the Designer 2026 de Figma, una encuesta a 906 diseñadores digitales realizada con NewtonX, documentó una reconfiguración brusca del propio rol (Figma report; Figma blog). El trabajo de ejecución (la producción de mockups, wireframes y prototypes) se ha desplomado en coste, mientras que el trabajo de juicio (la selección, curaduría y dirección editorial de las opciones generadas) se ha convertido en el cuello de botella que describen los encuestados. En una publicación aparte centrada en contratación, Figma sostuvo que la IA está aumentando la demanda de diseñadores, especialmente de perfiles sénior con mejor criterio y más experiencia (Figma hiring post). Las dos afirmaciones operan en niveles distintos. Una es lo que los diseñadores reportan sobre su propio trabajo; la otra es cómo Figma lo interpreta para sus clientes enterprise. Ambas apuntan en la misma dirección. El cargo no cambió. El trabajo sí.

En la entrevista de febrero de 2026 de Lenny Rachitsky, Lazar Jovanovic, de Lovable, enmarcó la habilidad de reemplazo como claridad, criterio, juicio y mejor toma de decisiones, y no velocidad bruta de coding (Lenny's Newsletter). La claridad, en este contexto, es la capacidad de especificar una intención que el agente no pueda malinterpretar y de reconocer cuándo la ha malinterpretado. Es el mismo movimiento cognitivo que exige la verificación, solo expresado desde la dirección opuesta.

Estas observaciones apuntan en una dirección. El mercado laboral no se está aplanando hacia una élite estrecha de frontera. Se está estratificando a lo largo de un eje nuevo (generador frente a verificador) que atraviesa roles ya existentes. La posición de más valor es la del verificador en un dominio que importa, con el contexto que no se puede guionizar fácilmente y el juicio que no se puede automatizar fácilmente. La compensación irá detrás de eso. También la fricción de contratación: el número de personas capaces de generar a escala está explotando; el número de personas capaces de verificar a escala, no.

Esa asimetría es la próxima anomalía de fijación de precios del mercado laboral.

Las dos interfaces

Todo producto de software construido en los próximos cinco años llevará dos interfaces, las nombren o no sus diseñadores.

La primera es la interfaz de protocolo: la superficie a través de la cual los agentes operan el sistema. Sus primitivas son el endpoint de API, la definición de la MCP tool, el comando de CLI, el alcance de permisos, el rate limit. Su disciplina de diseño es la legibilidad para un modelo: naming que resiste la ambigüedad, schemas que fallan hacia el lado seguro, documentación lo bastante densa para retrieval y lo bastante estructurada para tool selection. Headless 360 de Salesforce es una de las primeras declaraciones públicas de lo que esta interfaz parece a escala enterprise, mientras que el Model Context Protocol de Anthropic y las especificaciones de tool use de OpenAI forman parte de la infraestructura del ecosistema que la rodea (Salesforce; Anthropic MCP docs; OpenAI function calling).

La segunda es la interfaz de juicio: la superficie a través de la cual un verificador revisa, aprueba, corrige o rechaza lo que hizo el agente. Sus primitivas son el diff, el rollback, el trace, la cadena de atribución, la cola de aprobación. Su disciplina de diseño no es la legibilidad para un modelo, sino la legibilidad para un experto de dominio que opera bajo presión de tiempo. Qué ocurrió. Por qué. Qué cambia si esto se mantiene. Qué se rompe si se revierte. Una interfaz de juicio bien diseñada permite que un experto de dominio confirme con rapidez una salida asistida por IA; una mal diseñada le obliga a rehacer el trabajo manualmente y borra la ganancia de eficiencia que el agente debía aportar.

La mayoría de las empresas, por ahora, está construyendo la primera interfaz con agresividad y la segunda casi nada. La superficie de protocolo recibe roadmap, equipo dedicado y atención a nivel de consejo. La superficie de juicio recibe un panel administrativo adaptado a posteriori, una exportación CSV o, cada vez más, nada, bajo la premisa de que el agente es "good enough" para publicar sin revisión. Todo verificador que hoy trabaja desde un sistema de tickets desmiente esa premisa.

Una previsión refutable: de aquí a finales de 2028, espero que la mayoría de los principales proveedores de software enterprise lancen una interfaz de juicio con nombre propio y de primera clase. La fuerza que lo impondrá será compras, no la teoría de la agencia. A medida que los primeros contratos de la era de los agentes entren en renovación, será difícil responder a la cuestión del burnout de los verificadores sin una superficie dedicada.

El cambio más profundo es más antiguo que cualquiera de estas tecnologías. El marco de 1976 de Jensen y Meckling pasa de los departamentos de economía a los roadmaps de producto. Los costes de monitoreo que modelaron se convierten en partidas presupuestarias de UX. La pérdida residual que nombraron se convierte en una métrica trimestral. La teoría de la agencia, que durante cinco décadas fue el lenguaje del gobierno corporativo, pasa a ser el lenguaje del diseño de software.

Cuando el usuario es un agente, el cliente es un verificador. La distinción no es retórica. Es la forma de la próxima década del software empresarial y del mercado laboral que lo sostiene. Los productos y las carreras que entiendan esto acumularán ventaja. El resto seguirá optimizando para un principal que ya abandonó la pantalla.

Sources