Un agente lee Slack, Google, Git y Jira para que yo reciba un briefing al día

En mi trabajo, lo que pasa ocurre en cinco lugares a la vez. Hilos de Slack, email y calendario, merge requests, páginas de Confluence, tickets de Jira. Nadie lee todo eso, y la persona que lo intenta se pasa el día leyendo en vez de construir.

Así que dejé de intentarlo. Un cron job de Hermes Agent lee esas fuentes una vez al día a través de MCP servers y me escribe un briefing. Sabe quién es quién y qué proyectos importan porque lee mi second brain primero. Ordena lo que encuentra por seis sentidos en vez de por herramienta. Su único trabajo es leer. Lo único que produce es un mensaje, para mí.

Así es como funciona, cómo construir el tuyo, y las decisiones de diseño que evitan que se vuelva otro digest ruidoso. No voy a describir qué dice mi briefing. Eso es de la empresa. El patrón es de cualquiera.

Qué es en realidad un chief of staff con IA

Un chief of staff con IA no es un producto que compras. Es un agente programado con tres cosas: acceso de lectura a donde pasa el trabajo, tu contexto para poder distinguir señal de volumen, y un formato que tiene que llenar siempre. El mío es un cron job de Hermes. La misma idea funciona con cualquier runtime de agentes que pueda correr con un horario y hablar con MCP servers.

Los productos que se venden bajo ese nombre casi siempre hacen solo la primera parte: se conectan a tus herramientas y resumen. El resumen es la parte fácil. Saber qué te importa esta semana es la parte difícil, y esa vive en tu cabeza, o, si tienes uno, en tu second brain.

Cómo funciona el briefing diario

Una corrida del briefing

Entrada

Un cron job de Hermes se dispara una vez al día

↓

1. CONTEXTOLeer el second brain

   Quién es quién, qué proyectos están vivos, de qué soy responsable. Solo lectura. El job nunca le escribe.

   ↓
2. LEERLeer la empresa a través de MCP

   Slack, Google Workspace, Git y Confluence/Jira, cada uno a través de su MCP server.

   ↓
3. ORDENARClasificarlo en seis sentidos

   No por la herramienta de donde vino. Un hilo de Slack y un ticket de Jira sobre lo mismo terminan en el mismo lugar.

   ↓
4. ESCRIBIRUn solo briefing, mismo formato todos los días

   Qué se movió, qué me necesita, qué viene. El formato es un skill, así que el prompt queda corto y el resultado queda comparable.

↓

Salida

Un mensaje que leo en vez de cinco herramientas que ojeo

Dos decisiones de ese pipeline hacen la mayor parte del trabajo. El briefing está organizado por sentidos, no por fuentes. Y mi contexto entra antes que los datos de la empresa.

Seis sentidos, no seis herramientas

Las herramientas son donde vive el dato. Los sentidos son las preguntas. Uso un framework de seis sentidos que construí primero para apuntar agentes al mercado, y se traslada a una empresa casi uno a uno.

Los seis sentidos, como preguntas que hace un briefing diario

Cada sentido puede traer datos de varias herramientas. Cada herramienta alimenta varios sentidos.

Sentido	La pregunta
Self	¿Qué se movió en las cosas de las que ya soy parte?
Ellos	¿Qué están lanzando o decidiendo otros equipos que toca mi trabajo?
Tendencia	¿De qué habla la empresa más esta semana que la pasada?
Frontera	¿Qué se volvió posible recién: una herramienta nueva, una plataforma nueva, un release nuevo?
Comunidad	¿Qué está pidiendo, trabando o reclamando la gente?
Cliente	¿Qué necesita de mí la gente a la que sirvo?

Ordenar por herramienta te da una sección de Slack, una de Jira y una de Git, y todavía tienes que hacer tú la síntesis. Ordenar por sentido hace la síntesis por ti. El merge request, el hilo que discute sobre él y el ticket que lo pidió terminan como un solo item bajo el sentido que responden.

Un agente sin sensor está ciego y adivinando. El MCP server es el puente del sensor al dato real.

Esa frase es toda la razón por la que el briefing está construido sobre MCP. La opinión del agente sobre lo que pasó en la empresa no vale nada. Su lectura de lo que la empresa de verdad escribió, sí.

El contexto es lo que convierte un digest en un briefing

Apunta un agente a Slack sin contexto y reporta volumen. Gana el canal más ruidoso. El hilo con más mensajes parece lo más importante que pasó.

