Un asistente sin contexto da consejos que sirven para cualquier empresa, que es lo mismo que decir que no sirven para la tuya. La diferencia entre eso y un agente que responde preguntas concretas de tu operación no está en el modelo ni en el plan que pagas: está en dónde vive tu información y cómo está ordenada.
Este documento explica cómo se arma esa base. No requiere programar, no requiere infraestructura y funciona en cualquier asistente que sepa leer archivos.
Cuatro capas, no una carpeta
Ordenar los archivos es la primera capa y sola no alcanza. Un agente con una carpeta prolija sigue improvisando el criterio, porque nadie se lo escribió.
Las cuatro capas, en el orden en que conviene montarlas:
| Capa | Qué responde | Dónde vive |
|---|---|---|
| Datos | Qué existe y dónde está | La carpeta y su contrato de metadatos |
| Reglas | Cómo se trabaja acá | El archivo raíz y sus apéndices por dominio |
| Procedimientos | Cómo se hace lo que se repite | Un archivo por proceso |
| Ejecutores | Quién lo corre entero sin supervisión | Agentes de tarea fija |
Y dos cosas que cruzan las cuatro: la memoria, que guarda los hechos duraderos que ninguna capa produce sola, y el mapa de fuentes, que declara quién manda sobre cada dato cuando hay más de un sistema en juego.
Cada capa se puede usar sin la siguiente. La primera sirve desde el día uno; la cuarta no se sostiene sin las tres anteriores, porque un agente que corre solo necesita datos donde se prometió, reglas escritas y un procedimiento que seguir.
El contexto vive en archivos, no en la conversación
La forma más común de trabajar con un asistente es contarle todo cada vez. Funciona para una consulta y se cae al segundo mes: la conversación se pierde, el detalle se repite mal, y cada hilo nuevo empieza de cero con una versión distinta de los hechos.
Un archivo de texto plano resuelve las tres cosas. Persiste, lo lee cualquier modelo, lo puede editar una persona sin herramientas y se puede versionar para saber qué cambió y cuándo.
La regla práctica: si un dato lo vas a necesitar dos veces, no lo escribas en el chat, escríbelo en un archivo.
Texto plano en markdown, no documentos de oficina ni planillas: un agente lee markdown sin intermediarios, y tú también.
El archivo que usas es el archivo que compartes
La tentación es tener el proceso de verdad en un lado y una versión ordenada para mostrar en otro. Esa copia se desactualiza en semanas, y a partir de ahí el sistema tiene dos verdades y ninguna confiable.
Cuando el archivo que abre tu agente todos los días es el mismo que le pasas a un socio, a un empleado nuevo o a un cliente, mejorar cómo trabajas y mejorar lo que muestras son la misma acción. No se puede olvidar una.
Un dato tiene un solo dueño
Cada dato se escribe en un lugar y desde ahí se referencia. El identificador tributario del cliente vive en su ficha. Tu propia información fiscal vive en un archivo y solo en uno. El precio de lista vive en el documento de la línea de producto.
Copiar un dato para tenerlo a mano es la forma más rápida de terminar con dos valores distintos y ninguna manera de saber cuál es el bueno. Un agente multiplica el problema, porque puede encontrar los dos y quedarse con uno sin señalar que había otro.
Cuando dos sistemas guardan el mismo dato de verdad, y a veces no hay alternativa, la regla se escribe antes de que ocurra el conflicto: quién manda sobre qué, y dónde está la frontera exacta. Sin esa línea escrita, cada discrepancia se resuelve por conveniencia del momento.
El frontmatter es el contrato
Al inicio de cada archivo va un bloque corto de metadatos: qué es, de quién es, en qué estado está, cuándo se actualizó.
---
type: propuesta
cuenta: cadena-de-restaurantes
status: enviada
monto: 120
moneda: UF
fecha: 2026-08-14
vigencia: 2026-09-13
---
Con eso, un agente puede responder "qué propuestas enviadas llevan más de dos semanas sin respuesta" sin leer el cuerpo de ninguna. Sin eso, tiene que leerlas enteras y adivinar cuáles cuentan.
Dos reglas que lo mantienen vivo: los mismos nombres de campo en todas partes, y un solo lugar donde está escrito qué campos lleva cada tipo de archivo.
Hay un campo que parece decorativo y hace más trabajo que todos los demás:
confirmado. Al lado del decisor y del presupuesto, distingue lo que el
cliente dijo de lo que tú supusiste. Un agente que no tiene esa marca trata
igual "el gerente de operaciones firma" y "creo que firma el gerente de
operaciones", y ahí empieza el pronóstico optimista.
Las reglas no son conocimiento del negocio
En la raíz va un archivo que el agente lee siempre, antes que cualquier otra cosa. Es el equivalente exacto de lo que le explicarías a alguien que entra a trabajar contigo: cómo está organizado esto, dónde va cada cosa, qué reglas no se rompen, cómo se escribe acá, y qué no se hace nunca.
Ahí no va conocimiento del negocio, va la forma de operarlo. El conocimiento cambia con cada cliente; las reglas de la casa casi nunca.
Ese archivo crece rápido y ahí aparece el problema real: si le sumas las reglas
de escritura comercial, las de código, las de la máquina donde corre y las de
tu tono, terminas con un documento larguísimo que se lee entero para responder
cualquier cosa. La solución es un archivo raíz corto que clasifica el pedido y
carga solo el apéndice que corresponde. Cómo se arma está en
reglas.md, y la plantilla lista para copiar en
instrucciones.md.
Los procedimientos se escriben una vez
Todo lo que haces más de tres veces igual es un procedimiento, y mientras vive en tu cabeza se ejecuta distinto cada vez. Escribirlo cuesta una hora y lo convierte en algo que otro puede correr: una persona nueva, o un agente.
Un procedimiento útil declara cuatro cosas: cuándo aplica, qué pasos tiene, qué archivos toca y cómo se verifica que salió bien. La verificación es la que se olvida y la que evita que el agente te reporte un trabajo que no ocurrió.
Encima de todos conviene un índice que diga qué proceso opera cada etapa del trabajo, dónde vive y en qué estado está. Ese índice también sirve para admitir lo que falta: una etapa marcada "a medias" es información, y una etapa que nadie declaró es una que vas a improvisar el día que la necesites.
Qué agrega un MCP, y qué no
Un MCP es la manera estándar de darle a tu asistente acceso a un sistema vivo: el ERP donde se factura, el correo, el calendario, un navegador, una base de datos. Deja de depender de que tú copies y pegues.
Los que uso a diario son tres: el ERP para facturación y cobranza, el correo y el calendario en modo lectura, y un navegador para verificar cosas en sitios reales. Los tres responden preguntas de estado. Ninguno responde preguntas de criterio.
Sirve para lo que cambia solo y tú no controlas: cuánto se facturó el mes pasado, qué reuniones hay esta semana, qué respondió el cliente el martes.
No sirve para lo que te define. El ERP sabe cuánto facturaste y no sabe por qué ganaste ese negocio, qué objeción apareció ni qué prometiste que no estaba en el contrato. Ese criterio vive en tus archivos y no lo tiene ningún sistema comprado.
De ahí sale la frontera, que conviene escribir explícita: el sistema vivo es dueño de sus registros y tú eres dueño del criterio. Un agente con acceso al ERP y sin tus archivos puede improvisar con datos correctos, y eso es más difícil de detectar que improvisar sin datos, porque suena fundamentado.
Empezar por los archivos y agregar accesos después es el orden que funciona. Al revés se termina con un asistente muy conectado que sigue sin entender el negocio.
Los cuatro errores que se repiten
Pedirle al agente que recuerde. La memoria de la herramienta no es tu sistema de registro. Si el dato importa, va a un archivo; si no va a un archivo, asume que se perdió.
Darle todo el contexto siempre. Más texto no es más contexto: es más ruido y más costo. La estructura existe justamente para poder apuntar a lo que hace falta, un archivo o dos, no la carpeta entera.
Documentar el proceso en un lugar y operarlo en otro. El documento que describe cómo trabajas tiene que ser el que usas mientras trabajas. Si son dos, el segundo miente.
Confundir el registro de la conversación con el registro del negocio. Que algo se haya conversado, incluso con mucho detalle, no significa que exista. Existe cuando está escrito donde corresponde.
Por dónde se empieza
No se empieza construyendo el sistema completo. Se empieza por la entidad que más te cuesta hoy, normalmente los clientes: una carpeta por cliente, un archivo con su ficha y su frontmatter, y el archivo de reglas en la raíz.
Con eso ya se puede trabajar con un agente encima. Las capas de arriba se agregan cuando duele no tenerlas: el procedimiento escrito, cuando te cansas de explicar el mismo proceso; el agente de tarea fija, cuando ese procedimiento ya no falla.