Claude Sonnet y el Jarvis Pattern: por qué a los agentes de IA les puede bastar con un sistema operativo

Habr ha publicado un texto que propone simplificar de forma radical el debate sobre los agentes de IA. En lugar de frameworks, grafos, orquestadores y bases de datos vectoriales, el autor plantea una fórmula: LLM + sistema operativo + archivos. Su argumento es que un modelo actual ya es lo bastante potente para usar la terminal, las API y la estructura de archivos casi como lo hace un ingeniero. Por tanto, el cuello de botella no es la cantidad de andamiaje alrededor del agente, sino cómo se diseñan su memoria, sus accesos y su entorno de trabajo.

El autor del concepto, el arquitecto de TI Egor Zinoviev, describe el Jarvis Pattern como un agente personal en red asignado a un especialista concreto. Ese agente no vive en un navegador ni en un portátil, sino en su propio contenedor con acceso a la infraestructura, y actúa en nombre de la persona. Como ejemplo, cita a su agente de DevSecOps umax, basado en Claude Sonnet, que según él cubre el conjunto completo de tareas del área: desde configurar RBAC en Kubernetes y trabajar con Vault hasta desplegar clústeres, escanear imágenes de Docker, configurar CI/CD y analizar vulnerabilidades.

La tesis central es que el agente no necesita un zoo de herramientas preensambladas. Si tiene que consultar Prometheus, usa curl; si debe transformar datos, recurre a jq, sed o awk; y si no existe una utilidad adecuada, la escribe él mismo y la incorpora a su entorno de trabajo.

La memoria recibe un énfasis especial. Para el autor, es la única parte de la arquitectura de agentes que sigue sin resolverse de verdad. Propone dividirla en declarativa, procedimental y episódica: hechos, instrucciones y experiencia. Y no solo importa la experiencia positiva, sino también la negativa: saber qué camino ya llevó a un callejón sin salida y por qué.

En lugar de búsqueda vectorial y modelos de grafos, Zinoviev apuesta por el sistema de archivos y los archivos markdown como mapa natural de rutas: las carpetas definen categorías, los nombres de archivo indican la dirección y un documento índice sirve de punto de partida para sumergirse en el contexto adecuado. En paralelo debe funcionar un Memory Agent independiente que, tras cada sesión, decide qué guardar, qué actualizar y qué descartar.

De este esquema se desprende una visión más amplia del papel del humano. El Jarvis Pattern no trata de una IA totalmente autónoma, sino de potenciar a un ingeniero concreto: la persona plantea la tarea, revisa el resultado y toma decisiones en condiciones de incertidumbre, y el agente se encarga de la ejecución y la rutina. El autor cree que este modelo puede cambiar la contratación, porque se podría evaluar a los candidatos no con preguntas abstractas, sino por cómo trabajan junto al agente en un caso real.

El artículo incluso aporta referencias del mercado empresarial: un ciclo de contratación de 40–60 días, un coste del error de decenas de puntos porcentuales del salario anual y una proporción notable de empleados que no superan el primer año.

Otra conclusión práctica afecta al software: si el agente trabaja mediante API y CLI, los productos sin una API decente empezarán a perder terreno, por muy atractiva que sea su interfaz.

Aunque el texto se presenta como un manifiesto, el autor subraya que no se considera un caso aislado. Como respaldo, remite a ideas similares de otros ingenieros y a productos en los que el agente ya se percibe más como un entorno operativo para el especialista que como un chat con un conjunto de botones.

En ese sentido, el Jarvis Pattern no es un estándar listo ni una nueva plataforma, sino un intento de fijar un cambio: parte de la industria empieza a ver al agente de IA no como una aplicación independiente, sino como una capa de control sobre la infraestructura existente. Si esta lógica cuaja, el debate principal sobre los agentes de IA pasará de la elección del framework al diseño de la memoria, los permisos de acceso y las herramientas API-first. Para los equipos, eso significa menos magia en la arquitectura y más exigencias sobre la calidad del contexto; para los especialistas, un aumento del valor del conocimiento profundo del dominio, que el agente puede escalar pero no sustituir.