Mi second brain arregla eso. Es una wiki en markdown que curo yo, con una página por cada proyecto en el que estoy y notas de las reuniones a las que voy. El briefing la lee antes que nada más, así que sabe que un hilo de dos mensajes en un canal tranquilo importa más que cien mensajes en algún lugar donde no tengo nada en juego.

El job lee la wiki. No le escribe. Eso es deliberado. La wiki es lo que decidí guardar. El briefing es la lectura del agente de un día. Dejar que un job diario escriba en mi base de conocimiento mezclaría las dos cosas, y en un mes no sabría qué notas escribí yo y cuáles adivinó un agente. La versión larga de ese límite está en Hermes Agent y un second brain.

Digest

1. 01Organizado por herramienta
2. 02Ordena por volumen
3. 03Reporta todo lo que pasó
4. 04Haces tú la síntesis
5. 05Lo ojeas, después lo ignoras

Briefing

1. 01Organizado por las preguntas que te importan
2. 02Ordena por lo que toca tu trabajo
3. 03Reporta lo que te necesita
4. 04El agente hace la síntesis
5. 05Se lee, porque es corto y específico

Cómo construir un briefing diario en Hermes

Hermes corre cron jobs desde su gateway, que revisa el scheduler cada 60 segundos. Cada job que toca arranca una sesión de agente nueva, corre, y entrega su respuesta final al destino que eliges. Los jobs viven en ~/.hermes/cron/jobs.json y la salida de cada corrida se guarda bajo ~/.hermes/cron/output/.

Así es la forma de un job de briefing. Los nombres y las rutas son placeholders.

Programar el briefing

1. Crear el job

   $ hermes cron create "every 1d at 08:30" \
     "Write today's briefing. Follow the daily-briefing skill exactly." \
     --name daily-briefing \
     --skill daily-briefing \
     --workdir /home/me/second-brain \
     --deliver telegram \
     --reasoning-effort medium

2. Verificar que el scheduler está vivo

   $ hermes cron status

3. Correrlo una vez ahora, para ver el primer briefing

   $ hermes cron run daily-briefing

Cada flag ahí está haciendo un trabajo.

--skill carga el método. Una corrida de cron es una sesión nueva sin memoria de ayer, así que el prompt tiene que ser autosuficiente. Pon los seis sentidos, el formato y las reglas en un skill y el prompt queda en una línea.

--workdir es por dónde entra tu contexto. Por default, un cron job no carga ningún contexto de proyecto. Con un working directory fijado, Hermes inyecta el AGENTS.md, CLAUDE.md o .cursorrules de ese directorio en el system prompt y corre sus herramientas de archivos desde ahí. Apúntalo a tu second brain y el AGENTS.md del vault se vuelve el briefing del job sobre quién eres.

--deliver decide dónde cae: Telegram, Slack, email, un archivo local, o el chat desde el que lo creaste. El agente no manda nada por sí mismo. Hermes entrega la respuesta final, y redacta cualquier cosa con forma de credencial en el camino.

--reasoning-effort fija el nivel de pensamiento solo para ese job, así que una síntesis diaria puede correr con más esfuerzo que el resto de tu flota. Puedes fijar el modelo por job de la misma forma con --model y --provider.

Un esqueleto del skill, para que el formato quede concreto:

---
name: daily-briefing
description: Write the daily briefing from the company's MCP sources, sorted by six senses.
---

Read AGENTS.md first: it says who I am, who is who, and which projects matter.

For each sense, report only what touches my work. Skip a sense with nothing to say.
Self · Them · Trend · Frontier · Community · Client

Rules:

- Read only. Never post, comment, react or edit anywhere.
- Every item links to its source (thread, ticket, merge request, doc).
- If a source failed to load, say which one at the top. Never report "nothing happened" for a source you could not read.
- At most 15 items. If you have more, keep the ones closest to my projects.

Las configuraciones que lo mantienen barato y honesto

Acota las herramientas. Un cron job recibe el toolset que configuraste para la plataforma de cron, y a través de la herramienta cronjob puedes fijar los enabled_toolsets de un job exactamente a los MCP servers que lee. Un briefing no necesita un navegador, una terminal ni delegación. Cada herramienta que dejas afuera es un schema que el modelo no paga en cada llamada.

