Dos agentes
Para shippear en esta era agéntica los workflows posibles son casi infinitos, y aun así parece que todos hacemos lo mismo: un agente que escribe código y un post enseñándolo. Nosotros también tenemos ese agente. Pero el que nos ha cambiado la organización es otro: un agente que no toca el repo, vive en nuestro grupo de Telegram como bot y apunta lo que decidimos para que el primero lo construya.
El primer día expulsamos al bot del grupo. Contestaba a todas las conversaciones, opinaba de temas ya cerrados, literalmente se creía el centro del universo. Era más una molestia que una ayuda.
Duró poco fuera, y el arreglo no fue de prompt sino de gateway, dos parámetros del perfil: require_mention: true para que solo hable cuando lo mencionamos, y observe_unmentioned_group_messages: true para que lea todo el grupo y pueda hacer resúmenes de los temas tratados.
No monté un harness desde cero. Aproveché el VPS que ya tenía configurado con Hermes, mi harness de agentes, el que corre los perfiles y el gateway, y encima levanté dos cosas: la web del hackathon, hacksnow.dev, y el agente que nos organiza por dentro.
Un prompt, un commit, un deploy
El flujo para desplegar y hacer cambios en la web es simple. Desde mi Mac abro una sesión del proyecto en T3 Code, un IDE para sesiones de agente sobre distintos harnesses. El proyecto está sincronizado en el VPS y en Git. La sesión se abre con OpenCode como provider por debajo (es el harness principal para buildear la web) y con los modelos de nan.builders, una comunidad de inferencia local para modelos open source. Ahí realizo los cambios necesarios, y con un plugin de T3 Code voy verificando en el mismo IDE mientras el agente toca.
Cuando lo he verificado todo y me convence, commit a main y Cloudflare Pages se actualiza solo: la web servida, el dominio apuntando ahí y las inscripciones de los asistentes guardadas en una D1, la base de datos SQL serverless de Cloudflare sobre SQLite.
Y aquí está lo que nos ahorra tiempo de verdad: una vez montado, una modificación es un prompt. Sin abrir el repo, sin buscar el componente, sin tocar la configuración a mano. Pides el cambio y listo.
El Secretario
El Secretario es toda la información que no quieres que se te pase, centralizada en un agente. Nos acompaña en las tareas del hackathon: recuerda, resume y organiza lo que dijimos en las llamadas. Telegram es nuestro canal principal, así que el agente sale al grupo: escribe al grupo entero y también a personas concretas cuando toca. Con varias personas trabajando a la vez, se recoge cada mensaje y se actualizan las tareas.
Y tiene un valor añadido que no esperaba: todo lo que hablo con él queda preparado para el agente que trabaja en el repo. Lo que decide el equipo no se pierde entre conversaciones: sale del chat y entra en Git.
Dónde vive y qué puede tocar
El Secretario vive en una carpeta suya en el VPS:
- tareas.md es el backlog.
- notas/ son las actas: qué se dijo, qué se decidió, qué quedó abierto.
- investigacion/ lo que busca, con el precio o el enlace al lado.
- miembros.md, quién es quién, para saber a quién puede escribir en privado.
- datos/, donde caen las sincronizaciones.
Esa carpeta se monta dentro del contenedor como /workspace: es lo único que ve el Secretario.
El agente del chat no ejecuta en el host. Ejecuta en un contenedor Docker, con escritura solo en los montajes que le he permitido. ~/.hermes, /etc y las credenciales no los ve: el token de acceso a D1 vive en el host y el cron lo ejecuta fuera; al agente le llega el resultado ya limpio, en datos/.
Los recordatorios
Al final, un asistente no tiene mucho sentido si no puede recordarte cosas o mandarte información. Aquí entran los cronjobs: recopilar información, recordar tareas, sincronizar con la base de datos de Cloudflare.
Un cron cada seis horas lee el grupo y actualiza tareas.md y notas/. Lo que se habla por la mañana aparece en la siguiente pasada, con la fecha y los ids de los mensajes. Y cuando no hay nada nuevo, lo dice y no escribe: el digest reporta lo que procesa, sin inventarse actividad.
El segundo cronjob es d1_sync.py: cada doce horas se trae las inscripciones de la D1 de Cloudflare a datos/. Lo que cae ahí ya es contexto que el agente puede leer, así que puede decir cuántas candidaturas hay sin que yo abra el panel.
Todo esto corre en el plan gratuito: cada D1 admite 500 MB, con 5 millones de filas leídas y 100.000 escritas al día. Para las inscripciones de un hackathon va sobrado, aquí ni hemos rozado el límite.
Otros cronjobs trabajan sobre el histórico del grupo y lo dejan en CSV, SQL y Markdown. Sirven para lo que nadie quiere contar a mano, como cuántas veces ha salido un hotel o qué quedó pendiente de la reunión anterior.
Lo que sabe uno, lo usa el otro
Aquí está lo que más me gusta del sistema: lo que sabe el Secretario lo recoge el agente que trabaja en el repositorio. El del grupo sabe qué ha dicho el equipo; el del repo sabe qué hay que construir. Los dos viven en el mismo VPS y tiran del mismo LLM.
Un ejemplo real, sin hacer spoilers del evento. En la primera reunión salió que hacía falta un FAQ en la web: dudas que la gente no tenía dónde consultar. Hicimos el borrador entre todos, se lo pasamos al asistente, lo validó y dejó una nota preparada para el agente de OpenCode. Con la nota lista, el prompt fue una línea: "necesitamos añadir un botón de FAQ con la nota que ha dejado lista el agente".
El agente del repo lleva un AGENTS.md en el workspace. Ahí le queda claro:
- Entorno.
El repo vive en un VPS que gestiona el Secretario, y sus notas están en una carpeta del servidor.
- Convenciones.
Sitio estático HTML/CSS/JS con Cloudflare Pages y Workers; las convenciones de copy y la FAQ de la landing salen de esas notas.
- Reglas.
Leer git log y git status antes de tocar nada, no commitear secrets ni .dev.vars, y coordinar cualquier cambio de copy o FAQ con las notas del secretario.
Ahí se cierra el bucle: el Secretario apunta, el agente lee.
Todo junto
El mapa completo: el código, la conversación y los datos, todo sobre el mismo VPS.
No todo de golpe
Para que conste el coste real: el Secretario se montó en un finde y se fue fixeando en tardes sueltas según lo probábamos. El VPS son unos 5€ al mes, y los LLM consumen tokens de los modelos de nan.builders.
Hay más herramientas que sería muy útil añadir, como un MCP del correo de la organización para gestionar correos, pero de momento dependeremos del HITL en esa parte. Lo vamos dando escalonado: sin dar acceso root a todo y probando las funcionalidades. Primero, que el Secretario demuestre que va fino, y luego abrimos la puerta a más.
Esto aún está creciendo. Os iré contando; y si os interesa, la parte de Cloudflare da para otro post.