Um agente lê Slack, Google, Git e Jira para eu só receber um briefing por dia

No meu trabalho, o trabalho acontece em cinco lugares ao mesmo tempo. Threads no Slack, e-mail e agenda, merge requests, páginas no Confluence, tickets no Jira. Ninguém lê tudo isso, e quem tenta passa o dia lendo em vez de construir.

Então eu parei de tentar. Um cron job do Hermes Agent lê essas fontes uma vez por dia por servidores MCP (o protocolo que deixa um agente puxar dado direto de outras ferramentas, sem precisar de uma integração sob medida para cada uma) e escreve um briefing para mim. Ele sabe quem é quem e quais projetos importam porque lê meu second brain primeiro. Organiza o que encontra por seis sentidos em vez de por ferramenta. O trabalho dele é só ler. A única coisa que ele produz é uma mensagem, para mim.

Isto é como isso funciona, como construir o seu, e as escolhas de design que mantêm isso um briefing em vez de mais um digest barulhento. Eu não vou descrever o que o meu briefing diz. Isso pertence à empresa. O padrão pertence a qualquer um.

O que um AI chief of staff realmente é

Um AI chief of staff não é um produto que você compra. É um agente agendado com três coisas: acesso de leitura a onde o trabalho acontece, o seu contexto para saber separar sinal de volume, e um formato que ele precisa preencher toda vez. O meu é um cron job do Hermes. A mesma ideia funciona com qualquer agent runtime que roda numa agenda e fala com servidores MCP.

Os produtos vendidos sob esse nome fazem, na maioria, só a primeira parte: eles conectam nas suas ferramentas e resumem. O resumo é a parte fácil. Saber o que importa para você nesta semana é a parte difícil, e ela vive na sua cabeça, ou, se você tiver um, no seu second brain.

Como o briefing diário funciona

Uma execução do briefing

Entrada

Um cron job do Hermes dispara uma vez por dia

↓

1. CONTEXTLer o second brain

   Quem é quem, quais projetos estão ativos, pelo que eu sou responsável. Só leitura. O job nunca escreve nele.

   ↓
2. SENSELer a empresa por MCP

   Slack, Google Workspace, Git e Confluence/Jira, cada um pelo próprio servidor MCP.

   ↓
3. SORTOrganizar sob seis sentidos

   Não pela ferramenta de origem. Uma thread no Slack e um ticket no Jira sobre a mesma coisa caem no mesmo lugar.

   ↓
4. WRITEUm briefing, mesmo formato todo dia

   O que mudou, o que precisa de mim, o que vem a seguir. O formato é uma skill, então o prompt fica curto e o resultado fica comparável.

↓

Saída

Uma mensagem que eu leio em vez de cinco ferramentas que eu teria que varrer

Duas decisões nesse pipeline fazem a maior parte do trabalho. O briefing é organizado por sentidos, não por fontes. E o meu contexto entra antes do dado da empresa.

Seis sentidos, não seis ferramentas

As ferramentas são onde o dado vive. Os sentidos são as perguntas. Eu uso um framework de seis sentidos que construí primeiro para apontar agentes para o mercado, e ele se aplica a uma empresa quase um para um.

Os seis sentidos, como perguntas que um briefing diário faz

Cada sentido pode puxar de várias ferramentas. Cada ferramenta alimenta vários sentidos.

Sentido	A pergunta
Self	O que mudou nas coisas de que eu já faço parte?
Them	O que outros times estão lançando ou decidindo que toca o meu trabalho?
Trend	Do que a empresa está falando mais essa semana do que na passada?
Frontier	O que acabou de se tornar possível: uma ferramenta nova, uma plataforma nova, um release novo?
Community	O que as pessoas estão pedindo, travando ou reclamando?
Client	O que as pessoas que eu atendo precisam de mim?

Organizar por ferramenta te dá uma seção de Slack, uma seção de Jira e uma seção de Git, e você ainda tem que fazer a síntese sozinho. Organizar por sentido faz a síntese para você. O merge request, a thread discutindo ele e o ticket que pediu ele terminam como um item só, sob o sentido que respondem.

Um agente sem sensor está cego e chutando. O servidor MCP é a ponte do sensor até o dado real.

Essa frase é a razão inteira pela qual o briefing é construído sobre MCP. A opinião do agente sobre o que aconteceu na empresa não vale nada. A leitura dele do que a empresa de fato escreveu vale.