Deja que el preflight falle en voz alta. Antes de una corrida, Hermes revisa que la key del proveedor resuelva, que los skills adjuntos estén listos, que el destino de entrega esté configurado, y que cada MCP server que el job nombra en verdad se conectó. Si alguno nunca lo hizo, el job queda marcado blocked_config, recibes una sola alerta, y no se hace ninguna llamada al modelo. Un briefing roto no cuesta nada y te dice por qué.

Haz el briefing respondible. Las entregas son fire-and-forget por default: respondes a una y el agente no tiene idea qué dijo. Activa las entregas continuables (cron.mirror_delivery, o por job) y cada briefing abre su propio hilo, con el briefing ya cargado, así que “cuéntame más del item tres” funciona.

Separa recolección de escritura cuando crece. context_from alimenta la última salida de un job en el prompt de otro job. Un colector puede correr primero y un escritor después, cada uno con sus propias herramientas y modelo.

Ese callout viene de una lección anterior: el agente es un narrador poco confiable, y el log de ejecución es la verdad del terreno.

Acceso de lectura, nunca una voz

La regla de diseño más importante para un job así: lee, y nunca habla por ti. Conecta cada fuente con acceso solo de lectura. Lo único que el job debería producir jamás es un mensaje para ti.

Acotar cada fuente es su propio trabajo: Slack MCP server y Google Workspace MCP cubren las dos de mayor señal, y Hermes Agent y MCP cubre cómo conectar cualquier server a Hermes.

Un agente que puede publicar en Slack, comentar en un merge request o responder un email en tu nombre es un producto distinto con un riesgo distinto. Puede ser útil. No debería ser lo primero que construyas, y nunca debería venir empaquetado con un job cuyo propósito es leer todo.

Antes de programar un briefing

• ✓Obligatorio:
  Cada fuente de MCP está conectada con acceso solo de lectura.Si un server no se puede acotar a solo lectura, no se lo des a un job programado.
• ✓Obligatorio:
  El método vive en un skill, no en el prompt del cron.Una corrida de cron arranca desde cero. Un prompt de una línea más un skill es más fácil de versionar y revisar que una página de prompt.
• ✓Obligatorio:
  Tu contexto es algo que el agente lee, no algo que escribe.Apunta el workdir del job a un vault curado. Mantén la salida diaria del agente fuera de él.
• ✓Obligatorio:
  Las herramientas del job están fijadas a lo que lee.Ningún navegador, ninguna terminal, ninguna delegación para un briefing.
• ✓Obligatorio:
  El briefing dice qué fuentes fallaron.Un día tranquilo y un conector roto se ven idénticos a menos que el formato fuerce la diferencia.
• ✓Obligatorio:
  Entrega solo a ti.Un briefing sobre una empresa es sensible por default. Un destinatario, un canal.

Agente de briefing diario, respuestas rápidas

¿Qué es un chief of staff con IA?+

Un agente programado que lee dónde pasa tu trabajo, sabe lo suficiente de ti como para distinguir qué importa, y te entrega un briefing corto en un formato fijo. Es un patrón, no un producto. Puedes construir uno con cualquier runtime de agentes que corra con un horario y se conecte a MCP servers, como Hermes Agent.

¿Hermes Agent puede leer Slack, Gmail y Jira?+

Sí, a través de MCP servers. Hermes es un cliente de MCP, así que cualquier MCP server de Slack, Google Workspace, Git o Atlassian que configures se vuelve un conjunto de herramientas que un job puede llamar. Usa acceso solo de lectura para todo lo que toque un job programado.

¿Un cron job de Hermes recuerda el briefing de ayer?+

No. Cada corrida es una sesión nueva sin memoria de corridas anteriores.

Si necesitas continuidad, encadena jobs con context_from, guarda estado en un archivo que el job lea, o activa las entregas continuables para poder responder un briefing con él en el contexto.

¿Cómo evito que un agente programado publique en mi nombre?+

Dale a sus fuentes acceso solo de lectura, fija las herramientas del job a los MCP servers que lee, y entrega el resultado solo a ti mismo. Hermes entrega la respuesta final del job, así que el agente nunca necesita una herramienta que manda mensajes.

¿Cuánto cuesta correr un briefing diario?+

Depende de cuántas herramientas carga el job y qué modelo corre. Fijar los toolsets del job mantiene los schemas de herramientas sin usar fuera de cada llamada, y un modelo fijado por job deja que el briefing corra en un modelo más barato que tus sesiones interactivas.

Un job cuyas fuentes fallan el preflight no hace ninguna llamada al modelo.