Agentic-as-a-Service y el retorno del ingeniero

Soy ingeniero desde finales de los noventa.

Empecé en la electrónica, porque era lo que se hacía entonces si querías trabajar en medios audiovisuales. Para ser cámara o técnico de sonido tenías que estudiar antes algo técnico — era la época en que una cámara digital pesaba treinta kilos y la cargabas al hombro como un saco de cemento. De ahí fui derivando hacia los ordenadores: primero arreglándolos y, ya en 2005, montando comercio electrónico, cuando "tener una tienda online" todavía era una idea algo exótica que había que venderle a la gente.

Llegué pronto. Todavía recuerdo la primera vez que mi padre instaló en casa un módem de acceso telefónico y un portátil, en 1996, y me dejó trastear con ellos. Chirriaba, perdía la conexión si alguien descolgaba el teléfono y era, se mire como se mire, un juguete carísimo. Pero me quedé enganchado. Tuve un asiento de primera fila para la llegada de internet, y nunca lo devolví.

En algún momento de mis treinta, todo aquello se convirtió en una habilidad extraña y muy útil: era capaz de ver hacia dónde iba la tecnología. No de forma vaga — de forma concreta, y con margen suficiente para actuar. Mi ventaja, eso que contaba con una cerveza en la mano, era que veía más o menos dos años por delante. Dos años bastaban. Dos años son la diferencia entre construir lo que todo el mundo va a necesitar y construir lo que todo el mundo ya tiene. Ese instinto me acompañó por startups y unas cuantas aventuras emprendedoras, y rara vez me falló.

Entonces los LLMs se popularizaron, y mi horizonte de dos años se desplomó a dos o tres meses.

Quiero ser honesto sobre cómo me sentó: me preocupó. La habilidad en la que me había apoyado discretamente durante década y media dejó de funcionar de la noche a la mañana. No porque la hubiera perdido, sino porque el propio terreno había empezado a moverse más rápido de lo que la intuición de nadie puede seguir. Cuando el estado del arte se reinicia cada trimestre, "dónde estará esto dentro de dos años" deja de ser un pronóstico y pasa a ser un cara o cruz.

El hype por fin se está disipando

Una locura colectiva tiene una cosa: no puede durar para siempre. Y ahora estamos en el punto en que empieza a enfriarse — no la tecnología, sino el ruido a su alrededor. Por fin somos capaces de separar el hype hiperinflado de los medios de los avances reales que hay debajo, y la distancia entre ambos resulta ser enorme.

La señal más clara está en los despidos que se suponía que eran el futuro. Las empresas que no echaron al 40% de su plantilla en un arrebato de optimismo por la IA pueden considerarse ahora, calladamente, entre las afortunadas. Klarna es el ejemplo aleccionador que todo el mundo señala: redujo su plantilla en torno a un 40% y presumía de que su asistente construido con OpenAI hacía "el trabajo de 700 agentes" — y luego, ya en 2025, dio marcha atrás y empezó a recontratar personas después de que la calidad del servicio se desplomara. Su propio CEO lo admitió con todas las letras: "fuimos demasiado lejos".

No es una historia anti-IA. Es una historia anti-hype. Las empresas que trataron el modelo como una varita mágica se quemaron. La pregunta interesante es qué están a punto de construir las que lo tratan como un problema de ingeniería.

Agentic-as-a-Service (no, no voy a escribir el acrónimo…)

Con la irrupción de lo que la gente llama Agentic-as-a-Service — y lo sé, el nombre no es afortunado, que alguien encuentre uno mejor, por favor — por fin empezamos a ver con cierta nitidez los próximos uno o dos años. Y, por una vez, siento que mi viejo horizonte vuelve a enfocarse.

Así que voy a plantear la apuesta sin rodeos: a medida que los sistemas agénticos y los harnesses que envuelven a los LLMs se vuelvan más complejos, veremos una explosión de servicios de software — la misma explosión que vimos con el SaaS — solo que construida sobre una tecnología subyacente distinta. No despidos masivos. Lo contrario: muchísimo trabajo para los ingenieros que dominen el nuevo medio.

Para ver por qué, hay que mirar qué es de verdad un "agente", porque el marketing hace que suene como una personalidad cuando en realidad es una arquitectura.

Un producto SaaS es software determinista que alquilas. Pulsas un botón, pasa siempre lo mismo, y el trabajo del proveedor es mantener el servicio en pie y lanzar funcionalidades. Un servicio agéntico es otra cosa: es un sistema que ejecuta trabajo y entrega un resultado, y el modelo es solo la parte más pequeña y barata. El modelo es el motor. El coche es todo lo demás.

Ese "todo lo demás" — el harness — es donde vive la ingeniería:

