Nota del Editor: Cuando los Agentes de IA evolucionan desde el Prompt puntual y la programación por "vibra" hacia una fase de flujos de trabajo más complejos, la verdadera pregunta importante ya no es "¿puede el modelo completar la tarea?", sino "¿podemos consolidar la capacidad de la IA como un activo de proceso reutilizable y acumulable?".
Este artículo, partiendo del GBrain de Garry Tan, resume las cinco formas centrales a las que gradualmente están convergiendo muchos usuarios de herramientas de Agentes como Codex, Claude Code, Hermes, etc: Habilidades parametrizables, el marco de ejecución ligero Thin Harness, los Resolvers responsables del enrutamiento, la capa de ejecución que separa el juicio del modelo del código determinista, y la Memoria para acumular contexto a largo plazo.
La combinación de estos módulos apunta hacia una nueva "capacidad de proceso": codificar la experiencia en flujos, abstraer las tareas en parámetros, encomendar las reglas estables al código, delegar el juicio y la síntesis al modelo, y continuar acumulando conocimiento a través de la capa de memoria. Comparado con aplicaciones generadas de una sola vez o prompts específicos, este tipo de sistema es más difícil de replicar y es más probable que se convierta en la base para que individuos, pequeños equipos o incluso empresas formen una ventaja competitiva duradera en la era de la IA.
A continuación, el texto original:
He dedicado algún tiempo a investigar el GBrain de Garry Tan. Como alguien sin formación técnica y que no trabaja en el sector de capital riesgo, quería destilar las estructuras genéricas que veo en él y lo que realmente me parece interesante.
Creo que mucha gente está gradualmente convergiendo hacia el mismo conjunto de estructuras centrales. Se pueden resumir aproximadamente en 5 formas, que también representan la dirección natural de evolución en el uso de herramientas de IA de tipo agente como Codex, Claude Code, Hermes, OpenClaw, etc.
Lectura relacionada: "Harness Delgado, Habilidades Gruesas: La Verdadera Fuente de una Productividad de IA 100x"
Skills: Del SOP a la "llamada a método"
Las Skills son el punto de partida más natural para casi todo el mundo. Incluso sin que nadie lo sugiera, los usuarios tienden a construirlas instintivamente porque su forma es muy familiar. Al principio lo entendí como un SOP (Procedimiento Operativo Estándar), es decir, un flujo de trabajo para completar algo. El usuario proporciona "qué hacer", la Skill proporciona "cómo hacerlo".
La comprensión de Tan es que una Skill se parece más a una "llamada a método". En programación, una llamada a método implica invocar un flujo de programa con parámetros. El mismo código se ejecuta cada vez, lo que cambia son los parámetros: qué datos, qué problema, qué objetivo. Por ejemplo, la misma función `process_invoice` puede procesar cada factura en el sistema, no solo aquella para la que se escribió inicialmente.
Una Skill tiene una estructura similar. Una Skill llamada `/investigate` puede contener siete pasos fijos que no cambian. Lo que cambia son los parámetros: TARGET (quién o qué es el objeto de investigación), QUESTION (qué quieres averiguar), DATASET (dónde buscar información). Si la diriges hacia un caso de denunciante en el sector sanitario, actúa como un analista de investigación; si la diriges hacia archivos de declaraciones de la SEC, actúa como un investigador legal. El mismo archivo, los mismos siete pasos, la diferencia la proporciona el mundo exterior.
Esto es diferente a un SOP tradicional. La mayoría de los SOP se escriben para un puesto o tarea específicos, como "procesar cuentas por pagar". Cada escenario de uso corresponde a un flujo. La abstracción de una Skill es mayor: un mismo flujo puede manejar una clase de problemas. Una Skill bien diseñada puede hacer el trabajo de docenas de SOP porque la información del caso concreto se extrae del documento y se transfiere a los parámetros. En el uso práctico, algunas Skills se parecen más a SOP, otras se acercan más a llamadas a método.
Thin Harness: El modelo es la inteligencia, el Harness son las manos
El modelo, como Opus, GPT-5.5, etc., es la inteligencia bruta; el Harness, como Claude Code, Codex CLI, Hermes, OpenClaw, es el marco de ejecución que realmente le da "manos" al modelo. Se encargan de la ejecución en bucle, lectura/escritura de archivos, gestión del contexto, aplicación de restricciones de seguridad. Su código central tiene unas 200 líneas.
Garry menciona que un error común que comete la mayoría es seguir agregando cosas al Harness, yo mismo lo hice. Terminé acumulando 100 definiciones de herramientas y un montón de servidores MCP. El resultado: la ventana de contexto se llenaba con descripciones de herramientas que no eran necesarias para la tarea actual. El modelo empezaba a confundirse sobre qué herramienta usar, la latencia aumentaba, la precisión caía, y finalmente se formaba lo que se llama "corrupción del contexto".
Resolvers: Resolver la corrupción del contexto con una tabla de enrutamiento
La forma de resolver la corrupción del contexto es establecer una tabla de enrutamiento. El Resolver sirve para mapear explícitamente "la tarea de tipo X que acaba de llegar" a "debería invocar la Skill Y". Cuando solo tienes 5 Skills, no necesitas un Resolver; pero cuando tienes 100 Skills, las descripciones se vuelven borrosas y el modelo fácilmente no puede invocar la Skill correcta en el momento correcto. El Resolver reemplaza el emparejamiento de patrones difuso con reglas explícitas.
Tan también ejecuta un mecanismo similar a un Resolver para archivos: una tabla de enrutamiento independiente para decidir en qué ubicación del sistema de archivos debe depositarse la salida de una Skill. Es la misma estructura "auditoría-enrutamiento" aplicada a otro problema. Así, la salida va consistentemente a la carpeta correcta, no a donde el modelo adivina temporalmente.
Skillify es otra idea complementaria suya: es un ciclo de calidad para convertir una Skill puntual en una infraestructura reutilizable a largo plazo. El proceso de 10 pasos que describe Tan incluye: definición del contrato, uso de código determinista donde corresponda, pruebas unitarias, pruebas de integración, evaluación con LLM-as-judge, entrada en el Resolver, script de auditoría, verificación de qué Skills no tienen ruta de invocación y pruebas de humo de extremo a extremo. El criterio de prueba es simple: si tienes que hacerle la misma pregunta al modelo dos veces, es un fracaso.
Latente vs. Determinista: El juicio al modelo, las tareas deterministas al código
Es importante distinguir seriamente qué trabajo debe encomendarse al LLM y cuál a sistemas deterministas. Los LLM son buenos para el juicio, la síntesis, el reconocimiento de patrones y leer entre líneas; pero no son buenos en aritmética, optimización combinatoria, ni son adecuados para cualquier tarea que requiera dar la misma respuesta cada vez. Los LLM son esencialmente probabilísticos; cuando una solución determinista puede resolver el problema, no debería usarse un LLM.
La mayoría de las personas sin formación técnica tienden a subestimar el valor de la capa determinista. La reacción por defecto es arrojar todo al modelo. Pero si algo puede hacerse de manera determinista, casi siempre se debería hacer así. Y no necesitas ser programador, porque el modelo puede escribir el código por ti. Lo que realmente se necesita entrenar es una disciplina: preguntarse cada vez, ¿puede esto hacerse de manera estable y a bajo costo con código? Si la respuesta es sí, haz que el modelo escriba ese código.
Memory: Hacer que el sistema sea realmente acumulativo
Para que el sistema sea útil, debe tener algún tipo de memoria. Todavía no estoy seguro de cuál es la forma más correcta, mucha gente la está construyendo de diferentes maneras: embeddings vectoriales, similitud semántica, grafos de conocimiento, almacenamiento híbrido, etc. El enfoque de Tan es el mismo que el mío: una carpeta de markdown.
Su estructura es: una página por persona, una por empresa, una por concepto. En la parte superior de cada página está la "conclusión actual creíble", es decir, el juicio sintetizado que se reescribe y actualiza continuamente con nueva evidencia; en la parte inferior hay una línea de tiempo solo de adición, sin sobrescritura.
Elegir markdown tiene varias consecuencias. Primero, el archivo en sí es el registro principal del sistema, no una exportación. Puedes abrirlo en VS Code, editarlo manualmente, y el Agente leerá automáticamente esos cambios. Segundo, las relaciones tipadas, como works_at, invested_in, founded, attended, advises, se extraen automáticamente mediante expresiones regulares cada vez que se escribe, por lo que el grafo de conocimiento se puede conectar sin consumir tokens. Este esquema concreto es adecuado para su trabajo, pero otros pueden necesitar personalizarlo según su profesión o escenario empresarial.
Además, hay un detector de señales ejecutándose en segundo plano. Si se menciona a una persona una vez, se genera una página provisional (stub); si se la menciona tres veces en múltiples fuentes, se activa una completación de información web; después de una reunión, se ejecuta el flujo completo. El "ciclo de sueño" nocturno escanea conversaciones, completa información de entidades desactualizadas y repara referencias rotas. La capa base es texto; todo lo que se construye sobre ella es barato y componible.
Por supuesto, hay más detalles en el nivel subyacente, pero creo que estos son los contornos más importantes y, en gran medida, son universales.
Yo mismo ya he construido aproximadamente la mitad de esta arquitectura. Antes no había alcanzado la escala que requería un Resolver propiamente dicho, pero ahora sí, así que acabo de hacer una pequeña refactorización para hacer mi sistema agnóstico al modelo e incorporar un Resolver. La parte clave que aún no he construido son el detector de señales en segundo plano y el ciclo de sueño nocturno, es decir, el mecanismo de completado y organización automática de información, que es lo que quiero intentar añadir a continuación.
Sospecho que la convergencia de diferentes constructores hacia estructuras similares es en sí misma una señal: aunque esta forma puede no ser aplicable a todos, es probable que sea útil en términos generales. Incluso si los detalles de implementación específicos tendrán diferencias importantes, esta estructura general está siendo descubierta de forma independiente por cada vez más personas.
Últimamente me he estado preguntando: ¿cómo puedo usar la IA para construir una ventaja competitiva sostenible?
Todo el mundo se entusiasma con las aplicaciones vibe-coded y los prompts de una sola vez, lo cual es genial. Yo mismo empecé así y me enganché. Pero cualquier cosa que pueda construirse con un prompt de una sola vez, su precio de equilibrio eventualmente caerá al coste de los tokens requeridos para construirlo, es decir, unos pocos céntimos.
Por ejemplo, alguien que clona MyFitnessPal, lo vende a la mitad de precio y gana un millón de dólares, es impresionante. Pero pronto alguien más lo clonará y lo venderá a un precio aún más bajo. Este ciclo continuará hasta que el margen de beneficio se comprima por completo.
Lo verdaderamente sostenible es algún tipo de "capacidad de proceso". Usando el marco de Hamilton Helmer en "7 Powers", la arquitectura descrita implica precisamente el process power.
"7 Powers" propone que las empresas pueden mantener rentabilidades superiores a la media del mercado a largo plazo porque poseen una de siete fuerzas estructurales. Cualquier ventaja no arraigada en estas fuerzas será finalmente erosionada por la competencia.
Para pequeñas y medianas empresas y compañías en etapas tempranas, cinco de las siete fuerzas de Helmer están básicamente cerradas. Las economías de escala requieren escala; los efectos de red y los costes de cambio se pueden construir, pero requieren primero una base de usuarios masiva; los recursos exclusivos suelen significar patentes o activos similares, que no están al alcance de la mayoría; la construcción de una marca suele llevar una década, no hay atajos.
Las dos restantes son el contra-posicionamiento y la capacidad de proceso.
El contra-posicionamiento se refiere a un modelo de negocio que los gigantes existentes no pueden imitar porque, si lo hicieran, dañarían su propio negocio establecido. Esta oportunidad existe a veces, pero no siempre está disponible.
Por lo tanto, el camino más realista que queda es la capacidad de proceso. Y un sistema de IA bien diseñado es precisamente la herramienta que puede generar capacidad de proceso.
Esto es esencialmente el mismo trabajo que establecer SOPs de alta calidad o desarrollar software propietario interno: el proceso se codifica, los casos se parametrizan, el sistema determinista subyacente es rápido y confiable, y la capa de memoria absorbe continuamente lo aprendido. Amplifica aún más la "productización de servicios": puedes ofrecer un servicio o producto a menor coste o mayor calidad porque todo el trabajo ha sido estructurado.
Imagina a una contadora que construye un sistema así. La capa de memoria es una carpeta donde cada cliente tiene un archivo markdown con la conclusión actual creíble, como la estructura de la entidad, la postura fiscal anual, las auditorías en curso, y una línea de tiempo con reuniones, decisiones y cambios.
Ella tiene algunas Skills, como /year-end-review, /quarterly-estimate, /audit-prep. El mismo flujo puede ejecutarse parametrizado para diferentes clientes.
Tiene una capa determinista con formularios fiscales, tablas de depreciación, documentos del IRS, declaraciones históricas de los clientes, etc.
Suma un mecanismo similar al de la organización de registros o al ciclo de sueño. Por ejemplo, el sistema detecta automáticamente por la noche que la asignación del K-1 de un socio bajó un 40% sin cambios estratégicos; o nota que la estructura de deducción de la oficina en casa de un cliente podría migrarse a otro, reutilizando la estructura pero manteniendo la identidad y privacidad en su lugar.
Así, ella puede cobrar una pequeña prima, atender a más clientes al año, y a la competencia le resulta difícil replicarlo porque esta estructura no aparece de la nada una vez que tiene éxito, sino que se ha ido acumulando desde el principio.
Superficialmente, esta herramienta es solo una carpeta de markdown. Pero cada línea dentro de cada archivo proviene de una gran cantidad de pruebas, construcción e iteración consciente. Lo que realmente forma la barrera competitiva no son los archivos en sí, sino la capacidad de proceso que estos archivos portan.
