The tool gives you a starting point. The architecture is what you build on top.
Most AI assistants that offer voice personalization make you do the work manually — feed it samples, describe your style, iterate until it sounds close enough. The engram builder in Quick Desktop does something different: it reads your actual sent messages, clusters them by communication context, and produces a structured voice profile in one session.
I ran it. Here’s what came out, what it missed, and what I added to make it production-ready.
What the Builder Does
The native flow: authorize Slack and Outlook access, run the builder, wait. It fetches up to 500 of your sent Slack messages and 100 sent emails, filters out anything under 50 characters, analyzes the remainder for tone, sentence structure, vocabulary patterns, and communication habits, then calls save_engram with a structured JSON profile.
The output goes directly into the assistant configuration dropdown. Select the engram, and the assistant writes in your voice.
What it produces is genuinely useful. The style analysis runs to about 3,000 tokens — detailed enough to capture sentence length patterns, vocabulary preferences, how you open and close messages, and 30-50 representative verbatim samples. For most people, this is a significant upgrade over “be professional and concise.”
The gap: it produces one profile. One engram per person. The entire message corpus — DMs to close colleagues, emails to executives, customer-facing partner updates, published blog drafts — collapses into a single average.
The Problem with the Average
If you look at the messages that go into the builder, they span at least six distinct registers. A DM to a colleague you’ve worked with for years reads nothing like an endorsement request to a VP. A customer-facing partner update reads nothing like a technical handoff spec. The only thing they share is authorship.
Averaging them produces output that is recognizably shaped like you — the vocabulary is right, the sentence length is approximately right — but consistently wrong for the context. The casual register bleeds into leadership emails. The advisory posture from partner emails bleeds into deal-room Slack threads.
I noticed this in the first week of using the generated engram. The output was technically mine. The register was nobody’s.
What I Added: Six Modes
The fix is not a better extraction algorithm. It is separating the corpus before analysis.
I ran the builder’s analysis manually against mode-specific message sets — messages to close colleagues only, messages to executives only, external partner emails only, published drafts only, technical handoff tasks only. Six analyses instead of one. Six profiles instead of one average.
Each profile ended up structurally different:
The casual mode uses fragments. Short sentences. Jumps topics mid-message. The representative samples look like: “Ahh ok”, “Via Prime?”, “What about LinkedIn and Twitter login?” — not because the writing is bad, but because that register lives in rapid-fire back-and-forth where fragments are correct.
The leadership mode is almost the opposite: direct ask in the first two sentences, specific shared history named (not generic “we’ve worked together”), no opt-out language in the close. Every sample is a complete, structured message.
The publishing mode has the longest sentences, the most evidence citations, the strongest opinions stated flatly. No hedging. No credential framing. Universal opener (“If you work in…”) rather than personal (“In my experience as…”).
The gap between casual and publishing is wider than the gap between any two people’s single engrams. The single-profile builder produced something between them — which means it was wrong for both.
What the Profiles Actually Contain
The native builder produces style_summary and writing_samples. Those are necessary. They are not sufficient.
After running the per-mode analysis I added three more fields to each profile:
never_say — a flat list of phrases banned in this mode. This is the highest-signal addition. “I hope this note finds you well” is banned in casual mode — wrong register entirely for a DM to a close colleague. “In my role as…” is banned in publishing mode — credential framing when universal framing is needed. “Either way, no worries if not” is banned in leadership mode — hedging a close signals lack of confidence in the ask. Each of these is a decision, not a pattern. The native builder captures patterns. The never_say list captures decisions.
corrections — input/output substitution pairs. “leverage” → “use”. “comprehensive” → “[specify exactly what it covers]”. “seamless” → “[describe the actual setup steps]”. These came directly from real corrections: the profile produced a phrase, I rejected it, the rejection became a durable constraint.
quality_signals — hit/miss conditions the agent checks before returning output. Hit: opens with recipient’s context, not ours. Hit: at least one specific number in the first two sentences. Miss: “We at [company] believe…” Miss: close is “let me know if…” rather than a concrete next action. The self-check runs before every output — not as a review prompt, but as a pre-flight before returning the draft.
Auto-Detection: The Other Half
Profiles alone are not enough. If the agent has six profiles and doesn’t know which to load, it defaults to the one you last used or asks you every time. Both are friction that kills adoption.
The fix is a config-driven detection system. A YAML file encodes a five-signal priority hierarchy:
- Explicit override — if I say “keep it casual” or “exec tone,” that wins
- Recipient override — per-person config (some people are always casual, always)
- Role mapping — looks up the recipient in a contacts registry, maps their relationship to me (peer, manager, customer, close colleague) to a mode
- Channel detection — Slack public channel → professional; email to external domain → field; blog draft → publishing
- Intent keywords — “tell him,” “ping” → casual; “endorse,” “promo” → leadership; “write a post” → publishing
Default: professional. The detection runs before a single word is written. The agent never asks which mode to use.
The native builder has none of this. Mode selection is manual — you choose the engram from the dropdown each time. That works at one session a day. At twenty parallel sessions across multiple tools, it breaks down.
The Pattern
Quick Desktop’s engram builder is a good starting point and a genuinely useful primitive. It does the extraction work — corpus gathering, clustering, initial analysis — that would take hours to do manually. Start there.
What you add on top is the architecture:
Split the corpus by context before analysis. Build six profiles instead of one. Add a never_say list to each — what you’d never say in that register is more distinctive than what you do say. Add corrections from real rejections — each one is higher signal than ten samples. Wire auto-detection so the right profile loads without manual selection.
The tool gives you a voice. The architecture gives you voices — the right one for the right context, consistently, at scale.
The next post in this series goes deeper on the never_say list: why anti-patterns are the fingerprint, and why corrections produce higher-fidelity calibration than any amount of sample analysis.