Editor's Note: When many people learn AI tools, they often start with model capabilities, Agent architectures, or complex automation concepts, which can easily intimidate ordinary users. This article offers a more accessible path: don't try to understand what AI is first, but start from a real daily work scenario—the morning briefing.
Taking Codex's "morning briefing" as an example, the author breaks down how ordinary people can step by step upgrade AI from a Q&A tool into a true assistant that participates in daily work. The first step is simply to connect it to Slack, Gmail, and Calendar, asking it what you need to pay attention to today; next, standardize output format and personal preferences through agents files; then further, set it to run automatically daily, split into threads by different projects, and even directly draft replies, meeting prep materials, and project memos.
The value of this tutorial is that it doesn't frame AI usage as an abstract methodology but breaks down complex capabilities into six actionable levels: from information summarization to preference crystallization; from periodic reminders to project management; from assisted judgment to long-term memory. Each level corresponds to a very specific action. Users don't need to understand what an Agent system is from the start to gradually appreciate AI's value in their real workflow.
For those who want to truly start using Codex, rather than just treating it as a chat window, this is a perfect first-step guide.
Below is the original text:
This is the simplest way I know to teach someone how to use AI.
Don't start by talking about models, Agents, or some abstract technical classification. Start with a work scenario people are already familiar with, and then quietly make it more powerful.
The "morning briefing" works because almost everyone already has a similar process, they just usually organize it poorly.
I believe the morning briefing is the first Codex workflow that ordinary people can genuinely understand.
You wake up, open Slack, glance at your calendar, click into your email, then forget why you opened the email; go back to Slack, and suddenly realize there's a meeting in seven minutes, and you have no idea what happened yesterday.
Its appeal is simple: help me remember what's actually happening right now.
When discussing onboarding new Codex users, this is the first workflow that is both mundane enough for teaching and useful enough to be taken seriously. It starts as a very simple directed prompt. But if you keep pushing it, it ultimately becomes a great model to help people truly transition to serious Codex use.
Start with something beginners can understand. Then add only one real capability at a time until the shape of the whole system becomes clear.
I think there are six genuine levels here.
Level 1: First, Find Out What You Actually Have Going On Today
The first version is so small it's almost embarrassing.
Connect Slack, Gmail, and Calendar, then ask: Using Slack, Gmail, and Calendar, tell me what I need to deal with today?
First, see if Codex can cross your three most common information entry points and tell you something you actually care about.
It might notice a Slack thread where someone is waiting for your reply; it might spot a meeting you forgot to prepare for; it might catch an email that changes the context for that meeting.
If it can make the first ten minutes of your morning a little clearer, it's already working.
Level 2: Add an Agents File
The second level is adding a bit of instruction that persists.
You already have enough raw information sources to make Codex useful. Now you need it to stop being vaguely "helpful" every morning.
This is where an agents file is useful. It's not some cold, infrastructure-level knowledge, but a place to specify "what you want this job to look like by default."
For the morning briefing, it might look like this:
You don't need to worry about where exactly to put this file. Just tell Codex:
I want you to save this to your agents file, so you can use it every time you prepare my morning briefing from now on.
Then paste the instructions above. The key is to define your preferences once, so every future briefing starts from that foundation.
You're not aiming to sound fancy. You just want tomorrow morning to be slightly less frustrating than today.
For other jobs, the instructions will differ. A recruiter might want grouping by candidate; an engineer might separate blocking issues from code reviews; a PR/communications person might split external info scans from internal to-dos. But the action is the same: give Codex real context first, then give it your default rules.
Level 3: Let It Keep an Eye Out for You
The third level adds periodicity, but I wouldn't teach it as "create an automated task."
I'd say: Every weekday morning, keep an eye on this for me.
That's the instruction people actually remember.
Under the hood, yes, you're turning the morning briefing into a periodic automated task. But in practical use, you're just saying: this is useful enough that I want it to come back on its own.
The unit of value is no longer "I remembered to ask." It's "the briefing is already waiting for me."
And because it lives in the same thread, you can keep refining it without rewriting the prompt from scratch every time. If it overemphasizes calendar events, tell it. If it consistently misses unclosed items in Slack, tell it. If it should separate "needs a reply," "needs preparation," and "worth knowing," teach it once, and let this thread carry your preferences forward.
That's also why I prefer the threaded version over some generic scheduled report. The morning briefing gets better with your complaints.
The periodic prompt can stay simple:
At this point, the morning briefing starts generating real value. You wake up, and something has already done the first round of information cleanup for you.
Level 4: Split It Into Multiple Project-Level Briefings
Eventually, one master briefing gets increasingly muddled.
This point came up very directly in conversation. I don't actually want a single universal daily assistant forever. Usually, I have multiple project threads, each giving me its own morning briefing.
One thread for a specific launch.
One thread for a project.
One thread for open-source matters.
One thread for personal affairs triage, like a chief of staff.
Each thread defines "important" differently.
A project thread cares about blockers, PRs, decisions, and whether a promised draft was actually completed.
A recruiting thread might care about candidate briefings for today's interviews and any background changes that emerged overnight.
A personal thread cares about messages, schedule arrangements, travel, and those low-intensity obligations that quietly sit in the background.
Here, the value of pinned threads becomes very obvious. A periodic morning briefing isn't just a report. It's a way to keep each project "warm" in its own fashion.
The prompt gets better because this thread already knows what you mean by "things related to the launch."
Level 5: Let the Briefing Directly Draft Follow-up Work
At this level, the morning briefing shouldn't just tell me what happened. It should also draft the obvious next steps.
Draft Slack replies, but don't send.
Compile candidate briefings.
Write meeting preparation notes.
Summarize the discussion thread I should read before replying.
Tell me which decision seems stuck with me.
A good Level 5 briefing might end like this: Here are the three messages I suggest you prioritize replying to. I've drafted replies for each. Here are two meetings worth preparing for. And here's one decision that seems stuck with you.
I want the morning briefing to do half the obvious work for me upfront, not just hand me another summary to read.
This is also the stage where I start using my phone more. If context gathering is already done before I open my laptop, I can glance at the briefing while moving around, approve a small thing, or just judge what's truly worth my attention once I sit down.
Level 6: Save Important Content Into a Memory Vault
The sixth level is when the morning briefing stops being just a morning ritual and starts feeding into a memory system.
If the morning briefing repeatedly spots the same people, the same projects, the same unclosed items, the same decisions, then some of that content shouldn't stay just in the thread. It should become persistent information.
Write down the important stuff.
Update project notes.
Record unclosed items.
Add decisions that shouldn't be forgotten.
Keep the context that will make next week's briefing better.
This is where I start using a vault. Simply put, I like making memory a set of files that can be viewed, compared, and reused across threads.
A minimal viable version looks roughly like this:
The structure is simple:
· TODO.md is to prevent unclosed items from disappearing into chat history.
· people/ stores persistent context about frequent collaborators.
· projects/ stores the status of important workflows.
· daily/ leaves a spot to record important facts for each day.
· notes/ stores more loosely structured research or one-off memos.
· AGENTS.md tells Codex how to use this vault, instead of reinventing the structure each time.
You should also update the agents file to have the morning briefing read the vault before output. Something like:
Once the briefing has enough structure, you can also have Codex use subagents for parallel searches. One can check for unfinished to-dos, one can scan project notes, another can look at recent person context, then the main thread assembles the real briefing and updates underlying documents when substantive changes occur. You don't need this on day one, but it becomes useful when the briefing involves enough moving parts, as single-threaded serial processing starts to feel slow, shallow, or not fresh enough.
You can also have Codex review the work you're already doing and ask you questions to help organize the vault better. It might spot the same person appearing in three projects, a project lacking clear notes, or your TODO.md mixing personal chores with launch blockers. This back-and-forth interaction is useful. When Codex is allowed to say, "I think this content needs a more appropriate home. Where should it go?" the vault gets better.
The morning briefing gets better because it can read the vault before running and update the vault after substantive changes. Tomorrow's project briefing can remember last week's pending decisions, that person who still needs a reply, or that status record that shouldn't vanish as the thread gets longer.
Why I Like This Ladder
Each level teaches the user a more serious way to use Codex, without requiring them to jump into some grand Agent architecture from the start.
Level 1 teaches you to use connectors.
Level 2 teaches you to set default rules via an agents file.
Level 3 teaches you periodic tasks via "keep an eye on this for me."
Level 4 teaches you to establish project-level briefings in persistent threads.
Level 5 teaches you the trust boundary I truly care about: draft work for me, but don't impersonate me.
Level 6 teaches you the part that truly compounds: save persistent context into a vault, making tomorrow's briefing smarter than today's.
That's why I use the morning briefing to teach Codex. It starts as a simple summary and ends up becoming a miniature work operating system.







