Context
The web operation I now own began inside Red Graphic around 20 years ago. I worked within it for much of my career, then took ownership in 2023. Today the business serves around 200 clients and combines project delivery, hosting, maintenance, support, marketing and administration.
That history matters. This was not a clean-sheet software project. The task was to improve a working business without losing the relationships, judgement and controls that make it dependable.
The challenge
Client work arrives through multiple inboxes and systems. A single message may contain an unclear request, a commercial implication, a technical problem and a tone-sensitive relationship decision.
It is tempting to treat email as a summarisation problem. It is actually an operating-model problem. The system needs to know what evidence to gather, what it can do safely, where it must stop and how a person can understand what happened.
My role
I designed the operating model, selected the systems, defined the permission and approval boundaries, and directed implementation using developers and AI.
My responsibility was not to produce every line of code. It was to decide what a useful and safe system should do, translate that into bounded workflows, test the real behaviour and keep humans accountable for consequential actions.
The system
The live email path combines Gmail Pub/Sub, Cloudflare Workers AI, explicit D1 queue states, APIs, webhooks, n8n, Notion records and human-reviewed Gmail drafts.
The workflow:
- Receives an event from one of two business Gmail accounts.
- Classifies the item and records its state.
- Gathers the minimum relevant context through read-only investigation.
- Prepares an unsent draft or a proposed operational next step.
- Routes the result to a person for review.
- Records the decision and verifies any bounded follow-up action.
A lock-guarded recovery sweep checks for work missed by the primary trigger after three minutes. This was added after investigating a real missed-webhook incident, not as theoretical architecture.
Related workflows prepare draft Xero invoices from approved time records, assemble maintenance evidence, generate human-reviewed content proposals and route code changes through draft pull requests.
Product decisions
Several decisions define the system more than the model choice:
- A draft is an output. Sending is a separate, human action.
- Investigation is read-only unless a later step has explicit authority.
- Queue states and errors remain visible rather than disappearing inside a model response.
- The primary event path has a bounded recovery mechanism.
- Financial changes stop at a draft.
- Code changes stop at a reviewable pull request.
- Public content stops at an approval queue.
These boundaries allow AI to contribute speed and context without pretending uncertainty has disappeared.
Outcome
The business now has live event-driven processing across two business mailboxes. Incoming work can be classified, investigated and converted into a useful unsent draft with traceable state and recovery behaviour.
The broader result is a repeatable pattern for introducing AI into operations: connect it to real evidence, limit its authority, make failure visible and keep a person responsible for the decision.
Evidence and limits
No time-saving percentage is published because it has not been measured defensibly. The system does not autonomously send client email, approve invoices, merge code, publish content or deploy changes.
The claim is narrower and stronger: this is a live human-in-the-loop operating system, designed around real business risk rather than a demonstration prompt.