Contexto é o que transforma um digest num briefing

Aponte um agente para o Slack sem contexto nenhum e ele reporta volume. O canal mais barulhento ganha. A thread com mais mensagens parece a coisa mais importante que aconteceu.

O meu second brain corrige isso. É uma wiki em markdown que eu curo, com uma página para cada projeto em que estou envolvido e notas das reuniões em que participo. O briefing lê ela antes de ler qualquer outra coisa, então ele sabe que uma thread de duas mensagens num canal quieto importa mais que cem mensagens em algum lugar onde eu não tenho interesse nenhum.

O job lê a wiki. Ele não escreve nela. Isso é deliberado. A wiki é o que eu decidi guardar. O briefing é a leitura do agente sobre um dia. Deixar um job diário escrever na minha base de conhecimento misturaria as duas coisas, e num mês eu não saberia mais quais notas eu escrevi e quais um agente chutou. A versão completa dessa fronteira está em Hermes Agent e um second brain.

Digest

1. 01Organizado por ferramenta
2. 02Ranqueia por volume
3. 03Reporta tudo que aconteceu
4. 04Você faz a síntese
5. 05Passado o olho, depois ignorado

Briefing

1. 01Organizado pelas perguntas que importam para você
2. 02Ranqueia pelo que toca o seu trabalho
3. 03Reporta o que precisa de você
4. 04O agente faz a síntese
5. 05Lido, porque é curto e específico

Como construir um briefing diário no Hermes

O Hermes roda cron jobs a partir do próprio gateway, que checa o scheduler a cada 60 segundos. Todo job que vence inicia uma sessão de agente nova, roda, e entrega a resposta final num destino que você escolhe. Os jobs vivem em ~/.hermes/cron/jobs.json e o output de cada execução fica salvo em ~/.hermes/cron/output/.

Aqui está o formato de um job de briefing. Os nomes e caminhos são placeholders.

Agende o briefing

1. Criar o 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. Checar se o scheduler está vivo

   $ hermes cron status

3. Rodar uma vez agora, para ver o primeiro briefing

   $ hermes cron run daily-briefing

Toda flag ali está fazendo um trabalho.

--skill carrega o método. Uma execução de cron é uma sessão nova sem memória de ontem, então o prompt precisa ser autocontido. Coloque os seis sentidos, o formato e as regras numa skill e o prompt fica numa linha.

--workdir é como o seu contexto entra. Por padrão um cron job não carrega contexto de projeto nenhum. Com um diretório de trabalho configurado, o Hermes injeta o AGENTS.md, CLAUDE.md ou .cursorrules desse diretório no system prompt e roda as ferramentas de arquivo a partir dali. Aponte para o seu second brain e o AGENTS.md do vault se torna o briefing do job sobre quem você é.

--deliver decide onde ele chega: Telegram, Slack, e-mail, um arquivo local, ou o chat de onde você criou ele. O agente não manda nada sozinho. O Hermes entrega a resposta final, e redige qualquer coisa parecida com uma credencial antes de sair.

--reasoning-effort fixa o nível de raciocínio só para esse job, então uma síntese diária pode rodar num effort mais alto que o resto da sua frota. Você fixa o modelo por job do mesmo jeito, com --model e --provider.

Um esqueleto da skill, para deixar o formato 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.

As configurações que mantêm isso barato e honesto

Estreite as ferramentas. Um cron job recebe o toolset configurado para a plataforma de cron, e pela ferramenta cronjob você consegue fixar o enabled_toolsets de um job exatamente para os servidores MCP que ele lê. Um briefing não precisa de browser, terminal ou delegação. Toda ferramenta que você deixa de fora é um schema pelo qual o modelo não paga em toda chamada.

Deixe o preflight falhar alto. Antes de uma execução, o Hermes confere se a chave do provider resolve, as skills anexadas estão prontas, o destino de entrega está configurado, e todo servidor MCP que o job nomeia de fato conectou. Se algum nunca conectou, o job é marcado como blocked_config, você recebe um alerta, e nenhuma chamada de modelo acontece. Um briefing quebrado não custa nada e te diz por quê.

Deixe o briefing responder. As entregas são fire-and-forget por padrão: você responde uma e o agente não tem ideia do que ele disse. Ligue as entregas continuáveis (cron.mirror_delivery, ou por job) e cada briefing abre a própria thread, com o briefing como contexto, então “me conta mais sobre o item três” funciona.

