Context engineering: el sistema con IA que construí para amplificar mi trabajo
La documentación que ha estado dormida en muchas empresas sin aportar mucho, de pronto es el mayor activo.
FELIPE POLO
CEO Orbitant
Llevo más de diez años en tecnología y los últimos seis meses han sido los más transformadores en cuanto a cómo gestiono mi trabajo. La razón no es que haya empezado a usar IA, sino que he dejado de usarla como una herramienta suelta y he construido un sistema. La distinción que lo hace posible se llama context engineering, y es lo que separa un uso puntual de la IA de algo que mejora con el tiempo.
Si prefieres ver las demos en directo, la sesión completa está disponible en YouTube.
De prompt engineering a context engineering: la distinción que lo cambia todo
La mayoría de la gente usa IA de la misma manera: escribe un prompt, recibe una respuesta y vuelve a empezar, porque cada conversación arranca desde cero y hay que explicar quién eres, en qué contexto estás y qué sabes ya del problema.
Mientras el prompt engineering trabaja sobre la calidad de la pregunta, el context engineering trabaja sobre lo que ya está disponible antes de que esa pregunta llegue. Andrej Karpathy —la persona responsable de la IA en Tesla y uno de los fundadores originales de OpenAI— viralizó esta idea a principios de abril con un argumento concreto: una wiki estructurada es mucho más potente que un sistema RAG porque el uso de la wiki genera un efecto compuesto. Cada output que produces puede realimentarse como input para la siguiente conversación, y lo que acabas construyendo no es una colección de documentos, sino una red de conocimiento que crece.
La documentación deja de ser un arrastre cuando se convierte en contexto activo para la IA. Lo veo en proyectos de clientes: datos almacenados durante veinte años por normativa, sin que nadie los aprovechara, que de pronto se convierten en un activo enorme. Y es lógico porque estructurar ese material antes requería meses de trabajo manual, pero ahora, en cambio, el coste de generar buena documentación tiende a cero porque la IA puede organizar información incluso a partir de notas en bruto. Al mismo tiempo, su valor se dispara porque esa misma documentación se convierte en el contexto que permite a los agentes trabajar de forma eficaz.
La arquitectura que uso para gestionar todo esto tiene tres capas:
- Ficheros en crudo: notas, ideas, transcripciones de reuniones, bookmarks de Twitter, mensajes de Telegram que me mando a mí mismo cuando algo me llama la atención. En este punto no proceso nada, solo capturo.
- Wiki: la IA enriquece, clasifica y conecta esos ficheros, creando notas enlazadas, etiquetas y categorías. Aquí es donde se construye la red.
- Esquema: las reglas de juego. Incluye las categorías que uso, las convenciones de naming, los estados posibles, el tono de referencia… sin esto la wiki se convertiría en un caos.
La herramienta y los cinco agentes que componen el sistema
Para gestionar todo esto uso Obsidian, una aplicación de notas que trabaja directamente sobre ficheros Markdown en local. Funciona sin servidor ni suscripción de pago, y todos los datos son míos. Lo que más me interesa no es su sencillez, sino que permite crear WikiLinks entre ficheros y esas relaciones se traducen en un grafo visual. Cuando la IA tiene acceso a ese grafo, puede tirar del hilo de maneras que yo no habría anticipado: conecta una idea sobre agentes IA con un artículo que marqué hace tres semanas en Twitter y con una reunión del mes pasado.
Los agentes los tengo construidos con Claude Code y distribuidos como plugins en GitHub. Un megaagente que hace todo es un error —el contexto que le das es demasiado difuso y el resultado lo nota—, así que prefiero varios agentes especializados, cada uno con un propósito específico y el mínimo contexto necesario para hacerlo bien.
Los cinco que uso actualmente:
➤ Wiki Manager: el bibliotecario. Ingiere los ficheros en crudo, los enriquece y los mete en la wiki con sus conexiones correctas. Limpia notas huérfanas, sana links rotos, mantiene la red coherente. Lo ejecuto con ingest al arrancar el día y con link al cerrarlo.
➤ Chief of Staff: el operador. Cada mañana, today me crea una nota diaria con el triaje del correo —de varias cuentas en paralelo—, las tareas del día desde Asana y un resumen de dónde estoy respecto a los objetivos estratégicos. Al cierre, close of business procesa todo lo que ha pasado, indexa las reuniones del día y actualiza el mini-CRM que mantengo en la wiki por cada persona con la que interactúo.
➤ Coach: el que más caña me da. Los domingos le pido que me ayude a planificar la semana. Lee el contexto de los últimos siete días, ve mis tareas, mis objetivos y mis huecos en el calendario, y me propone un plan día a día. Los viernes, review me hace una performance review basada en todo lo que he escrito en el diario de esa semana. La nota más alta que he sacado hasta ahora es un 6.
«Llevas quejándote de esto en el diario tres semanas seguidas. Sin embargo, tu tiempo no se está yendo ahí.»
Así me habla el Coach; es difícil rebatirlo.
➤ Content editor: gestiona mi producción de contenido para LinkedIn, newsletter y Twitter. No escribe por mí —el resultado suena enlatado—, pero me propone la parrilla semanal en función de mis analíticas y me da feedback sobre lo que escribo aplicando los principios de los libros de escritura de negocio que le he pasado como contexto.
➤ Thinking Partner: el que me reta. Challenge coge una idea mía y busca en toda mi wiki argumentos para rebatirla. No va a Internet, sino que usa mis propias notas, transcripciones y diarios, que resultan ser la fuente más útil para detectar agujeros en mis argumentos antes de que los defienda en público.
Cómo empezar sin perderte en el camino
Lo que ves aquí es el resultado de seis meses de iteración. No hace falta ese tiempo para llegar a algo útil, pero conviene no intentar montar el sistema completo desde el primer día. Estos serían los pasos que recomendaría:
- Instala Obsidian y Claude Code. Ambos gratuitos. Dentro de Obsidian, crea esta estructura básica de carpetas:
/rawpara notas en crudo,/wikipara notas procesadas,/systemspara las reglas de juego. - Adopta el hábito de la nota diaria. No necesita automatización al principio. Abre una nota, escribe lo que tienes que hacer, lo que has decidido, lo que te preocupa. Eso es el contexto que la IA necesita para empezar a ayudarte de verdad.
- Conéctate a tus herramientas vía MCP. Lo más rápido para ver resultados: conectar correo, Asana y Slack. Hacer preguntas sobre tu propio contexto en tiempo real cambia completamente cómo interactúas con la IA.
- Construye tu primer agente pequeño. Elige una tarea que repites cada semana, descríbesela a Claude Code, itera y versionalo en GitHub.
El principio en el que se basa todo esto vale igual si lideras una empresa que si desarrollas software. Si eres desarrollador, el contexto relevante son las decisiones de arquitectura que tomaste hace seis meses, los tickets que resolviste, los patrones que se repiten entre proyectos. Todo eso, bien organizado y accesible para la IA, multiplica la calidad de lo que produces, no solo el volumen.
Este patrón plantea preguntas interesantes cuando lo trasladas a escala de equipo o de proyecto: qué cambia arquitectónicamente, cuándo tiene sentido frente al contexto nativo del modelo, qué limitaciones aparecen cuando dejas de ser un usuario individual. Son preguntas para otro momento. La que sí tengo respondida es la del principio: cuando el contexto trabaja para ti, cada conversación con la IA empieza desde un nivel más alto que la anterior —eso es el efecto compuesto— y una vez que lo ves, es difícil volver a trabajar de otra manera.
