Zent OS
Tiramos las herramientas de gestión y escribimos el sistema operativo de la agencia. Adentro corre una flota de agentes que abre pull requests, revisa código, mira los servidores y prepara el trabajo comercial.
Es un producto privado y no está a la venta. Lo publicamos porque es el proyecto del que más aprendimos, y porque explica sobre qué infraestructura corre todo lo demás que hacemos.
- Cuándo
- Junio 2026, un mes
- Quiénes
- 3 personas
- Estado
- En producción
- commits en el repo
- 702 commits en el repodesde el 24 de mayo
- commits en junio
- 382 commits en junioel mes del proyecto
- agentes en loop
- 15 agentes en loopcorriendo programados
- proyectos operados
- 32 proyectos operadossobre 5 servidores
Ninguna herramienta sabía nada de lo que estaba pasando.
La agencia opera más de quince clientes con un equipo chico. Probamos las herramientas conocidas y con todas pasó lo mismo: para que la operación entrara en su grilla, había que deformar cómo el equipo piensa. Los clientes se volvían tableros, los proyectos se volvían épicas, y las oportunidades que nacían de una conversación no tenían dónde vivir.
El problema más caro no era ese, igual. Era que ninguna sabía nada del trabajo real. Para saber si un proyecto estaba sano había que preguntarle a la persona que lo estaba haciendo, porque la herramienta solo tenía lo que alguien se había acordado de cargar. Las decisiones vivían en el mail, el estado técnico en el repositorio, y lo aprendido en la cabeza de quien lo aprendió.
El equipo terminó volviendo a un pizarrón físico, porque era el único lugar donde el modelo mental entraba entero. Zent OS es ese pizarrón, pero que además leyó los mails, los commits y las reuniones de la semana.
Todo cae a una sola memoria, y todo agente nuevo nace con acceso.
Commits con su contexto, mails con clientes, documentos subidos, reuniones, comentarios del portal externo, decisiones y aprendizajes: todo termina en una base vectorial dentro del mismo Postgres que guarda el resto. La búsqueda es híbrida, vectorial más filtros estructurados por cliente, proyecto, fecha y autor, resuelta en una sola consulta.
La consecuencia práctica es la que importa. Sumar el agente número dieciséis es escribir su prompt y su cadencia, porque el contexto ya está resuelto. En la arquitectura anterior habría sido integrarlo contra seis sistemas distintos y mantener seis integraciones para siempre.
Sobre esa memoria vive el chat interno, que responde preguntas del tipo “cómo viene tal proyecto” o “qué aprendimos en aquel caso que sirva para este”, y que además puede ejecutar acciones: crear tareas, generar reportes, mover una oportunidad de etapa.
- Commits de todos los repos activos
- Casillas de mail de los tres founders
- Documentos y archivos compartidos
- Calendario y notas de reuniones
- Notas internas y decisiones del equipo
- Comentarios de clientes en el portal
Un agente clasificador decide qué entra y con qué etiquetas. Sin ese filtro, la memoria se convierte en un depósito y la búsqueda deja de servir.
Quince agentes con cadencia propia, no un asistente que espera que le hablen.
La diferencia entre esto y un chat con herramientas es que acá nadie tiene que abrir nada. Cada agente tiene su horario, su alcance y su forma de avisar. La mayoría corre y no dice nada, que es exactamente lo que queremos: solo aparecen cuando hay algo que una persona tiene que resolver.
Project Supervisor
cada 5 minEl latido del sistema. Mira cada plan en ejecución, despacha las tareas que quedaron desbloqueadas, reintenta lo que falló y cierra la fase cuando terminó para arrancar la siguiente.
Coding Agent
por demandaRecibe una instrucción en lenguaje natural, aplica el cambio sobre un espacio de trabajo aislado y abre un pull request. Nunca toca producción de forma directa: su única salida es un PR.
Reviewer
por cada PRLee el pull request del agente anterior y emite veredicto. Si pide cambios, dispara una ronda de arreglo acotada antes de que un humano gaste tiempo mirándolo.
Memory Curator
cada 5 minClasifica todo lo que entra al sistema (mails, documentos, reuniones, archivos) y decide qué merece quedar en memoria y con qué etiquetas. Sin este, la memoria se convierte en un depósito.
Mapper
al abrir proyectoToma el contexto crudo de un proyecto nuevo y devuelve tres cosas: el alcance escrito, un plan por fases y la lista de preguntas que todavía no tienen respuesta, separadas entre las que contesta el equipo y las que hay que hacerle al cliente.
Lead Intelligence
cada 30 minLee el mail nuevo de cada oportunidad comercial abierta y mantiene actualizado qué tan cerca está de necesitar una propuesta.
Reply Suggester
cada 30 minCuando el último mail de un hilo es del prospecto, redacta la respuesta con el hilo completo y la memoria de la agencia adentro. El humano la edita y la manda desde su propia casilla.
Follow-up Agent
diarioBusca las propuestas enviadas sin respuesta hace varios días y deja escrito el seguimiento, esperando aprobación. Nunca manda un mail solo.
Pipeline Coach
lunes 09:00Arranca la semana avisándole al responsable de cada oportunidad que se está enfriando, con una próxima acción concreta sugerida.
Opportunity Hunter
martes 09:00Cruza lo que el equipo construyó puertas adentro contra la cartera de clientes y propone dónde eso mismo se puede vender de nuevo.
Weekly Narrator
viernes 18:00Traduce la semana técnica de cada proyecto a lenguaje que un cliente entiende, y la deja lista para publicar en el portal externo.
Uptime Sentinel
cada 5 minPinga cada servicio declarado y avisa solo en las transiciones, cuando algo se cae y cuando se recupera. No hace ruido si el estado no cambió.
Daily Pulse
diario 08:00El resumen matutino de todo lo que necesita una persona: clientes trabados, propuestas por aprobar, agentes con preguntas, servicios caídos. Si está todo en verde, no manda nada.
Client Health
diarioRecalcula la salud sugerida de cada cliente a partir de señales concretas. Es determinístico a propósito: acá no queríamos que un modelo opine.
Knowledge Graph
cada 5 minResuelve identidades y vincula reuniones con las personas y proyectos que corresponden, para que preguntar por alguien devuelva todo lo suyo y no tres versiones sueltas del mismo nombre.
Una instrucción en castellano entra, un pull request revisado sale.
Es la pieza que más se usa y la que más restricciones tiene. El agente no tiene acceso de escritura a producción ni permiso para saltearse el proceso: su única salida posible es un pull request que alguien más mira.
- 01
Instrucción
Llega en lenguaje natural, desde el panel o desde WhatsApp. No hay ticket que llenar ni formulario con veinte campos.
- 02
Espacio aislado
El agente trabaja sobre un clon cacheado del repo, en un espacio de trabajo efímero que se borra al terminar. No comparte disco con otro job.
- 03
Pull request
La única salida posible del agente. No puede empujar a la rama principal ni editar el servidor de producción para arreglar algo rápido.
- 04
Cuatro revisiones
Revisión de código, prueba funcional con browser real, mirada de experiencia de uso y auditoría de seguridad. Cada una emite veredicto por separado.
- 05
La firma humana
A la rama de desarrollo puede entrar solo si el proyecto está marcado como automático y todo dio verde. A la rama principal siempre entra una persona.
Un agente puede operar los servidores por WhatsApp. Con tres niveles de freno.
Cualquiera de los tres founders puede escribirle por WhatsApp y pedirle que mire los registros de un servicio, que traiga los últimos cambios o que despliegue algo. Es la función más útil del sistema y también la más peligrosa, así que cada comando pasa por un clasificador antes de ejecutarse.
El número que miramos no es cuántos comandos corrieron, es la proporción entre los tres niveles. Si pide permiso demasiado seguido, la gente aprueba sin leer, y eso es peor que no preguntar.
Corre solo
Leer registros, mirar el estado de un contenedor, traer los últimos cambios. Todo lo que observa sin modificar nada pasa sin preguntar.
Pide permiso
Reiniciar un servicio, bajar un contenedor, tocar configuración sensible, cualquier cosa con riesgo real de dejar algo abajo. Espera el sí explícito de un founder.
No corre nunca
Borrados masivos de raíz, formateos, apagados, escrituras sobre discos. Esta lista no se puede desactivar ni pidiéndoselo, ni cambiándole la configuración al agente.
Cuatro apuestas que explican por qué esto sigue prendido y no fue una demo.
- 01
El humano firma, y eso es producto
La mayoría de las demos agénticas se rompen en la misma pregunta: qué pasa cuando se equivoca. Nuestra respuesta no fue mejorar el modelo, fue diseñar el sistema para que la última firma sea siempre de una persona identificable, y que quede registrada. El agente investiga, escribe, propone y deja todo listo. El sí lo pone alguien. Eso no lo hicimos por miedo: lo hicimos porque es lo único que nos deja darle más autonomía sin perder el sueño.
- 02
Dos modelos, dos presupuestos
El razonamiento conversacional y la elección de qué herramienta llamar corren en un modelo barato. El trabajo de código pesado corre en uno caro. La razón es aburrida y por eso funciona: la gran mayoría de los turnos son consultas de estado que no justifican el modelo grande. Bajar el costo del turno común es lo que hace que el sistema se pueda dejar prendido las veinticuatro horas en vez de encenderlo para la demo.
- 03
La memoria es la infraestructura, no una función
Commits, mails, documentos, reuniones y decisiones caen a una sola base con búsqueda vectorial y filtros estructurados en la misma consulta. Todo agente nuevo que sumamos nace con acceso a eso el día uno. Es la diferencia entre agregar el agente número dieciséis en una tarde y tener que integrarlo contra seis sistemas distintos.
- 04
Corre en fierros propios
Base de datos, vectores, colas, panel y portal viven en servidores nuestros. La única dependencia externa son las APIs de los modelos. No pagamos por asiento ni por tenant, y el dato de cada cliente no sale de nuestra infraestructura. Para una agencia que firma acuerdos de confidencialidad, eso dejó de ser una preferencia técnica y pasó a ser un argumento comercial.
Las cuatro cosas que hicimos mal antes de que empezara a andar.
El plan grande murió; la iteración chica ganó
El primer intento fue un plan de tres fases para construir la flota entera de una. Se cerró sin escribir una línea. Lo que terminó funcionando fue una sucesión de cambios chicos que se podían mergear el mismo día.
La regla no alcanza si no está impuesta
Durante semanas el "el agente no mergea a la rama principal" vivía solo en el prompt. Funcionaba, pero funcionaba porque el modelo obedecía, no porque no pudiera. La protección de rama de verdad fue requisito para habilitar cualquier automatismo.
El sistema pide permiso demasiado o muy poco
Calibrar cuándo un agente frena a preguntar es la parte más difícil. Si pregunta de más, la gente empieza a aprobar sin leer, que es peor que no preguntar. Terminamos midiendo la proporción entre lo que corre solo y lo que escala, y ajustando contra eso.
Ordenar la documentación fue prerrequisito, no tarea de limpieza
Los agentes leen las mismas notas que el equipo. Mientras la documentación interna tuvo dos formatos conviviendo, los agentes generaban trabajo en el formato viejo. Normalizar eso fue la primera etapa del proyecto, antes de tocar el orquestador.
Los tres, el mes entero, sin repartirse por especialidad.
- Isidro Pasman
“Probamos todas las herramientas y siempre terminábamos deformando cómo pensamos para que entre en la grilla de otro. El día que volvimos al pizarrón de verdad, con marcador, entendimos que el problema no era la herramienta: era que ninguna sabía nada de lo que estaba pasando realmente. Zent OS es ese pizarrón, pero que además leyó los mails, los commits y las reuniones de la semana.”
- Francisco Sobral
“Queríamos dejar de contestar la pregunta "cómo viene tal cliente" abriendo seis pestañas. Si el sistema ya tiene los commits, los mails y las decisiones adentro, que la conteste él. Lo que más nos sorprendió no fue que los agentes escriban código, sino cuánto trabajo nuestro era simplemente mover información de un lado a otro.”
- Bautista Silvano Lima
“La regla que no negociamos fue que el agente nunca cierra el círculo solo. Puede investigar, escribir, proponer y dejarlo listo, pero la última firma es de una persona. No es desconfianza: es que el día que algo salga mal queremos poder señalar exactamente quién dijo que sí, y a qué hora.”
No se vende, no tiene lista de espera y no compitió contra nadie.
Esta edición está publicada para documentarla. Si te interesó cómo está armado, el lugar para preguntar es la sección de comentarios de la ficha: las contestamos nosotros.