# Cómo se le da contexto a un agente

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ó.

```yaml
---
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`](reglas.md), y la plantilla lista para copiar en
[`instrucciones.md`](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.