Cómo crear agentes de IA que construyen y publican software: la arquitectura de Jobbit

La mayoría de los "agentes de IA" se quedan en la conversación. Responden, y luego un humano hace el trabajo. El problema de ingeniería interesante —y genuinamente difícil— es construir agentes que hagan el trabajo: que escriban una aplicación full-stack, la ejecuten, corrijan sus propios errores y la desplieguen en producción. Ese es el problema en el que el equipo de ingeniería de Jobbit y su división de I+D, Jobbit Labs (jobbitlabs.com), trabaja cada día.

Este artículo es un análisis técnico de los patrones que hay detrás de los agentes de IA que construyen y publican software: la arquitectura, los modos de fallo y las lecciones aprendidas. Es deliberadamente práctico e independiente del proveedor: tanto si construyes sobre LLMs, orquestación multiagente, llamadas a herramientas (tool calling) o RAG, estos principios son transferibles.

Los chatbots responden; los agentes actúan

El salto de un chatbot a un agente es el salto de generar texto a realizar acciones en el mundo. Un agente tiene que planificar una tarea de varios pasos, llamar a herramientas, leer los resultados y decidir qué hacer a continuación, y luego repetir hasta cumplir el objetivo. Ese ciclo, a menudo llamado el bucle agéntico (agentic loop, o ciclo de razonamiento-acción), es el corazón del sistema.

El reto de ingeniería es que cada paso puede fallar. El modelo puede alucinar una función que no existe, escribir código que no compila, malinterpretar la salida de una herramienta o desviarse silenciosamente de la tarea. Un chatbot que se equivoca produce una frase incorrecta; un agente que se equivoca produce un despliegue roto. La fiabilidad, y no la capacidad bruta, es el verdadero trabajo de ingeniería.

La arquitectura: planificador, ejecutor, herramientas

Una plataforma de agentes robusta separa la planificación de la ejecución. Una capa de planificación descompone un objetivo ("crear una app de reservas con pagos") en pasos concretos; una capa de ejecución lleva a cabo cada paso usando herramientas. Mantener estas responsabilidades separadas hace que el sistema sea depurable: puedes inspeccionar el plan de forma independiente a cómo se ejecutó cada paso.

El uso de herramientas (tool use) es donde el agente consigue sus manos. Las herramientas son funciones bien definidas que el modelo puede invocar: leer un archivo, escribir código, ejecutar una compilación, consultar una base de datos, desplegar. La disciplina de ingeniería aquí es el diseño de interfaces: cada herramienta necesita un esquema ajustado e inequívoco, entradas validadas y salidas estructuradas que el modelo pueda interpretar de forma fiable. Las interfaces de herramientas poco definidas son una de las principales fuentes de fallos en los agentes; las bien definidas son la victoria más barata en fiabilidad que existe.

Para trabajos complejos, un único agente a menudo da paso a la orquestación multiagente: agentes especializados que planifican, escriben código, revisan y verifican, coordinados por un orquestador. La descomposición te aporta foco (cada agente tiene una tarea acotada y un contexto acotado) y paralelismo (las subtareas independientes se ejecutan de forma concurrente). El contrapunto es la sobrecarga de coordinación, así que la capa de orquestación tiene que ser determinista donde pueda serlo y resiliente donde no.

Ejecutar y desplegar código real, de forma segura

Un agente que escribe software tiene que ejecutar ese software, y ejecutar código generado por un modelo es un problema de seguridad antes que cualquier otra cosa. La respuesta es la ejecución de código en sandbox: el código no confiable se ejecuta en un entorno aislado con recursos limitados, sin acceso a secretos y con fronteras de red estrictas. El sandbox es lo que permite a un agente iterar —compilar, probar, leer el error, corregir— sin poner en riesgo la plataforma ni a otros usuarios.

El despliegue es el paso que convierte una app generada en un producto. Un verdadero constructor de apps con IA (AI app builder) se hace cargo del camino desde el código hasta una URL en vivo: compilar, aprovisionar el hosting, asociar un dominio, terminar el TLS. Hacer esto bien significa lograr que los despliegues sean repetibles y reversibles: las mismas entradas producen el mismo resultado, y un mal despliegue puede revertirse. La idempotencia y un rollback limpio no son glamurosos, pero son lo que hace confiable el despliegue autónomo.

Contexto, memoria y recuperación

Los LLMs tienen un contexto finito, y los proyectos reales no caben en él. Por eso un sistema de agentes serio invierte mucho en ingeniería de contexto (context engineering): decidir qué ve el modelo en cada paso. Meter todo en el prompt es a la vez caro y contraproducente: demasiado contexto irrelevante degrada el razonamiento.

Aquí es donde el RAG (generación aumentada por recuperación) y las bases de datos vectoriales se ganan su lugar. En vez de volcar todo un repositorio de código en el contexto, el sistema recupera los pocos archivos, símbolos o documentos relevantes para el paso actual. Combinada con una memoria estructurada —un registro de decisiones, la especificación en evolución y lo que ya se ha intentado—, la recuperación mantiene al agente anclado a lo largo de una tarea larga sin reventar la ventana de contexto. Una buena recuperación suele ser una palanca de calidad mayor que un modelo más grande.