• Orquestación y planificación. Las tareas reales no son un único prompt; son bucles. Descomponer el objetivo, dar un paso, observar el resultado, decidir el siguiente paso, recuperarse cuando algo se tuerce. Ese flujo de control es software, y software difícil.
• Herramientas e integración. Un agente que no puede actuar es un chatbot. Darle la capacidad de consultar una base de datos, llamar a una API, abrir un ticket o mover dinero implica construir, asegurar y limitar (rate-limit) cada una de esas superficies de herramientas — y decidir qué tiene permitido tocar.
• Contexto y memoria. Los modelos no tienen memoria entre llamadas. La recuperación de información, la gestión de estado y la memoria a largo plazo son subsistemas enteros que alguien tiene que diseñar para que el agente sepa qué pasó hace cinco minutos — o hace cinco sesiones.
• Verificación y guardrails. Esta es la parte que se saltaron los fracasos tipo Klarna. Un sistema estocástico que acierta el 95% de las veces, en producción, se equivoca una de cada veinte — y esa vigésima vez está hablando con tu cliente o tocando tu contabilidad. Comprobar el trabajo del agente, ponerle límites y saber cuándo escalar a una persona es ingeniería innegociable.
• Evals y observabilidad. No puedes mejorar lo que no puedes medir, y no puedes medir un sistema no determinista con tests tradicionales. Hay que construir alrededor toda una disciplina nueva — frameworks de evaluación (evals), suites de regresión para el comportamiento, trazabilidad de cada decisión.

Fíjate en lo que acaba de pasar. Cada punto de esa lista es más trabajo para los ingenieros, no menos. El modelo convierte en mercancía el 80% fácil; la diferenciación — el foso defensivo — se traslada por completo al sistema que lo envuelve. Y los sistemas los construyen, depuran, monitorizan y operan personas que saben construir sistemas. El no determinismo no saca al ingeniero del bucle. Exige uno mejor, porque ahora el software que ponemos en producción es probabilístico, y razonar sobre sistemas probabilísticos bajo carga es una de las cosas más difíciles que hace nuestra profesión.

Esa es la forma de los próximos dos años, hasta donde vuelvo a verla: no menos empresas de software, sino una nueva generación de ellas — que cobran por resultado y no por usuario, agénticas en lugar de estáticas — y una demanda profunda y sostenida de ingenieros que de verdad entiendan el medio.

Lo que esto no significa

No voy a fingir que la disrupción sale gratis. No es así. Industrias enteras se transformarán, y algunos puestos tendrán que admitir, con honestidad, que han quedado obsoletos y que el mercado los barrerá. El call center tradicional es el ejemplo evidente. Fingir lo contrario no ayuda a nadie, y menos a las personas en esos puestos, que merecen un diagnóstico honesto y una salida viable.

Pero no tengo el menor interés en escribir ni una apología de lo nuevo ni una elegía de lo viejo. Ambas cosas son perezosas. Lo nuevo no es bueno por defecto y lo viejo no era sabio por defecto. Mi trabajo — el trabajo de verdad — es encontrar esos caminos: caminos que pasen por una tecnología mejor, y por la mejora de la sociedad en su conjunto, dentro de mi humilde alcance.

Qué haría este trimestre si fuera tu CTO

1. Elige un flujo de trabajo y construye el harness a su alrededor. No un chatbot — un bucle: descomponer el objetivo, actuar, observar, recuperarse. La capa de orquestación es donde tu equipo aprende lo que el medio exige de verdad, y un solo flujo real enseña más que diez demos.
2. Presupuesta la verificación antes que el modelo. Un sistema que acierta el 95% de las veces se equivoca una de cada veinte en producción. Decide ahora a qué persona escala esa vigésima vez — antes de que esté hablando con tu cliente.
3. Monta los evals desde el primer día. Un sistema probabilístico no se puede someter a tests de regresión tradicionales. Si no estás midiendo el comportamiento, estás ensayando el error de Klarna a tu propia escala.
4. Contrata para el harness, no para el prompt. Cada punto de la lista de arriba es ingeniería de sistemas — construida, depurada y operada por gente que sabe construir sistemas. Ahí vive la diferenciación, así que ahí debería ir la contratación.

Mi horizonte de dos años está volviendo. El panorama desde aquí es más ajetreado, más extraño y más exigente de lo que prometían los mercaderes del hype — y mucho más esperanzador de lo que los agoreros quieren hacerte creer. Hay una cantidad enorme de cosas por construir.

Yo, desde luego, estoy deseando ponerme a ello.

¿Estás construyendo un sistema agéntico y necesitas ingenieros que entiendan el harness, no solo el modelo? Habla con un CTO — te ayudamos a construir el coche alrededor del motor.