8 de julio de 2026
Antes de armar una flota de agentes, armá cuatro archivos.
No un dashboard.
No una base vectorial.
No una capa de orquestación.
No trece agentes con nombres, roles, fotos de perfil y trabajo real que hacer.
Cuatro archivos.
projects.yamldecisions.mdinbox.mdweekly-review.md
Eso alcanza para crear la primera capa de verdad operativa.
No va a impresionar a nadie en un demo.
Va a hacer mucho más útil al primer agente.
Por qué archivos primero
Los agentes necesitan contexto.
Pero “contexto” no es un montón de documentos al azar o memoria infinita.
Contexto es verdad actual organizada de una forma que el sistema pueda usar.
La mayoría de los negocios no tiene esto. Tienen historial de chat, docs viejos, herramientas desconectadas, planillas viejas, memoria personal y decisiones enterradas en reuniones.
Después suman un agente y esperan que opere.
El agente hace lo que hacen los agentes en esa situación: suena útil y adivina de más.
Los archivos obligan al operador a definir lo básico.
¿Qué proyectos existen?
¿Qué se decidió?
¿Qué está esperando triage?
¿Qué cambió esta semana?
Si esas cuatro preguntas no están claras, un sistema más grande no te va a salvar.
Solo va a esconder la confusión detrás de más infraestructura.
Archivo 1: projects.yaml
El registro de proyectos responde una pregunta:
¿Qué trabajo está vivo ahora mismo?
Una versión simple:
projects:
- id: client-followup-system
name: Sistema de seguimiento para cliente
type: client_delivery
owner: nico
status: active
priority: high
next_action: Enviar plan de implementación
next_action_due: 2026-07-10
last_reviewed: 2026-07-08
source_of_truth: clients/acme/followup-system.md
notes:
- Las etapas del CRM necesitan limpieza antes de automatizar
- Reglas de aprobación de WhatsApp todavía pendientes
Este archivo debería ser aburrido y estricto.
Todo proyecto activo necesita:
- ID;
- nombre;
- tipo;
- dueño;
- estado;
- prioridad;
- próxima acción;
- fecha límite si aplica;
- fecha de última revisión;
- source of truth.
El registro de proyectos no es para brainstorming.
Es para trabajo que está vivo.
Si un proyecto no tiene próxima acción, no está activo. Es un deseo con metadata.
Qué puede hacer un agente con esto
Un agente puede:
- listar proyectos sin próxima acción;
- marcar trabajo vencido;
- preparar una revisión semanal de prioridades;
- identificar proyectos estancados;
- generar una lista de seguimiento;
- comparar prioridad del proyecto contra el tiempo del calendario;
- avisar cuando trabajo de alta prioridad no se movió.
Eso es útil porque el archivo es explícito.
Archivo 2: decisions.md
El log de decisiones responde:
¿Qué ya decidimos, y por qué?
La mayoría de los operadores subestima cuánta energía desperdicia reabriendo decisiones.
Posicionamiento. Precios. Ofertas. Herramientas. Procesos. Clientes objetivo. Hiring. Features. Qué automatizar. Qué no automatizar.
Un log de decisiones te protege de tu propio humor.
Plantilla:
## 2026-07-08 — Reencuadrar la oferta de automatización como sistemas de negocio
Decisión:
Dejar de vender proyectos de automatización aislados. Vender sistemas de negocio atados a resultados operativos.
Contexto:
Los compradores comparan automatización con herramientas baratas y horas de implementación. El valor real es comportamiento de negocio confiable: seguimiento, routing, reportes, flujo de documentos, tiempo de respuesta.
Alternativas consideradas:
- Seguir vendiendo workflows de n8n directamente.
- Vender chatbots de IA por canal.
- Productizar un SaaS inmediatamente.
Razonamiento:
Los sistemas reutilizables se componen. Los workflows custom crean fragilidad de delivery. El encuadre por resultado es más claro para los compradores.
Fecha de revisión:
2026-08-15
El razonamiento importa más que la conclusión.
Una conclusión sin razonamiento es solo una nota.
Una decisión con razonamiento es memoria operativa.
Qué puede hacer un agente con esto
Un agente puede:
- chequear si trabajo nuevo contradice decisiones anteriores;
- resumir por qué se eligió una dirección;
- preparar una revisión de estrategia;
- identificar decisiones que tocan revisión;
- evitar que el operador trate debates viejos como insights nuevos;
- explicar contexto a otro agente o colaborador.
Eso no es sobre-documentación.
Es apalancamiento.
Archivo 3: inbox.md
El inbox responde:
¿Dónde caen los pensamientos crudos antes de convertirse en trabajo?
Un error común es intentar organizar ideas en el momento de capturar.
Eso hace la captura pesada.
La captura pesada muere.
El inbox debería ser rápido, desordenado y temporal.
Ejemplo:
# Inbox
## 2026-07-08
- Escribir ensayo comparando mala automatización vs buenos sistemas.
- Hacer seguimiento con ACME sobre limpieza de campos del CRM.
- Plantilla potencial: cuatro archivos para operación agéntica.
- Chequear si la revisión semanal es demasiado larga.
- Idea: screenshot del briefing matutino de OWL para ensayo flagship.
Sin categorías. Sin tags complejos. Sin productividad falsa.
Solo captura.
Después triage en un horario.
Durante el triage, cada ítem tiene uno de cuatro destinos:
- convertir en proyecto/tarea;
- sumar al log de decisiones;
- archivar como referencia;
- borrar.
La mayoría de las ideas deberían morir.
Eso es sano.
Qué puede hacer un agente con esto
Un agente puede:
- agrupar ideas crudas;
- sugerir qué va en proyectos;
- identificar duplicados;
- extraer seguimientos;
- preparar una lista de triage;
- recordarle al operador que el inbox se está convirtiendo en cajón de basura.
Pero el agente no debería convertir cada pensamiento en una tarea.
Así es como los sistemas se convierten en ruido autoinfligido.
Archivo 4: weekly-review.md
La revisión semanal responde:
¿Qué pasó de verdad, y qué cambia después?
Este archivo es el ritual operativo.
Sin revisión, los otros archivos se degradan.
Plantilla:
# Revisión semanal — 2026-W28
## Planificado
- Publicar ensayos revisados para el sitio personal.
- Enviar dos propuestas a clientes.
- Revisar arquitectura del sistema de seguimiento.
## Lo que pasó de verdad
- Ensayos reescritos y empaquetados.
- Una propuesta enviada, una demorada.
- Arquitectura de seguimiento aclarada pero no implementada.
## Qué se movió
- El posicionamiento personal ahora apunta a fractional systems engineer.
- El encuadre de sistemas de negocio es más claro que el de automatización.
## Qué está trabado
- Hacen falta screenshots reales / prueba anonimizada.
- Hace falta publicar un caso de estudio práctico.
## Decisiones pendientes
- ¿Qué ensayo se convierte en el post flagship?
- ¿Qué sistema se convierte en caso de estudio público primero?
## Próxima semana
- Publicar ensayo flagship.
- Preparar un teardown anonimizado de sistema de seguimiento.
- Contactar tres empresas con la oferta de sistemas.
La revisión semanal debería ser incómoda a veces.
Si nunca genera tensión, probablemente no está conectada a la realidad.
Qué puede hacer un agente con esto
Un agente puede:
- comparar trabajo planificado con la realidad del calendario;
- resumir qué se movió;
- listar proyectos trabados;
- generar acciones de seguimiento;
- detectar bloqueos repetidos;
- preparar prioridades de la próxima semana;
- hacer preguntas más afiladas.
Acá es donde los agentes se vuelven útiles rápido.
Una revisión semanal les da ritmo.
El primer agente
Después de que existan los cuatro archivos, sumá un agente.
No una flota.
Uno.
Dale un trabajo acotado:
Leé los cuatro archivos operativos cada viernes. Producí un reporte operativo semanal con: qué se movió, qué está trabado, qué necesita una decisión, qué está vencido, qué debería seguirse y qué debería morir. No modifiques los archivos fuente. Proponé cambios solamente.
Ese agente puede crear apalancamiento porque el sistema tiene algo para leer.
Sin los archivos, el agente tiene que inferir el negocio desde historial de chat y vibes.
Eso no es un sistema operativo.
Es improvisación.
Cuándo sumar más
Sumá un segundo agente solo cuando el primero tenga un trabajo estable y produzca valor externo.
Buenas razones para sumar otro agente:
- un workflow repetido ya está claro;
- el source of truth es estable;
- el handoff está definido;
- la calidad se puede revisar;
- el output cambia comportamiento real;
- los modos de falla están entendidos.
Malas razones:
- el rol suena cool;
- la herramienta lo hace fácil;
- estás evitando ventas;
- el agente actual es vago;
- querés que el sistema se sienta más completo;
- estás armando infraestructura por status.
Los agentes deberían ser contratados por la operación, no por la imaginación del founder.
Cuándo deberían graduarse los archivos
El texto plano es un sustrato inicial, no una religión.
Algunas cosas deberían moverse eventualmente a otro lado.
Eventos de alto volumen pertenecen a una base de datos.
Los registros de clientes pueden pertenecer a un CRM.
Los secretos pertenecen a un secrets manager.
Los adjuntos pertenecen a storage.
Los logs de producción pertenecen a algún lugar buscable.
Los permisos necesitan un sistema real.
Pero moverse demasiado temprano es caro.
Los archivos son útiles porque obligan claridad antes de la infraestructura.
Una vez que la forma es estable, promové las partes que necesitan garantías más fuertes.
No promuevas confusión.
La razón real por la que funciona
Estos cuatro archivos crean un sistema operativo mínimo.
No para toda la empresa.
Para el operador.
Crean:
- visibilidad del trabajo activo;
- memoria para decisiones;
- una superficie segura de captura;
- un loop semanal de corrección;
- estructura suficiente para que un agente ayude.
Esa es la base.
El agente no crea el modelo operativo.
Los archivos sí.
El agente lo acelera.
Ayudo a empresas a armar la capa operativa detrás de los agentes: archivos source-of-truth, workflows, reportes, integraciones, permisos y loops de revisión. Usá el sistema de cuatro archivos como punto de partida. Si querés convertirlo en un sistema de negocio que funcione, contactame.