The day arrives already read
Nine systems are read, cross-referenced and written up as one briefing before the working day starts — and again before it ends, with every promise made in writing tracked in between.
Before
Nine systems, and the parts that mattered were the joins.
The information needed to start a working day was spread across nine systems, none of which talked to each other: calendar, inbox, task list, the ticket queue, the RMM, accounting, the utilisation dashboard, and so on. Getting a picture meant opening all of them and holding the result in your head.
The parts that mattered were the joins — a client with a breached SLA who is also sixty days overdue, a meeting this afternoon with the person whose ticket went unanswered. Nobody does those joins reliably at 7am. What actually happened is that the loudest system won: whatever was on the screen when you sat down set the agenda for the day. Promises made in email were tracked the same way — by remembering.
- 9
- separate systems consulted to assemble one day’s picture
- 2
- of them cross-referenced against each other
- 20 min
- per morning spent assembling it by hand
The first figure is a count of the sources the briefing now reads, each of which was previously checked by hand or not at all; the second follows from it. The third is Dean’s own estimate of the time it took him.
What we built
A briefing that is written, not assembled.
Twice a day a language model is handed live access to every system and asked to produce the actual briefing — so what arrives is prose that notices the join between an overdue invoice and this afternoon’s meeting, not a template with values dropped into it. A second pass reads the sent mail for commitments made in writing and tracks them until they are closed.
- 01
Nine systems, one page, 7:15am
Calendar, inbox and flagged senders, tasks, the ticket queue and SLA state, backup health, overdue receivables, utilisation, weather and health metrics — read live and written up as one briefing.
- 02
And again at the end of the day
What landed, what moved, and what is waiting for tomorrow.
- 03
Promises, tracked
Scans sent mail twice daily for commitments made in writing — across more than one mailbox — and tracks each until it is closed, plus the ones made to us that we are waiting on.
- 04
Unattended, and it writes the email itself
Runs on a schedule with no interactive step, and composes the message rather than filling a template.
- 05
A different briefing per role
The sales briefing carries meetings, replies waiting and follow-ups, and omits the operational sections entirely — because a briefing that includes things you cannot act on trains you to skim.
What it looks like in use
Both are reconstructions. A real brief quotes client email and carries receivable balances by name, so these are rebuilt rather than redacted.
What changed
The honest outcome here is qualitative.
The day starts from a considered picture instead of from whichever system shouted first. The numbers available — systems read, briefings sent — measure activity rather than change, and a rail of activity counts would be padding. So there isn’t one. What changed is that the joins get made by something that makes them every day, rather than by whoever remembered to look.
What didn't work first time
Four things we got wrong, in our own shop.
A briefing failed silently, apologised, and retried into the same wall
The system had a limit on how much it could produce in one response. When a briefing grew past it, the failure landed mid-way through composing the email: the partial output was unrecoverable, but the sentence it had written first — "building it right now" — survived and was recorded as though it were the finished answer. So the next turn showed a promise to act with no action behind it, and the system did the reasonable thing: apologised for getting sidetracked, and tried again. Into the same wall. Nothing appeared in any log, because from every component’s point of view nothing had failed. We raised the ceiling, made the truncation report itself out loud, and wrote a test that fails if any code path ever re-uses streamed text as an answer again.
A whole section went missing and looked exactly like "nothing to report"
The task list was being read from an interface that had been retired and answered with an error. The code caught the error and returned nothing — which renders as a briefing with no task section, byte-identical to a briefing for someone who has no tasks. It went unnoticed until the first person whose task list was not empty was enrolled. The same investigation found a second one: a filter passed to an interface that accepts the parameter and silently ignores it, so every filtered answer had been an arbitrary slice of the whole list wearing the filter’s name. Both returned success codes throughout. Counting rows against a filter that had to exclude something is what exposed it.
It inherited a rule that made no sense at 7:15am
The interactive assistant is instructed to read an email back for confirmation before sending it. Correct when a person is there. At 7:15am on a schedule there is nobody to confirm, so the briefing waited politely for approval that could not arrive. The scheduled path now overrides the rule rather than sharing a prompt written for a conversation.
We removed a section because it had finished being useful
The brief carried a training block for months. It served its purpose and then cost attention it no longer earned, so it is gone; the underlying data is still available on request. A briefing accumulates sections by default and nothing prunes them but a decision.
We run this on ourselves before we run it on you.
Nine systems is not an unusual number. The survey that found ours is the same four weeks we would run for you.