The Briefing Agent
One command on Monday morning. The agent reads the week's calendar, pulls four KPIs from a spreadsheet, composes a briefing email, and leaves it sitting in Drafts, where it is not allowed to press Send. Ever.
Built in my home lab against a $6/month sandbox account and synthetic data. Work-flavored, never work data. Same as everything on this site.
The problem
Every Monday starts the same way: what's on the calendar this week, and where did last week's numbers land? The information exists. It's just spread across a calendar and a spreadsheet, and assembling it is fifteen minutes of clicking that never taught anyone anything. That's the exact shape of task an AI agent should own: repetitive, well-defined, and checkable.
THE LEASH
The agent does the work. The human keeps the Send button.
The one non-negotiable in the spec: the agent creates a draft, never a sent email. It's a small technical difference, one flag in the request, and the entire difference in trust. If the agent has a bad morning, the blast radius is a weird draft I delete, not a weird email my whole team read. When people ask where to start with AI agents, this is my answer: give it real work and keep the last irreversible step for yourself.
How it was built: tests first, trust later
I don't write code, so my quality bar has to live somewhere other than reading the code. It lives in tests. Before the agent was allowed to do anything, we wrote down eight questions it would have to answer, proved each one failed first (if a test can't fail, it isn't a test), then earned the greens one at a time. After every step, I personally eyeballed the output before the next step was allowed to start.
read calendar (this week) read spreadsheet (4 KPI cells)
\ /
compose HTML briefing
|
create DRAFT (never send)
|
read it back and verify: exactly oneThe receipts
Recreated from my build log with synthetic values. The real log stays on my machine, but this is faithfully what it proves.
| T1 | Can it reach the calendar at all? | GREEN |
| T2 | Does it pull the right week and convert time zones correctly? | GREEN |
| T3 | Can it find the ops spreadsheet in cloud storage? | GREEN |
| T4 | Does it read exactly the four KPI cells, nothing else? | GREEN |
| T5 | Does the briefing compose into clean, readable HTML? | GREEN |
| T6 | Does it create a DRAFT and provably never send? | GREEN |
| T7 | Read the draft back: is it the one we just wrote, and only one? | GREEN |
| T8 | One single command, end to end, all of the above. | GREEN |
Then the part I'm proudest of: the cold-verify run. The whole procedure was written up as a runbook, and a brand-new AI session (no memory of the build, no context, nothing but the runbook) executed it start to finish. It passed, and it even caught one documentation mistake, which is exactly what that run is for. If your process only works when the person who built it is driving, you don't have a process. You have a person.
The red ink
Full disclosure, because this site runs on it: early in the connector setup I fumbled a credential: pasted it across chat sessions while troubleshooting, which meant it had to be treated as burned. A later session caught it, we generated a fresh one, revoked the old one, and moved on. Two lessons came home with me: a credential that has touched a chat window is a credential you rotate, no debate; and the fix took five minutes, which is the strongest argument for just doing it. The mistakes are part of the build. That's why they're on the page.
Steal this pattern
You don't need my agent. You need the shape of it. Pick one recurring chore that ends in a message or a report. Write down the checks that would convince a skeptic it worked, and make the AI prove each one fails before it passes. Keep the final irreversible step (send, submit, publish) human. And when it all works, have a fresh AI session re-run everything from your written instructions alone. If it can't, the instructions aren't done.
New to this? Start at the shallow end: the five sentences you already know. Already comfortable? See what happens when I stop building and start grading: three models, one judge.