The fifteen-minute agent

One command. The agent reads my week's calendar and four KPIs from a spreadsheet, writes a briefing email, and leaves it in Drafts. It never sends.

Timeline: all dates from timestamped test logs. Plan written May 12, 2026. Built May 13 — pre-flight at 9:37, all eight tests green by 9:50, runbook captured by 9:52. About fifteen minutes of build. Cold-verified the same morning; re-run in production against live data May 14. The three weeks of pain that made fifteen minutes possible belong to the Lokka story.

What it is

A Monday-morning briefing agent: on "Run Monday briefing," it pulls the coming week's calendar events, reads four operational numbers from a spreadsheet in OneDrive, composes a formatted email, and creates a draft in Outlook. I review and hit send myself. That last rule is load-bearing: an agent that drafts is useful; an agent that sends is a risk.

Why I built it

It's the most universally applicable assistant pattern I know — calendar + numbers + email is the shape of a weekly ops report, a daily sales summary, a board-prep packet. It was also deliberately a discipline exercise: the second full test-driven build, reusing the red-to-green protocol from the Lokka migration. Eight tests, written before any building: can it reach the calendar, parse events, find the file, read the cells in one call, compose the body, create a draft (not send), read the draft back, and do all of it from a single command.

The walls

1. I almost built it in the wrong room. The session that first reviewed the plan was configured for a completely different project — one aimed at Gmail, while this plan targets Microsoft 365 — and didn't have the right working folder. Instead of pushing ahead, that session closed itself out and produced a "restart kit": a self-contained kickoff prompt for a fresh session pointed at the right folder. The build session then ran clean. Lesson: where you start a session matters as much as what you ask for.

2. The day before, we'd "proven" something false. The May 12 log concluded the tooling couldn't create an Excel file (its API takes JSON, not raw file bytes). The plan therefore told me to make the spreadsheet by hand in the browser. During pre-work we tested the impossible thing anyway — and found a path: create an empty file through the API, and the first workbook call materializes it into a real spreadsheet. Sheet renamed, all ten cells written in one call. The log entry literally says "supersedes yesterday's conclusion." Conclusions from failed attempts deserve re-testing from a different angle.

3. "This week" is a definition problem, not a code problem. I defined the week as a rolling seven days from today. Running mid-week, that window caught only three of the five test events — Thursday and Friday fell outside. Nothing was broken; my definition and my expectation disagreed. It got flagged in the log at pre-work time instead of discovered as a mystery later, and the runbook grew a Monday-to-Friday override option.

4. All tests green — and the documentation still had a bug. After the eight tests passed, we ran a cold verify: a session executing purely from the written runbook, no memory of the build. It reproduced the draft byte-for-byte — and caught a duplicate row in the runbook's config table that the passing tests never touched. The code was right; the document was wrong. Only running from the document found that.

5. The plan document itself contained noise. The plan file had a chunk of an earlier chat conversation accidentally embedded in the middle of it — an artifact of how it was assembled. The review session had to recognize it as noise and route around it. Documents generated from conversations need a proofread for exactly this.

Dead ends

Making the spreadsheet by hand (planned, then obsoleted by Wall 2). Building in the mismatched session (abandoned on purpose — its entire output became the handoff prompt instead). The build itself went red-to-green without a single failed attempt in the log; the groundwork had eaten the pain in advance.

What I'd do differently

Define "this week" as Monday-to-Friday from the start. And proofread machine-assembled plan documents before treating them as clean.

What carried forward

The runbook-as-agent pattern: the "agent" here is not code — it's a markdown procedure a fresh session can execute cold, which the cold-verify proved. That pattern shows up in everything I've built since. So did the small habits: paste-back checks before anything destructive, one range-read instead of four cell-reads, drafts-never-sends, and firing independent API calls in parallel. The next morning, the same discipline built the Attendance Dashboard — twice — before breakfast.