An Agent Reads Slack, Google, Git and Jira So I Get One Briefing a Day

At my day job, the work happens in five places at once. Slack threads, email and calendar, merge requests, Confluence pages, Jira tickets. Nobody reads all of it, and the person who tries spends the day reading instead of building.

So I stopped trying. A Hermes Agent cron job reads those sources once a day through MCP servers and writes me a briefing. It knows who is who and which projects matter because it reads my second brain first. It sorts what it finds by six senses instead of by tool. Its whole job is to read. The only thing it produces is one message, to me.

This is how that works, how to build your own, and the design choices that keep it a briefing instead of another noisy digest. I will not describe what my briefing says. That belongs to the company. The pattern belongs to anyone.

What an AI chief of staff actually is

An AI chief of staff is not a product you buy. It is a scheduled agent with three things: read access to where the work happens, your context so it can tell signal from volume, and a format it has to fill every time. Mine is a Hermes cron job. The same idea works with any agent runtime that can run on a schedule and talk to MCP servers.

The products sold under that name mostly do the first part: they connect to your tools and summarize. The summary is the easy part. Knowing what matters to you this week is the hard part, and it is the part that lives in your head, or, if you have one, in your second brain.

How the daily briefing works

One run of the briefing

Input

A Hermes cron job fires once a day

↓

1. CONTEXTRead the second brain

   Who is who, which projects are live, what I am responsible for. Read only. The job never writes to it.

   ↓
2. SENSERead the company through MCP

   Slack, Google Workspace, Git and Confluence/Jira, each through its MCP server.

   ↓
3. SORTFile it under six senses

   Not under the tool it came from. A Slack thread and a Jira ticket about the same thing land in the same place.

   ↓
4. WRITEOne briefing, same format every day

   What moved, what needs me, what is coming. The format is a skill, so the prompt stays short and the output stays comparable.

↓

Output

One message I read instead of five tools I skim

Two decisions in that pipeline do most of the work. The briefing is organized by senses, not by sources. And my context goes in before the company’s data does.

Six senses, not six tools

The tools are where the data lives. The senses are the questions. I use a framework of six senses that I first built to point agents at the market, and it carries over to a company almost one to one.

The six senses, as questions a daily briefing asks

Each sense can pull from several tools. Each tool feeds several senses.

Sense	The question
Self	What moved in the things I am already part of?
Them	What are other teams shipping or deciding that touches my work?
Trend	What is the company talking about more this week than last?
Frontier	What just became possible: a new tool, a new platform, a new release?
Community	What are people asking for, stuck on or complaining about?
Client	What do the people I serve need from me?

Sorting by tool gives you a Slack section, a Jira section and a Git section, and you still have to do the synthesis yourself. Sorting by sense does the synthesis for you. The merge request, the thread arguing about it and the ticket that asked for it end up as one item under the sense they answer.

An agent without a sensor is blind and guessing. The MCP server is the bridge from the sensor to the real data.

That line is the whole reason the briefing is built on MCP. The agent’s opinion of what happened at the company is worthless. Its reading of what the company actually wrote down is not.

Context is what turns a digest into a briefing

Point an agent at Slack with no context and it reports volume. The loudest channel wins. The thread with the most messages looks like the most important thing that happened.

My second brain fixes that. It is a markdown wiki I curate, with a page for each project I am involved in and notes from the meetings I am in. The briefing reads it before it reads anything else, so it knows that a two-message thread in a quiet channel matters more than a hundred messages somewhere I have no stake.

The job reads the wiki. It does not write to it. That is deliberate. The wiki is what I decided to keep. The briefing is the agent’s reading of one day. Letting a daily job write into my knowledge base would mix the two, and in a month I would not know which notes I wrote and which an agent guessed. The longer version of that boundary is in Hermes Agent and a second brain.

Digest

1. 01Organized by tool
2. 02Ranks by volume
3. 03Reports everything that happened
4. 04You do the synthesis
5. 05Skimmed, then ignored

Briefing

1. 01Organized by the questions you care about
2. 02Ranks by what touches your work
3. 03Reports what needs you
4. 04The agent does the synthesis
5. 05Read, because it is short and specific

How to build a daily briefing in Hermes

Hermes runs cron jobs from its gateway, which ticks the scheduler every 60 seconds. Each due job starts a fresh agent session, runs, and delivers its final answer to a target you choose. Jobs live in ~/.hermes/cron/jobs.json and each run’s output is saved under ~/.hermes/cron/output/.

Here is the shape of a briefing job. The names and paths are placeholders.

Schedule the briefing

1. Create the 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. Check the scheduler is alive

   $ hermes cron status

3. Run it once now, to see the first briefing

   $ hermes cron run daily-briefing

