Tu agente no cobra nómina. Cobra cada vez que:
- vuelve a leer contexto;
- razona sobre una tarea ambigua;
- llama una herramienta;
- pide a otro agente que revise;
- corrige una salida que nadie definió cómo evaluar;
- reintenta porque el loop no sabe cuándo terminó.
Eso cambia la unidad económica. Una llamada barata puede producir un resultado carísimo. Un modelo caro puede ser la opción más barata si termina bien a la primera.
En julio de 2026, George Sivulka publicó en a16z You Just Hired a Million Bad Employees. Su tesis es provocadora: las organizaciones recibieron una fuerza laboral de inteligencia casi ilimitada, pero están repitiendo con ella los mismos defectos de gestión que ya conocían.
No vamos a resumir el artículo como evangelio. Vamos a hacer algo más útil:
- separar sus datos de sus metáforas y proyecciones;
- rescatar las siete analogías que sirven;
- convertirlas en decisiones de arquitectura y operación;
- definir una forma honesta de medir si un agente crea valor.
La tesis en una frase
Escalar inteligencia sin especificar el trabajo escala el desperdicio.
Una empresa no mejora por contratar más personas si nadie define responsabilidades, información, decisiones y resultados. Un sistema de agentes tampoco mejora por multiplicar tokens, subagentes y vueltas.
El paralelismo no significa que un token sea literalmente un empleado. Significa que ambos son capacidad que necesita dirección:
capacidad × dirección × verificación = trabajo aprovechableSi dirección o verificación se acercan a cero, añadir capacidad sólo produce más actividad.
Antes de creer una gráfica: dato, modelo o metáfora
La pieza mezcla tres niveles de evidencia. Son válidos para propósitos distintos, pero no deben confundirse.
| Tipo | Ejemplo en el artículo | Qué permite concluir |
|---|---|---|
| Observación | Gasto empresarial registrado por Ramp; empleo de Revelio Labs | Qué ocurrió en la muestra y el periodo estudiados |
| Modelo o extrapolación | Proyecciones de gasto y comparaciones futuras | Qué ocurriría si se mantienen ciertos supuestos |
| Ilustración | Costos hipotéticos de loops, pirámides y dispersión de evals | Cómo pensar una relación, no cuánto vale universalmente |
| Opinión | “La próxima oportunidad de un billón” | Una tesis estratégica que todavía debe demostrarse |
Esta distinción no debilita el texto. Lo vuelve utilizable.
Lo observado
El Ramp AI Index usa transacciones empresariales para seguir adopción y gasto. Un estudio posterior de Ramp y Revelio Labs enlazó gasto con registros laborales de 21,559 empresas estadounidenses. Encontró que las firmas de mayor intensidad de adopción presentaron aproximadamente 10.2% más headcount tras adoptar y 12% más empleo de entrada; las de baja intensidad no mostraron un cambio estadísticamente significativo.
El propio paper advierte que quienes adoptan mucho ya tienden a ser empresas más grandes, técnicas y de crecimiento rápido. La estimación intenta controlar esa selección comparando con adoptantes posteriores, pero no autoriza la frase “la IA siempre crea empleos”.
Por otro lado, Anthropic analizó cerca de 400,000 sesiones de Claude Code. Encontró una división de trabajo bastante clara: las personas toman la mayoría de decisiones sobre qué construir y el agente toma la mayoría de decisiones sobre cómo ejecutarlo. La experiencia de dominio mejora el éxito y permite obtener más trabajo por instrucción.
Eso respalda una versión sobria de la tesis de Sivulka: el conocimiento del problema sigue siendo un multiplicador.
Lo modelado
La gráfica de gasto por empleado muestra datos observados hasta mayo de 2026 y después prolonga una tasa mensual de crecimiento. La segunda parte es un escenario, no una lectura del futuro.
La proyección sí plantea una buena pregunta operativa:
Si el presupuesto de inteligencia puede crecer más rápido que la nómina, ¿quién administra ese presupuesto y contra qué resultado?
“Tenemos plan ilimitado” no responde. Sólo oculta temporalmente el costo.
Los siete paralelos que vale la pena conservar
Sivulka traduce siete defectos o ventajas de una organización humana a una fuerza laboral de agentes.
La lista funciona mejor si la convertimos en preguntas de ingeniería.
1. Tokenmaxxing: añadir capacidad sin arreglar la tarea
Tokenmaxxing es la apuesta de que más contexto, razonamiento y llamadas producirán por sí mismos una respuesta mejor.
Puede funcionar cuando el problema requiere búsqueda real. Falla cuando el cuello de botella es:
- una intención ambigua;
- un criterio de aceptación inexistente;
- datos contradictorios;
- permisos incorrectos;
- una decisión que sólo puede tomar el negocio;
- una herramienta que no expone el estado necesario.
Un prompt de 20,000 tokens no compensa que nadie sepa qué significa “terminado”.
El paquete mínimo de contexto
Antes de ampliar el presupuesto, prepara cinco piezas:
task:
outcome: "Qué debe existir o cambiar"
acceptance: "Cómo se comprobará"
constraints: "Qué no puede cambiar"
evidence: "Dónde están los datos y ejemplos válidos"
escalation: "Qué ambigüedades requieren una persona"No es una plantilla ceremonial. Cada campo elimina una clase de loops:
outcomeevita optimizar actividad;acceptancecrea una salida;constraintslimita soluciones destructivas;evidencereduce búsqueda ciega;escalationimpide que el agente invente decisiones.
El context engineering valioso no consiste en llenar la ventana, sino en seleccionar lo que cambia una decisión.
2. Loops: reuniones sobre reuniones
Un loop productivo incorpora evidencia nueva y modifica el estado:
propuesta → ejecución → evidencia → decisión → nuevo estadoUn loop improductivo vuelve a formular la misma conjetura:
propuesta → opinión → otra opinión → más tokens → misma incertidumbreLa diferencia no es cuántos agentes participan. Es si aparece un oráculo independiente:
- un test;
- un cambio observable en base de datos;
- una captura del navegador;
- una medición de latencia;
- un contrato validado;
- una decisión explícita de una persona.
El loop necesita límites fuera del modelo
loop:
budget:
max_iterations: 6
max_tokens: 180000
max_cost_usd: 12
deadline_minutes: 35
progress:
signals:
- newly_passing_checks
- reduced_failing_checks
- accepted_artifact_created
max_iterations_without_progress: 2
stop:
repeated_error: 2
permission_denied: true
ambiguous_acceptance: escalateEl número exacto cambia por tarea. La propiedad importante es que el agente no pueda ampliarlo sólo porque “cree que está cerca”.
Nuestra guía de harness engineering explica cómo convertir estos límites, herramientas y señales en entorno de control.
3. Tokens desperdiciados: actividad sin outcome
Contar tokens es necesario para facturación, pero insuficiente para productividad.
Una sesión de 500,000 tokens puede haber resuelto un incidente de alto valor. Una de 5,000 puede haber enviado una respuesta incorrecta a diez mil clientes.
La unidad útil es:
costo por outcome aceptado =
tokens + tools + infraestructura + revisión + corrección
--------------------------------------------------------
outcomes aceptados“Aceptado” requiere evidencia. No basta con que el agente declare éxito.
Mide además:
- tasa de resultados aceptados;
- costo p50, p90 y máximo;
- tiempo humano por outcome;
- loops sin progreso;
- reintentos por la misma causa;
- correcciones posteriores;
- impacto de los fallos, no sólo frecuencia.
El promedio oculta las sesiones runaway. Si nueve tareas cuestan un dólar y una cuesta 700, el p90 y el máximo cuentan la historia operativa.
4. El token 100X: la información que elimina trabajo
La expresión “token 100X” no describe una palabra secreta. Describe información con alto poder de decisión.
Ejemplos:
- “La factura se considera pagada sólo cuando existe conciliación bancaria.”
- “Este endpoint debe conservar compatibilidad con clientes móviles de las dos versiones anteriores.”
- un fixture real que revela la excepción del dominio;
- un error con archivo, línea y remediación;
- un contraejemplo aprobado;
- una lista clara de no-objetivos.
Una sola restricción correcta puede eliminar cien soluciones plausibles pero inválidas.
Por eso la calidad del contexto no se mide en longitud. Se mide en cuánto reduce la incertidumbre relevante:
valor del contexto =
decisiones inválidas eliminadas
-------------------------------
costo de cargarlo y mantenerloLa investigación de Anthropic sobre Claude Code encontró precisamente que la experiencia de dominio permite extraer más trabajo por instrucción. No porque el especialista “promptee bonito”, sino porque aporta decisiones que el modelo no puede deducir del código.
5. Acaparar contexto: el problema político
La organización suele tratar el conocimiento tácito como si sólo faltara documentarlo:
entrevista al experto → extrae su proceso → automatizaPero ese conocimiento puede representar autonomía, identidad, influencia o seguridad laboral. Pedir “entrena a tu reemplazo” y sorprenderse por la resistencia no es gestión del cambio.
Una estrategia menos ingenua:
- Define qué decisión se quiere mejorar, no “capturar todo”.
- Reconoce autoría y responsables.
- Versiona reglas y conserva procedencia.
- Permite disputar o corregir conocimiento.
- Separa observación, política y preferencia.
- Mide si la automatización reduce trabajo indeseado para quien participa.
- Reparte parte del beneficio: tiempo, capacidad, reconocimiento o mejores decisiones.
El contexto empresarial no es sólo un archivo. Es un contrato social y operativo.
También es una superficie de seguridad. No todo lo que una persona sabe debe terminar en la memoria de un agente. Nuestra guía de seguridad para agentes cubre procedencia, mínimo privilegio y memory poisoning.
6. Evals: los nuevos OKRs, pero ejecutables
Sivulka compara las evals con OKRs porque ambas explicitan qué significa un buen resultado.
La analogía es útil hasta cierto punto. Una eval necesita ser más rigurosa:
- se puede ejecutar;
- recibe casos versionados;
- produce evidencia;
- distingue capacidad de regresión;
- corre varios trials;
- detecta atajos;
- registra costo, latencia y trayectoria;
- se calibra contra juicio humano.
Software fue un caso temprano porque ya tenía compiladores, tests, linters, repositorios y CI. “El código corre” no garantiza calidad, pero ofrece una señal más barata que evaluar criterio legal, gusto o estrategia.
Anthropic recomienda empezar con 20–50 tareas reales, graders claros y soluciones de referencia. Nuestra guía práctica de evals añade trials, outcomes, pass@k, pass^k y regresiones.
La idea decisiva es ésta:
No despliegues un agente en una tarea cuyo éxito todavía no sabes reconocer.
Primero puede existir una evaluación humana estructurada. Después algunos criterios se volverán computables. Lo peligroso es automatizar ejecución y dejar completamente subjetiva la aceptación.
7. Transformación: instalar una herramienta no cambia el sistema
La última tesis de Sivulka es empresarial: el gran valor no estaría en vender otro modelo o wrapper, sino en transformar cómo funciona una organización.
No necesitamos aceptar su predicción de mercado para reconocer la diferencia:
Compra de herramienta
- activa licencias;
- da acceso a un chat o agente;
- mide usuarios activos;
- celebra volumen de prompts;
- deja procesos, incentivos y decisiones intactos.
Transformación operativa
- elige un flujo con valor y propietario;
- hace explícita la decisión;
- integra datos y permisos;
- diseña evals;
- cambia responsabilidades;
- observa outcomes;
- captura fallos como mejoras del sistema.
La segunda nunca es “una instalación”. Es aprendizaje continuo. El caso de OpenAI con Codex muestra esa inversión: repositorio legible, herramientas, observabilidad, reglas ejecutables y garbage collection. El modelo fue importante; el entorno convirtió capacidad en throughput.
Entonces, ¿los humanos son más baratos que el software?
La frase del artículo funciona como titular, pero compara unidades que no siempre son equivalentes.
No compares salario por hora con precio por millón de tokens. Compara el costo total de un resultado aceptado.
| Opción | Suele ganar cuando | Costo oculto |
|---|---|---|
| Persona | Hay ambigüedad, negociación, responsabilidad o contexto tácito | Coordinación, espera, onboarding |
| Workflow determinista | Las reglas son estables y expresables | Mantenimiento y casos extremos |
| Agente | El camino varía, pero el outcome puede evaluarse | Tokens, tools, supervisión, varianza y fallos |
| Sistema híbrido | La persona decide y el agente ejecuta dentro de límites | Diseño de handoffs y escalamiento |
El agente no debe ganar porque “parece futurista”. Debe ganar porque mejora al menos una de estas dimensiones sin romper las demás:
- costo por outcome;
- tiempo de ciclo;
- capacidad;
- calidad;
- disponibilidad;
- experiencia de usuario;
- riesgo.
Si una automatización cuesta más, tarda más y exige revisar todo, contrataste actividad, no productividad.
La adopción intensa y el empleo: una señal, no un veredicto
La pieza de a16z afirma que la IA está creando más empleo del que elimina. La investigación de Ramp y Revelio ofrece una señal compatible, pero más estrecha.
El paper reporta:
- crecimiento de headcount cercano a 10.2% en adoptantes intensivos;
- 12% en empleo de entrada;
- expansión en ingeniería, ventas, administración y servicio;
- ausencia de cambio significativo en adoptantes de baja intensidad;
- efectos más claros en empresas de Information;
- adoptantes que ya eran distintos antes de adoptar.
La lectura honesta no es “la IA crea trabajo”. Es:
En esta muestra, gastar poco no cambió gran cosa; integrar intensamente la IA apareció junto con expansión, después de controlar parcialmente diferencias entre empresas.
Eso encaja con la idea de transformación: comprar acceso no produce el mismo resultado que reorganizar un flujo. Aun así, asociación sectorial y empresarial no resuelve el impacto neto sobre ocupaciones, salarios o toda la economía.
Playbook de 30 días: de tokens a outcomes
Semana 1: inventario económico
Escoge un solo flujo y registra:
- volumen mensual;
- tiempo humano;
- esperas;
- errores y retrabajo;
- costo de herramientas;
- consecuencia de un fallo;
- definición actual de terminado.
No empieces con “¿dónde ponemos un agente?”. Empieza con “¿qué outcome queremos mejorar?”.
Semana 2: contrato y eval
Construye entre 20 y 30 casos:
- normales;
- límites;
- negativos;
- incidentes históricos;
- entradas ambiguas;
- acciones que deben escalarse.
Define graders deterministas antes de usar un LLM como juez. Crea una solución o resultado de referencia.
Semana 3: piloto con presupuesto
Ejecuta varios trials con:
- contexto versionado;
- permisos mínimos;
- límite de tokens, costo, tiempo e iteraciones;
- traces de herramientas;
- circuit breaker;
- revisión humana del outcome.
No optimices todavía. Construye baseline.
Semana 4: decisión
Compara persona, workflow y agente:
calidad × confiabilidad × velocidad
-----------------------------------
costo total × riesgoDecide:
- escalar;
- reducir alcance;
- convertir partes en workflow determinista;
- mejorar contexto;
- construir un sensor;
- mantener ejecución humana.
“Necesitamos más datos” también debe terminar en una tarea concreta.
Scorecard mínimo
| Métrica | Pregunta |
|---|---|
| Outcome acceptance rate | ¿Cuántos resultados realmente se aceptan? |
| Cost per accepted outcome | ¿Cuánto cuesta lo que sí sirve? |
| Human minutes per outcome | ¿Se liberó atención o sólo cambió la revisión? |
| No-progress iteration rate | ¿Cuántas vueltas no modifican evidencia? |
| p90 cost and latency | ¿Qué ocurre fuera del caso promedio? |
| Escalation precision | ¿Pide ayuda cuando debe hacerlo? |
| Regression pass rate | ¿Conserva capacidades conocidas? |
| Incident impact | ¿Qué tan caro es equivocarse? |
| Context maintenance cost | ¿Cuánto cuesta mantener vigente la dirección? |
No uses “tokens consumidos” como KPI de adopción. Es equivalente a medir una fábrica por electricidad gastada.
Checklist antes de aumentar presupuesto
- El outcome está definido sin describir una solución específica.
- Existe una forma independiente de reconocer éxito.
- Los casos ambiguos tienen una ruta de escalamiento.
- Cada vuelta del loop incorpora evidencia nueva.
- Hay límite de costo, tiempo, iteraciones y acciones.
- Se mide costo por outcome aceptado, no sólo por llamada.
- p90 y máximo son visibles.
- El contexto tiene propietario, procedencia y versión.
- Las personas que aportan conocimiento participan en el diseño.
- Una eval de regresión protege fallos ya conocidos.
- Seguridad y permisos no dependen del prompt.
- Se comparó contra workflow determinista y ejecución humana.
- Existe una condición explícita para detener el piloto.
La conclusión incómoda
El artículo de Sivulka no demuestra que el 80% de los tokens sea inútil, que toda empresa deba convertirse en Palantir ni que los humanos ya sean universalmente más baratos que el software.
Sí articula una advertencia que merece sobrevivir al titular:
la abundancia de inteligencia no elimina la necesidad de administrar el trabajo. La vuelve más urgente.
La ventaja no será gastar más tokens. Será encontrar la información que elimina cien intentos, construir la eval que distingue éxito de teatro y diseñar el loop que sabe detenerse.
Los modelos escalan capacidad. El sistema operativo de la organización decide si esa capacidad termina en valor o en reuniones hechas de tokens.
Fuentes y lecturas
- George Sivulka / a16z: You Just Hired a Million Bad Employees
- Ramp Economics Lab: A New Look at AI’s Impact on Jobs
- Ramp AI Index
- Anthropic: Agentic Coding and Persistent Returns to Expertise
- Anthropic Economic Index: Cadences
- Anthropic: Demystifying Evals for AI Agents
- OpenAI: Harness Engineering — Leveraging Codex in an Agent-First World