How to Automate a Morning Brief in Slack: Calendar, Tasks and Pipeline

To automate a morning brief in Slack, give Mio the sources to read, the period to cover, the sections to produce and the person who should receive it. Test one brief, then set the recurring schedule. A useful brief ends with a decision or next step, not a longer list of notifications.

Mio is a Slack-native AI employee that brings company context into team workflows. The daily-brief workflow can combine Slack activity, Google Calendar events, Linear issues and an Attio pipeline snapshot into a formatted message. You do not need every source on day one. Start with the ones that answer a question you already ask each morning.

Give each source one job

The same update can appear in a Slack thread, a ticket and a meeting invite. Assign a job to each source so the brief does not repeat the same work three times.

• Slack: recent decisions, requests and context from the channels you name.
• Google Calendar: today's meetings in your time zone, with preparation needs that the available context supports.
• Linear: assigned priorities, open items and their recorded status. A completed issue is not by itself proof of a production release.
• Attio, if connected: the stage and next step recorded on the selected pipeline list. A current snapshot is not a change since yesterday unless there is a previous value to compare.
• GitHub, if relevant: open reviews or merged work that needs attention. Keep merge status separate from deployment status.

For a company-wide view, use the broader company operating brief. A personal morning brief should stay narrower: what this recipient needs to understand or decide today.

A copy-paste morning-brief prompt

Replace the bracketed fields before using this prompt. Connect the tools you want Mio to read, and keep the initial destination private.

@mio prepare a morning brief for me in this DM. Read [Slack channels], today's Google Calendar events and [Linear projects or assigned issues]. If connected, include a snapshot of [Attio list]. Use [time zone]. Cover changes since [last brief or explicit start time], and label older context separately. Use five sections: what changed, what needs me today, calendar, pipeline snapshot, and open items. Link each item to its source where available. State which sources could not be read and any list limits. Do not infer a metric change without a comparable earlier value. Do not update records, send follow-ups or post to another destination.

This is a workflow template, not a promise that every connected tool contains the fields you need. If a deal has no next step or an issue has no owner, the brief should say that. Filling the gap with a plausible answer makes the brief less useful.

What the finished message should look like

Here is an illustrative structure with fictional work items. Replace the labels with links to your own records; these are not customer results.

• What changed: The release checklist has a new review request. Source: the original Slack thread.
• What needs me today: The billing issue needs a decision on scope. Source: the Linear issue; owner as recorded there.
• Calendar: A customer call is scheduled this afternoon. Review the open question in the account thread before joining.
• Pipeline snapshot: One proposal needs a recorded next step. This describes the current list, not a measured change from yesterday.
• Open items: A review is still pending. No confirmed deadline was found. Source: the pull request.

Keep a short source-status line at the bottom: what was read, what was unavailable, and whether a query returned only part of a list. A partial pipeline read should not become a statement about the whole business.

Check one brief before scheduling it

Open a source link from each section. Check that the date window is right, the owner is real, and a request has not been presented as a commitment. Compare a calendar item with the original event and a task status with Linear. If the brief includes a count, confirm the filters and whether all relevant records were read.

Then ask Mio to turn the reviewed brief into a recurring job: Run this brief every weekday at [time] in [time zone]. Send a formatted message only to my DM. Keep the same sources and sections. State source failures in the message. Do not create a canvas, change records or contact anyone else. Confirm that the saved job's audience and destination match the instruction before relying on the schedule.

Start with a normal Slack message. A canvas is a different delivery format and should be tested separately. If you later want a shared-channel brief, change and verify the saved destination explicitly; a DM workflow should not silently broaden its audience.

The recurring-workflow runbook covers the same setup questions for other jobs: what starts the work, which sources it reads, where the output goes, and what it must leave untouched.

Make the brief useful, not longer

After several runs, remove sections you do not use. If the pipeline never changes your morning decisions, move it to a weekly review. If one project drives your day, narrow the task section to that project. Use a weekly team update for the broader recap instead of repeating it every morning.

Judge the brief by whether you can choose your next action without reopening every tool. Reading and summarizing is the first job. Sending a follow-up, changing a task or contacting a customer is separate work that you should authorize separately.

Try Mio in Slack, connect the sources for one morning question, and test the DM brief before adding a schedule.