AI Email Context

Contacts Database

One record per person, with communication history, contact type, and relationship notes.

Tone Profile

A written style guide the AI reads before drafting, not a set of rules but a description of how I actually write.

Decision Log

A structured record of key decisions across projects, so the AI can reference what was agreed without me restating it.

Email Examples

Real sent emails used as style reference.

Skill Log

A record of every draft generated, for audit trail and iteration.

Tone fidelity improved significantly with real context

Without the context layer, AI drafts were correct but generic. With the Notion-backed Tone Profile, drafts matched the actual voice: warm opener, bold section headers for multi-part messages, action-oriented close. The style guide works because it describes personality, not just formatting rules.

Contextual accuracy removed most of the editing work

Without project context, AI drafts are vague and require heavy editing to be usable. With the Decision Log and Contact Notes, drafts referenced the right project names, recent decisions, and relationship context — without me restating any of it. External first-user testing produced drafts requiring minimal editing, before any calibration period.

The first real bug: silent data loss at the retrieval layer

During the scheduled morning scan, the system used a semantic search query to fetch active contacts from Notion. It returned 10 of 18 contacts — silently, with no error. Eight contacts were simply excluded from the scan, including several active clients.

This is a platform limitation in Notion’s search API, not a logic error. The fix required replacing semantic search with a direct database fetch, adding count verification, and building a fallback protocol. The new approach consistently retrieves all 18 contacts and logs the result.

The broader lesson: for any AI system that depends on retrieval, silent partial retrieval is a critical failure mode. It doesn’t break loudly — it just quietly misses things.

External testing surfaced setup UX gaps — and confirmed the system is resilient

A colleague installed the system from scratch and ran it across several days, including intentional stress tests. The functionality held up well, but early runs surfaced real setup gaps:

• The “always run” permission prompts weren’t clearly flagged as something the user needed to approve during setup. A guided test run step was added so users see and approve these prompts before enabling scheduled tasks.
• The task monitor sidebar is collapsed by default. Added an explicit step to open it during setup so users can see what’s running.
• Gmail drafts weren’t landing in the correct thread — a threading bug where the draft was created without passing the thread identifier. Fixed and verified in the smoke test checklist.
• The [VERIFY: ...] tags weren’t prominent enough — these are flags for human review, and they need to be visible enough that the user actually sees them before sending.

The stress test that stood out: the Gmail connector was intentionally disconnected before a morning run to see what would happen. The system didn’t fail silently. It notified via the briefing that Gmail was unavailable, still produced two draft responses from partial inbox access, surfaced them in the briefing for copy/paste review, and flagged connector errors for attention.

The briefing also proactively flagged an unknown sender as someone worth adding to the Contacts DB — a small detail, but it shows the system doing useful triage beyond just drafting replies.

This feedback round accelerated quality significantly. Day-one external install going from “works but confusing” to “smooth” in a single iteration — and then holding up to intentional failure testing — is a meaningful signal.

Token efficiency required deliberate design

The more interesting signal came from continued testing. After switching from Opus to Sonnet, token usage dropped from ~25% of the Pro plan’s 5-hour window on day one to ~16% on day two, and ~9% by day three — without any change in output quality. Model selection turns out to be meaningful configuration, not just a preference.

The initial version loaded all context for every mode regardless of whether the mode needed it. A briefing run was consuming as much context as a full draft run.

Mode-aware optimization brought briefing mode from approximately 3,000-5,000 tokens down to 800-1,500. A further optimization — caching active contacts in a single reference page rather than fetching individual records — reduced the contact retrieval step from multiple round-trips to one fetch. Time-bounded queries eliminated repeated processing of already-reviewed emails.

System stability required staggering scheduled tasks

Running the morning briefing and inbox scan as a single chained task caused the app to freeze when connectors were slow on startup. The fix: stagger them 30 minutes apart. Each runs independently and releases connector resources before the next begins.

Connector latency on cold starts is a genuine failure mode for production scheduled AI agents, not an edge case.