De mediados de abril a mediados de junio apenas toqué las funcionalidades del producto.
Estaba construyendo OwlMeans, un pipeline de desarrollo que convierte historias de usuario en software. Mientras tanto, el trabajo que lo rodeaba andaba disperso: la estrategia, las notas de marca, la investigación y los textos del sitio web, cada cosa en un lugar distinto.
Cada vez que le pedía ayuda a un agente, le volvía a explicar la empresa.
Dediqué dos meses a cambiar eso. Construí el espacio de trabajo que hoy uso para el conocimiento de la empresa y para las tareas recurrentes.
El problema aparecía en las tareas de todos los días.
Un artículo necesitaba el posicionamiento actual; un cambio en la web, lo que el producto hacía de verdad; una investigación, la pregunta del cliente que intentábamos responder.
Siempre hacían falta los mismos datos, pero yo seguía aportándolos a mano. A veces se me olvidaba un matiz. Otras, un borrador usaba un mensaje que correspondía a una versión anterior de la empresa.
Un agente capaz sabía trabajar con el material que yo le daba. Lo que no le había dado era un lugar fiable donde encontrarlo.
Esa diferencia importaba. Podía mejorar el prompt de cada tarea o hacer que el conocimiento con el que trabajaba la empresa fuera más fácil de encontrar y de actualizar. Elegí lo segundo.
El registro compartido
Monté la wiki de la empresa en Markdown.
Contiene la estrategia, lo que sabemos de los clientes, las reglas de marca y la documentación del producto. Los índices de las carpetas le indican al agente dónde buscar. Cada página trata un tema concreto, y un hallazgo nuevo va junto al conocimiento que modifica.
Suena a archivar papeles. En buena parte, lo es.
La investigación y la ejecución pueden apoyarse en el mismo registro. Cuando un artículo necesita un dato del producto, el agente tiene dónde comprobarlo. Cuando un cambio en la web deja al descubierto un dato desactualizado, la wiki tiene un sitio para la corrección.
Aun así, el registro necesita criterio. Una creencia sobre el mercado que nadie ha puesto a prueba no se vuelve cierta porque un agente la haya guardado en una carpeta bien ordenada. Las hipótesis abiertas las mantenemos separadas del conocimiento consolidado.
La siguiente capa fueron las habilidades.
Puse por escrito los flujos de trabajo que repetía: investigar, preparar artículos, sincronizar el sitio web y mantener la documentación del producto. Cada habilidad describe la tarea y las reglas locales que es fácil pasar por alto.
Así, una corrección puede mejorar la siguiente ejecución. Pero hay que trasladarla a las pautas que correspondan: el modelo no se aprende la empresa para siempre porque yo lo haya corregido en el chat.
Una habilidad puede quedarse obsoleta, igual que un documento. Alguien tiene que comprobar que su procedimiento sigue encajando con las herramientas y con el trabajo.
La especificación de Agent Skills aporta el formato común de carpetas y metadatos. Las instrucciones que van dentro de nuestras habilidades las seguimos escribiendo y manteniendo nosotros.
El código junto a la empresa
También vinculé nuestros repositorios al espacio de trabajo.
A la hora de escribir, eso se notó en la práctica. Un artículo sobre una nueva versión podía partir de la implementación y no del recuerdo de lo que queríamos lanzar. La documentación técnica podía distinguir el código que ya estaba en un commit de una idea apuntada en la hoja de ruta.
La conexión no borra la diferencia entre esas fuentes. Un documento de diseño describe una intención. Un commit muestra una implementación. Ninguno de los dos demuestra que un flujo de trabajo concreto de un cliente se haya ejecutado con éxito.
Para una empresa que vende un pipeline de desarrollo con IA, mantener visibles esas diferencias forma parte del trabajo.
El flujo de trabajo de los artículos le dio a esta estructura un uso inmediato.
Podía dictar el tema y dejar que el agente consultara la wiki y fuentes externas, preparara un borrador y lo pasara por la revisión de redacción. Las imágenes y las versiones para redes sociales eran pasos aparte. Solo se publicaba cuando yo lo pedía.
Los datos ya no tenían que viajar desde mi memoria hasta cada prompt.
Esa misma estructura ayudaba con el trabajo en la web. La página pública y la explicación interna se podían cuadrar mientras las dos estaban a mano.
La empresa no pasó a funcionar sin mí. Seguía siendo yo quien elegía qué publicar, comprobaba las afirmaciones y decidía qué trabajo merecía atención.
Esta experiencia también orienta lo que hacemos en Servicios. Además de escribir el software, importa definir el flujo de trabajo y preparar el traspaso. Para eso hace falta un alcance concreto del proyecto del cliente, no la promesa de que un agente va a llevar el negocio.
Los archivos de memoria
La versión de junio de este artículo describía los archivos de contexto que yo usaba entonces. Esa configuración ya no es la misma.
En octubre, nuestras pautas compartidas ya estaban en AGENTS.md y en un directorio común de habilidades, con un pequeño puente CLAUDE.md donde hacía falta. Las copias de instrucciones específicas de cada agente habían dejado de ser el modelo a seguir.
La documentación actual de Claude Code sobre la memoria distingue entre las instrucciones del proyecto y la memoria automática. Por eso ya no procede aquella afirmación tajante de que la herramienta no tiene memoria persistente.
El registro de la empresa cumple otra función. Recoge lo que OwlMeans tiene decidido, qué pruebas respaldan una afirmación sobre el producto y qué flujo de trabajo corresponde a la tarea. Necesito que ese registro se pueda seguir revisando desde cualquier herramienta.
El artículo sobre cómo reorganizamos las pautas de los agentes describe con más detalle la estructura posterior de los repositorios.
Lo que costó
Dos meses son mucho desvío para un fundador en solitario.
El espacio de trabajo hizo que las tareas repetidas fueran más fáciles de retomar, pero crearlo retrasó funcionalidades del producto. También trajo una obligación permanente: las instrucciones y el conocimiento tienen que mantenerse al día.
Volvería a hacer la misma inversión, porque uso esa estructura en mi trabajo. Eso sí, la próxima vez empezaría por algo más pequeño. Un registro fiable para unas pocas tareas recurrentes ya es útil antes de convertirse en un sistema para toda la empresa.
Revisado el 15 de octubre de 2026. El desvío de abril a junio no cambia; lo que se cuenta más arriba sobre la estructura de los repositorios y sobre la memoria distingue la configuración original de la actual.