Case study: a morning brief that reads only
A walkthrough of Executive Daily Briefing, the read-only shape: three apps, no write access anywhere, and why that makes it the right first worker.
The two earlier walkthroughs, support triage and inbound leads, both hold Write access. This one holds none, and that makes it the best first worker to deploy.
As before, this is an implementation walkthrough rather than a customer story. No invented companies, no invented hours-saved figures. Every number is from /pricing or arithmetic you can check.
The job
Executive Daily Briefing's own job sentence: *delivers a prioritized morning brief of your day: meetings, urgent email, blockers, and team chatter.*
It is a good first worker for a reason that has nothing to do with the output being useful, though it is. It is the shape where the worst case is smallest.
Read-only changes the risk conversation
| This worker | A worker with Write | |
|---|---|---|
| Worst case of a bad run | A misleading brief you read and discount | An email a customer received |
| Reversible | Nothing happened to reverse | Sometimes not |
| Contact policy needed | None, it contacts nobody | Yes |
| Redaction relevant | For what reaches the model | For that, plus what it writes back |
| Confidence needed before deploying | Low | Earned over weeks |
That first row is the whole argument. A read-only worker's failure mode is **a document you disagree with**, which you notice immediately because you are the reader. There is no silent tail, no third party affected, nothing to unpick.
Deploy this before you deploy anything that writes. It teaches you how a worker behaves on your data at close to zero risk.
The loadout
| App | Level | Why |
|---|---|---|
| Calendar | Read | The day's meetings |
| Read | What is urgent and unanswered | |
| Tasks | Read | Blockers and what is due |
Three apps, all Read, nothing else. It cannot send, book, file or change anything. The app firewall makes that a property of the worker rather than a promise in its instruction.
Worth noting for the plan limits: on a Google or Microsoft account, calendar, email and tasks come from one connected account, not three. Free allows one email account, so this worker fits without touching that ceiling.
The kit also leaves an open slot for team collaboration, so it can pick up team chatter where you connect it, and works without it.
The schedule
Once each morning, early enough to be waiting when you start.
| Option | Verdict |
|---|---|
| Once, 6:30am | The job. It is a morning brief |
| Twice daily | A different product: a digest, not a brief |
| Hourly | Pointless. The day's shape does not change hourly |
| Event-driven | No event exists. "It is morning" is a clock |
This is the clearest case in the directory for a schedule over a webhook trigger: there is genuinely nothing to subscribe to. The trigger is the time.
Schedules run wall-clock in your own time zone, so 6:30 stays 6:30 through daylight saving rather than arriving at 5:30 for half the year. Free allows one schedule per worker, hourly or daily, which is exactly what this needs.
What it costs
Roughly 15 tool calls a run: list the day's events, scan recent mail, read a handful of threads, pull open tasks.
| Cadence | Tool calls a day | Share of Free's 500 |
|---|---|---|
| Once each morning | ~15 | 3% |
| Plus an evening version | ~30 | 6% |
Three percent. This worker is effectively free in capacity terms, which is worth stating plainly because "AI agent" and "cheap" are rarely used together. Model tokens bill separately at the provider's list price with no markup, from the wallet or your own key, and depend mostly on how much mail it reads.
Judging the output
The receipt matters differently here. For a writing worker you read receipts to check what it did to the world. For this one the brief is the output, so you are judging quality rather than safety.
The questions worth asking in week one:
- Did it surface the thing that actually mattered, or the thing that was loudest?
- Did it call something urgent that was not?
- Did it miss a thread because the subject line was misleading?
Each of those is a line for the instruction. This is the cheapest possible place to learn how to write one, because being wrong costs you a paragraph you ignore.
Where it should stop
- It should not book anything. The moment it holds Write on the calendar it is a different worker with a different risk profile. Keep them separate.
- It should not decide what is urgent for other people. A brief is for its reader.
- It should not be your only view of the day. A worker that quietly stops running is a worker whose absence you might not notice, which is why the receipt exists.
- It is not an inbox replacement. It tells you what to look at. It does not handle anything.
The reasonable objection
"A summary of things I could read myself, that might be wrong, is not obviously worth the setup."
Fair, and the honest answer is that the value is proportional to how much you have. With twelve emails and two meetings, read them. The brief earns its place when scanning is itself the work, and the failure mode stays mild: a brief that misses something is a bad brief, not a bad outcome, because you still have the inbox.
The stronger argument for deploying it is the second-order one. It is the lowest stakes way to find out whether workers behave sensibly on your data before you give one Write access to anything.
The fleet it starts
Read-only first, then writers once you trust the pattern:
| Worker | Apps | Level | Order |
|---|---|---|---|
| Executive Daily Briefing | calendar, email, tasks | Read | First |
| Engineering Pulse | github | Read | Also safe to start |
| Follow-Up Tracker | email, tasks | Write | Once you trust it |
| Support Inbox Triager | email, tasks | Write | Once you trust it |
Four workers, well inside Free's five and its 500 daily calls. See worker fleet for why several narrow workers beat one broad one.
FAQ
What is the safest first AI worker to deploy?
A read-only one. Executive Daily Briefing holds Read on calendar, email and tasks and can change nothing, so the worst case of a bad run is a brief you disagree with rather than something a customer received.
Does this worker need write access to anything?
No. It holds Read on three apps and nothing else, which the app firewall enforces as a property of the worker rather than as an instruction it might not follow.
How much of the free plan does a daily brief use?
About 15 tool calls a run, so roughly 3% of Free's 500 a day for a once-daily schedule. Model tokens bill separately at provider list price with no markup.
Why a schedule rather than a trigger for a morning brief?
Because there is no event to subscribe to. The trigger is the time, and the day's shape does not change hourly. Schedules run wall-clock in your own zone, so 6:30am stays 6:30am through daylight saving.
How do I make the brief better over time?
Read it for a week and note what it surfaced that did not matter and what it missed. Each of those is a line for the instruction, which is the cheapest place to learn instruction writing because being wrong costs you a paragraph you ignore.