Email looks like an obvious automation target. In practice, it contains ambiguous requests, commercial commitments, sensitive information and messages where tone matters as much as factual correctness.
The goal was therefore not to create an autonomous inbox. It was to reduce repetitive work without allowing a model to make unreviewed commitments on my behalf.
The workflow
The system separates several different jobs that are often blurred together:
- detect and classify incoming work
- gather the minimum relevant context
- decide whether the item needs attention
- prepare a suggested response or operational next step
- retain the result as a draft when external communication requires review
- record the workflow state so failures can be seen and recovered
The draft is the product of the automation. Sending it is a separate action.
Technology used
- n8n for workflow orchestration, retries and scheduled recovery checks.
- Gmail Pub/Sub and the Gmail API for event-driven intake, thread context and draft creation.
- Cloudflare Workers and Workers AI for public event handling and first-pass classification.
- Webhooks and explicit queue states for reliable hand-offs between services.
- The Notion API for operational logging and approval records.
- Python and bounded command-line tools for the actions that need deterministic validation.
- AI model services for classification, summarisation and draft preparation.
The technology is deliberately split by responsibility. n8n coordinates the workflow, APIs provide controlled access to each service, and models handle language tasks without receiving unrestricted authority.
Why the boundary matters
A model can produce a well-written response while still misunderstanding the commercial position, promising work that has not been approved or using context that is no longer current.
The workflow therefore treats human approval as part of the system design, not as an inconvenience added afterwards. It keeps a clear distinction between:
- received and understood
- prepared for review
- approved for action
- completed and verified
- failed or requiring recovery
Reliability work
The useful engineering is mostly around the failure path. The workflow needs to cope with delayed triggers, unavailable model services, incomplete context and work that stops between drafting and completion.
The system uses explicit states, backstop checks and recovery handling so an error does not silently become a sent message or a forgotten request. Verification checks the resulting draft or action rather than trusting a generic success response.
My role and the AI contribution
I selected the workflow, defined the approval boundary, decided what evidence was required and tested the operational behaviour. AI assisted with implementation as well as classification, summarisation and draft preparation.
That division is important. The model contributes speed and language capability. I retain responsibility for the process, permissions, safeguards and result.
What this project demonstrates
This is evidence of a live AI-assisted operational workflow with human approval, traceable state and recovery behaviour. It demonstrates practical use of models inside a wider system rather than isolated prompting.
A defensible time-saving measure has not yet been published. Until that is measured properly, the claim is operational usefulness and control, not a made-up productivity percentage.
What is deliberately not published
No mailbox addresses, message content, client information, authentication material, internal endpoints, queue identifiers or exact security configuration are included here.