Separe coleta de escrita quando crescer. context_from alimenta o output do último job no prompt de outro. Um coletor pode rodar primeiro e um escritor pode rodar depois, cada um com as próprias ferramentas e modelo.

Esse aviso vem de uma lição anterior: o agente é um narrador não confiável, e o log de execução é a verdade no terreno.

Acesso de leitura, nunca uma voz

A regra de design mais importante para um job como esse: ele lê, e nunca fala por você. Conecte toda fonte só com acesso de leitura. A única coisa que o job deveria produzir é uma mensagem para você.

Dar escopo a cada fonte é um trabalho próprio: servidor MCP do Slack e MCP do Google Workspace cobrem as duas de maior sinal, e Hermes Agent e MCP cobre conectar qualquer servidor ao Hermes.

Um agente que consegue postar no Slack, comentar num merge request ou responder um e-mail em seu nome é um produto diferente, com um risco diferente. Pode ser útil. Não deveria ser a primeira coisa que você constrói, e nunca deveria vir empacotado com um job cujo propósito é ler tudo.

Antes de agendar um briefing

• ✓Obrigatório:
  Toda fonte MCP está conectada só com acesso de leitura.Se um servidor não pode ter o escopo limitado a leitura, não dê ele para um job agendado.
• ✓Obrigatório:
  O método vive numa skill, não no prompt do cron.Uma execução de cron começa do zero. Um prompt de uma linha mais uma skill é mais fácil de versionar e revisar que uma página de prompt.
• ✓Obrigatório:
  Seu contexto é algo que o agente lê, não algo que ele escreve.Aponte o workdir do job para um vault curado. Mantenha o output diário do agente fora dele.
• ✓Obrigatório:
  As ferramentas do job estão fixadas no que ele lê.Nenhum browser, nenhum terminal, nenhuma delegação para um briefing.
• ✓Obrigatório:
  O briefing diz quais fontes falharam.Um dia quieto e um conector quebrado parecem idênticos a menos que o formato force a diferença.
• ✓Obrigatório:
  Ele entrega só para você.Um briefing sobre uma empresa é sensível por padrão. Um destinatário, um canal.

Agente de briefing diário, respostas rápidas

O que é um AI chief of staff?+

Um agente agendado que lê onde o seu trabalho acontece, sabe o suficiente sobre você para separar o que importa, e te entrega um briefing curto num formato fixo. É um padrão, não um produto. Você constrói o seu com qualquer agent runtime que roda numa agenda e conecta a servidores MCP, como o Hermes Agent.

O que é MCP?+

MCP (Model Context Protocol) é o protocolo que deixa um agente de IA conectar a ferramentas e fontes de dado externas, como Slack, Google Workspace, Git ou Jira, por uma interface comum, em vez de uma integração sob medida para cada uma. Um servidor MCP expõe esses dados e ações como ferramentas que o agente pode chamar.

O Hermes Agent consegue ler Slack, Gmail e Jira?+

Sim, por servidores MCP. O Hermes é um client de MCP, então qualquer servidor MCP de Slack, Google Workspace, Git ou Atlassian que você configurar se torna um conjunto de ferramentas que um job pode chamar. Use acesso só leitura para qualquer coisa que um job agendado toca.

Um cron job do Hermes lembra do briefing de ontem?+

Não. Toda execução é uma sessão nova sem memória de execuções anteriores.

Se você precisa de continuidade, encadeie jobs com context_from, mantenha estado num arquivo que o job lê, ou ligue as entregas continuáveis para conseguir responder um briefing com ele no contexto.

Como eu evito que um agente agendado poste em meu nome?+

Dê às fontes dele acesso só leitura, fixe as ferramentas do job nos servidores MCP que ele lê, e entregue o resultado só para você mesmo. O Hermes entrega a resposta final do job, então o agente nunca precisa de uma ferramenta que manda mensagem.

Quanto custa rodar um briefing diário?+

Depende de quantas ferramentas o job carrega e de qual modelo ele roda. Fixar os toolsets do job mantém schemas de ferramentas não usadas fora de toda chamada, e um modelo fixado por job deixa o briefing rodar num modelo mais barato que as suas sessões interativas.

Um job cujas fontes falham no preflight não faz chamada de modelo nenhuma.