Fiabilidad: evals, verificación y guardarraíles

Si hay una idea que separa la ingeniería de agentes en producción de las demos, es esta: no puedes publicar lo que no puedes medir. Los sistemas agénticos son estocásticos, así que la fiabilidad se construye mediante evals: conjuntos de pruebas automatizadas que puntúan al agente en tareas representativas y detectan regresiones antes de que las descubran los usuarios. Un cambio que "se siente mejor" pero hunde tus puntuaciones de eval es un cambio que no publicas.

Por encima de los evals están los guardarraíles en tiempo de ejecución y la verificación. El patrón más eficaz es la autoverificación adversarial: después de que un agente produce un resultado —un fragmento de código, un plan, una corrección—, un paso de verificación separado intenta refutarlo. ¿Compila el código? ¿Pasan las pruebas? ¿La salida coincide con el esquema? Tratar la verificación como un paso distinto y escéptico atrapa una gran parte de los fallos que una única pasada confiada pasaría por alto. Los reintentos con backoff, los circuit breakers y la escalada a un humano se encargan del resto.

Observabilidad que puedes depurar

Cuando un sistema autónomo toma docenas de decisiones por tarea, necesitas poder verlas. La observabilidad —trazado estructurado de cada prompt, llamada a herramienta y resultado— no es negociable. Cuando un agente falla, la traza es cómo encuentras el paso exacto que se desvió, lo reproduces y corriges la causa raíz. Los equipos de ingeniería que tratan las trazas de los agentes como telemetría de primera clase depuran en minutos; los que no, depuran en días.

El edge y la escala elástica

Las cargas de trabajo de los agentes son irregulares (en ráfagas) y sensibles a la latencia, lo que hace que el edge computing encaje de forma natural. Ejecutar cerca de los usuarios —en plataformas como Cloudflare Workers y almacenes de datos en el edge— reduce la latencia de ida y vuelta y escala de forma elástica con la demanda. Jobbit Labs se apoya en este enfoque edge-first para partes de su infraestructura de datos y de producto: distribuida globalmente, con autoescalado y de pago por uso, de modo que la capacidad sigue a la carga en lugar de quedarse inactiva.

La capa de humano en el bucle

La pieza final de la arquitectura es la que le falta a la mayoría de las plataformas de agentes: una ruta de humano en el bucle (human-in-the-loop). La IA gestiona el volumen y la velocidad, pero algunas decisiones —lógica sensible a la seguridad, redacción legal, criterio de diseño— corresponden a una persona. Diseñar esto significa construir puntos de entrega limpios donde un experto humano verificado pueda intervenir, con un sistema de escrow que protege la transacción. El agente y la red de humanos no son capas que compiten; son un mecanismo de respaldo diseñado a propósito que hace que sea seguro confiar en todo el sistema.

Lecciones para ingenieros que construyen agentes

Si estás construyendo sistemas agénticos, unos cuantos principios devuelven la inversión muchas veces.

Diseña interfaces de herramientas ajustadas. La mayoría de los fallos de los agentes se remontan a herramientas ambiguas. Los esquemas estrictos y la E/S validada son la fiabilidad más barata que comprarás jamás.

Verifica de forma adversarial. No confíes en una primera pasada segura de sí misma. Añade un paso separado cuyo trabajo sea refutar el resultado.

Mide con evals. Construye el arnés de evals antes de escalar el agente. No puedes mejorar lo que no puedes puntuar.

Diseña el contexto, no lo vuelques. Recupera lo que es relevante; recuerda lo que importa. Prompts más grandes no son prompts mejores.

Aísla en sandbox todo lo no confiable. Si un agente ejecuta código, el aislamiento es una condición previa, no una funcionalidad.

Mantén una ruta humana. El sistema autónomo más seguro es el que sabe cuándo preguntar a una persona.

Preguntas frecuentes

¿Qué diferencia a un agente de IA de un chatbot?

Un chatbot genera texto; un agente de IA planifica y realiza acciones: llama a herramientas, ejecuta código e itera hacia un objetivo. La dificultad de ingeniería está en la fiabilidad a lo largo de muchos pasos, donde cualquier error individual puede arruinar el resultado.

¿Cómo se ejecuta de forma segura el código generado por IA?

Con ejecución de código en sandbox: el código no confiable se ejecuta en un entorno aislado con recursos limitados, sin acceso a secretos y con red restringida, de modo que el agente puede compilar, probar y corregir sin riesgo para la plataforma.

¿Por qué son tan importantes los evals para los sistemas de agentes?

Porque los agentes son estocásticos, necesitas evals automatizados para medir la calidad en tareas representativas y detectar regresiones antes de publicar. Sin ellos, las "mejoras" son conjeturas.

¿Qué hace Jobbit Labs?

Jobbit Labs (jobbitlabs.com) es la división de I+D y datos detrás de Jobbit, centrada en la ingeniería más pesada, intensiva en datos y de nivel empresarial: investigación, plataformas de datos y los cimientos de agentes sobre los que se construye el producto.

¿Te intriga la ingeniería que hay detrás de los agentes que publican software? Explora jobbit.uk y jobbitlabs.com.