8 de julio de 2026
La parte más importante de mi sistema de agentes no son los agentes.
No el modelo. No la orquestación. No la capa de memoria. No las integraciones. No los jobs programados.
Es el montón de archivos de texto plano.
Markdown. YAML. Git. Logs de decisiones. Registros de proyectos. Dashboards generados. Archivos chicos que dicen qué es verdad.
Suena menos impresionante que “trece agentes manejando mi empresa.”
También es la razón por la que los agentes pueden hacer algo útil.
Los agentes necesitan algo donde pararse
Un agente sin contexto es un pasante talentoso en su primer día.
Puede sonar inteligente. Puede hacer preguntas razonables. Puede producir trabajo plausible. Puede improvisar.
No conoce el negocio.
No sabe qué se decidió el mes pasado. No sabe qué proyecto importa más. No sabe qué ideas se mataron. No sabe qué significa “listo”. No sabe qué fuente es canónica. No sabe cuándo un documento se volvió obsoleto. No sabe qué el operador va a lamentar haber automatizado.
A menos que el sistema le dé ese contexto.
El texto plano se vuelve infraestructura acá.
No porque Markdown sea lindo.
No porque YAML sea divertido.
No porque Git esté de moda.
Porque el texto plano crea una capa de verdad operativa durable, inspeccionable y versionada.
La base de datos suele ser el primer movimiento equivocado
Cuando la gente imagina armar un sistema operativo agéntico, empieza con una base de datos.
Tablas. Esquemas. APIs. Vector stores. Dashboards. Paneles de admin. Permisos. Un backend en serio.
A veces hace falta.
A menudo es prematuro.
Los sistemas tempranos cambian demasiado rápido. Las categorías son inestables. Los workflows todavía no se entienden. El operador sigue descubriendo qué debería existir.
Una base de datos hace que la estructura prematura se sienta oficial.
El texto plano sigue siendo negociable.
Un proyecto puede empezar como una entrada YAML. Una tarea como un checklist en Markdown. Una decisión como una nota con fecha. Un reporte semanal como texto generado. Un dashboard reconstruido desde registros. Una skill editada, diffada, revisada, reutilizada.
El sistema se mantiene legible mientras el modelo operativo todavía se está formando.
Empezá con archivos.
Promové a bases de datos cuando la forma se lo ganó.
Cómo se ve esto
Un registro de proyectos no tiene que ser impresionante.
Tiene que ser claro.
projects:
- id: followup-system-acme
name: Sistema de seguimiento para ACME
owner: nico
status: active
priority: high
client_visible: true
next_action: Enviar plan de implementación revisado
next_action_due: 2026-07-10
source_of_truth: /clients/acme/projects/followup-system.md
last_reviewed: 2026-07-08
risks:
- Los campos del CRM siguen inconsistentes
- Las reglas de ownership de WhatsApp necesitan aprobación del cliente
Ese archivo le da al agente algo para inspeccionar.
Puede preguntar qué está vencido. Puede generar una lista de seguimiento. Puede detectar owners faltantes. Puede comparar fechas de última revisión. Puede armar un reporte semanal. Puede avisar que un proyecto marcado alta prioridad no tiene siguiente acción.
El formato es aburrido.
Ese es el punto.
Git es memoria operativa
Git es herramienta de desarrollador hasta que se convierte en memoria operativa.
Responde preguntas que el historial de chat no responde limpiamente:
- ¿Qué cambió?
- ¿Cuándo?
- ¿Quién lo cambió?
- ¿Por qué?
- ¿Qué decía el archivo antes?
- ¿Qué decisión causó esta dirección?
- ¿Ya probamos esto?
- ¿Este plan es nuevo, o un loop viejo con mejor redacción?
Los humanos reabren preguntas ya resueltas cuando están cansados, ansiosos, aburridos o evitando trabajo real.
Un log de decisiones es defensa contra eso.
Cuando cambia el posicionamiento, escribí el razonamiento.
Cuando se mata una oferta, escribí el motivo.
Cuando se congela un workflow, escribí el motivo.
No porque la documentación sea virtuosa.
Porque el vos del futuro no es un testigo confiable.
Un log de decisiones simple puede verse así:
## 2026-07-08 — Congelar proyectos de automatización custom como categoría
Decisión: Dejar de vender proyectos de automatización aislados. Reencuadrar la oferta alrededor de sistemas comerciales.
Razonamiento:
- Los compradores comparan automatización con herramientas e implementación barata.
- El valor real es comportamiento de negocio confiable: seguimiento, enrutamiento, visibilidad, tiempo de respuesta.
- Los módulos reutilizables componen mejor que workflows bespoke.
Alternativas rechazadas:
- Seguir vendiendo workflows de n8n directamente.
- Vender agentes de IA genéricos por canal.
Fecha de revisión: 2026-08-15
Eso no es burocracia.
Es memoria con columna vertebral.
El texto plano hace revisable el trabajo de los agentes
Un prompt escondido dentro de una herramienta SaaS es difícil de gobernar.
Una skill guardada como archivo versionado es distinto.
Podés hacerle diff, revisarla, volver atrás, copiarla, mejorarla, asignarla a otro agente, pedirle a otro modelo que la critique, atarla a una evaluación y ver cuándo cambió.
Esa es la diferencia entre prompting como improvisación y prompting como infraestructura.
Si la competencia de un agente vive solo en un hilo de chat, no compone.
Si vive en archivos, mejora como código.
Me importa el conocimiento operativo como activos versionados, no el prompt engineering como hobby.
Las vistas deberían generarse desde la verdad
Una de las mejores decisiones que tomé fue separar la fuente de verdad de la vista.
La fuente de verdad es texto estructurado.
El dashboard se genera.
La verdad no se edita en el dashboard.
Se muestra ahí.
Los dashboards lindos se convierten en base de datos si los dejás. Cada cambio se vuelve trabajo de UI. Cada campo nuevo, decisión de producto. Cada corrección requiere clicks. El sistema se pone más pesado que el trabajo.
Con registros y vistas generadas, humanos y agentes actualizan archivos estructurados.
Reportes y dashboards se regeneran desde esos archivos.
La interfaz puede cambiar sin destruir la verdad de abajo.
Por qué esto funciona con agentes
Los agentes son buenos con texto.
Obvio, y subutilizado.
Leen Markdown. Actualizan YAML. Resumen logs. Comparan decisiones. Generan reportes. Inspeccionan diffs. Notan contradicciones. Proponen ediciones.
El texto plano tiene una ventaja injusta porque les da a los agentes una superficie simple.
El agente no necesita “usar la app de gestión de proyectos.”
Necesita actualizar projects.yaml según una regla.
Eso es mucho más fácil de confiar.
El texto plano no alcanza
El texto plano no reemplaza todo.
No es ideal para datos transaccionales de alto volumen. No es un sistema de permisos por sí solo. No reemplaza backups. No sirve para ediciones concurrentes sin disciplina. No es donde deberían vivir secretos de clientes sin cuidado. No reemplaza una base de datos real cuando el sistema llega a esa etapa.
“Todo debería ser Markdown” es otra religión.
No necesito una.
El texto plano es un primer sustrato fuerte para conocimiento operativo, especialmente mientras el sistema todavía se está definiendo.
Después, algunas partes deberían graduarse.
Los datos de clientes pueden pertenecer a un CRM.
Los eventos pueden pertenecer a una base de datos.
Los secretos pertenecen a un secrets manager.
Los logs de alto volumen pertenecen a algún lugar buscable.
Pero el modelo operativo debería ser legible antes de convertirse en infraestructura.
El stack aburrido compone
La parte atractiva de los sistemas de agentes es el comportamiento en vivo.
El agente responde. El workflow corre. Llega el reporte. El bot captura la idea. La integración actualiza el registro.
La parte que compone es aburrida.
Un registro más limpio.
Un mejor log de decisiones.
Una skill más precisa.
Un archivo obsoleto borrado.
Un dashboard generado desde verdad en lugar de vibes.
Un reporte semanal que compara el plan con la realidad.
Una regla que impide infraestructura nueva a menos que el trabajo externo lo exija.
No es material de demo.
Es apalancamiento operativo.
Qué construiría primero
Si empezara de nuevo, no arrancaría con una flota de agentes.
Arrancaría con cuatro archivos.
projects.yaml
Cada proyecto activo, owner, estado, prioridad y siguiente acción.
decisions.md
Decisiones con fecha y el razonamiento, no solo la conclusión.
inbox.md
Una superficie de captura para pensamientos crudos, después triageados al sistema o a la basura.
weekly-review.md
Un ritual que compara el plan contra la realidad y decide qué cambia la semana que viene.
Después sumaría un agente.
No trece.
Un agente que lee esos archivos y produce algo externamente útil: una lista de seguimiento, un borrador de propuesta, un reporte operativo semanal, un ensayo publicable, un resumen listo para cliente.
Los archivos crean continuidad.
El agente crea apalancamiento.
Necesitás los dos.
Por qué lo aburrido sobrevive
El texto plano es infraestructura subestimada porque es lo suficientemente aburrido para sobrevivir.
No intenta ser dueño de la empresa. No encierra la verdad dentro de un producto. No necesita roadmap. No se rompe cuando un SaaS cambia precios. No necesita una pestaña nueva. No impresiona a nadie en un demo.
Mantiene el sistema legible.
En una operación agéntica, la legibilidad es lo que evita que la inteligencia se convierta en ruido.
Construyo sistemas operativos alrededor del trabajo real de negocio: archivos, workflows, agentes, integraciones, revisiones y la infraestructura aburrida que mantiene todo legible. Si tu empresa necesita el sistema detrás de la IA, contactame.