Every flag there is doing a job.

--skill carries the method. A cron run is a fresh session with no memory of yesterday, so the prompt has to be self-contained. Put the six senses, the format and the rules in a skill and the prompt stays one line.

--workdir is how your context gets in. By default a cron job loads no project context at all. With a working directory set, Hermes injects that directory’s AGENTS.md, CLAUDE.md or .cursorrules into the system prompt and runs its file tools from there. Point it at your second brain and the vault’s AGENTS.md becomes the job’s briefing on who you are.

--deliver decides where it lands: Telegram, Slack, email, a local file, or the chat you created it from. The agent does not send anything itself. Hermes delivers the final answer, and it redacts anything shaped like a credential on the way out.

--reasoning-effort pins the thinking level for this job only, so a daily synthesis can run at a higher effort than the rest of your fleet. You can pin the model per job the same way with --model and --provider.

A skeleton for the skill, to make the format concrete:

---
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.

The settings that keep it cheap and honest

Narrow the tools. A cron job gets the toolset you configured for the cron platform, and through the cronjob tool you can pin a job’s enabled_toolsets to exactly the MCP servers it reads. A briefing does not need a browser, a terminal or delegation. Every tool you leave out is a schema the model does not pay for on every call.

Let preflight fail loudly. Before a run, Hermes checks that the provider key resolves, the attached skills are ready, the delivery target is configured, and every MCP server the job names actually connected. If one never did, the job is marked blocked_config, you get one alert, and no model call is made. A broken briefing costs nothing and tells you why.

Make the briefing replyable. Deliveries are fire-and-forget by default: reply to one and the agent has no idea what it said. Turn on continuable deliveries (cron.mirror_delivery, or per job) and each briefing opens its own thread, seeded with the briefing, so “tell me more about item three” works.

Split collection from writing when it grows. context_from feeds one job’s last output into another job’s prompt. A collector can run first and a writer can run after it, each with its own tools and model.

That callout comes from an earlier lesson: the agent is an unreliable narrator, and the execution log is the ground truth.

Read access, never a voice

The most important design rule for a job like this: it reads, and it never speaks for you. Connect every source with read access only. The one thing the job should ever produce is a message to you.

Scoping each source is its own job: Slack MCP server and Google Workspace MCP cover the two highest-signal ones, and Hermes Agent and MCP covers wiring any server into Hermes.

An agent that can post in Slack, comment on a merge request or reply to an email on your behalf is a different product with a different risk. It can be useful. It should not be the first thing you build, and it should never be bundled with a job whose purpose is to read everything.

Before you schedule a briefing

• ✓Required:
  Every MCP source is connected with read-only access.If a server cannot be scoped to read, do not give it to a scheduled job.
• ✓Required:
  The method lives in a skill, not in the cron prompt.A cron run starts fresh. A one-line prompt plus a skill is easier to version and review than a page of prompt.
• ✓Required:
  Your context is something the agent reads, not something it writes.Point the job's workdir at a curated vault. Keep the agent's daily output out of it.
• ✓Required:
  The job's tools are pinned to what it reads.No browser, no terminal, no delegation for a briefing.
• ✓Required:
  The briefing says which sources failed.A quiet day and a broken connector look identical unless the format forces the difference.
• ✓Required:
  It delivers only to you.A briefing about a company is sensitive by default. One recipient, one channel.

Daily briefing agent, quick answers

What is an AI chief of staff?+

A scheduled agent that reads where your work happens, knows enough about you to tell what matters, and hands you a short briefing in a fixed format. It is a pattern, not a product. You can build one with any agent runtime that runs on a schedule and connects to MCP servers, such as Hermes Agent.

Can Hermes Agent read Slack, Gmail and Jira?+

Yes, through MCP servers. Hermes is an MCP client, so any Slack, Google Workspace, Git or Atlassian MCP server you configure becomes a set of tools a job can call. Use read-only access for anything a scheduled job touches.

Does a Hermes cron job remember yesterday's briefing?+

No. Each run is a fresh session with no memory of previous runs.

If you need continuity, chain jobs with context_from, keep state in a file the job reads, or turn on continuable deliveries so you can reply to a briefing with it in context.

How do I keep a scheduled agent from posting on my behalf?+

Give its sources read-only access, pin the job's tools to the MCP servers it reads, and deliver the result only to yourself. Hermes delivers the final answer for the job, so the agent never needs a tool that sends messages.

What does a daily briefing cost to run?+

It depends on how many tools the job carries and which model it runs. Pinning the job's toolsets keeps unused tool schemas out of every call, and a per-job model pin lets the briefing run on a cheaper model than your interactive sessions.

A job whose sources fail preflight makes no model call at all.