Daniel's been waiting for mainstream AI tools to actually send email, and ChatGPT's full Gmail support finally got there. Once you authorize the connection, it can summarize your inbox, tell you who's been in touch, send messages on your behalf, and pair that sending with finding email addresses. But here's what he's actually asking about. Sending is the part that matters to him. Summarizing and reading he's happy to do himself. The killer use case is outreach to prospective partners, business contacts, collaborators on a passion project, maybe even people for this podcast. The old problem was that the AI could find recipients and write subject lines, but the email itself read as oddly robotic and stilted. And then, as tends to happen, the tools went straight from refusing to touch the send button to being trigger-happy, skipping the drafting and review step entirely unless you explicitly tell them to stage a draft.
His core question is how to reliably instruct the tool on the type of message he wants. He writes direct emails. He hates the closer, shall we jump on a call to discuss this. He wants outreach that explains genuine interest without reading as spam or insincere. He uses voice-to-text, and he sees nothing insincere about drafting instructions and letting the AI handle subject lines, recipient lookup, and sentence breaks. His tactics so far have been writing a couple of emails he'd actually send, adding those to the system prompt, and using a dedicated email assistant. But that fights the emerging tendency toward one general assistant. You can't stuff all your formatting nuance into one giant system prompt without token bloat and inefficiency. Memory stores and graph backends are the alternatives. He found that a couple of targeted examples and a few guardrails dramatically improved reliability. His question is how to add examples and guardrails for different email types.
So the plumbing works. The question is why the emails it writes don't sound like him, and what to do about it.
Right. And I think before we get to the architecture question, which is really where Daniel's head is at, we should nail down what the integration actually does now and why the review step vanished so quickly.
The integration is useful in a way that the earlier versions weren't. After OAuth authorization, it's not just reading your inbox. It can summarize, identify who's contacted you recently, draft and send, and pair sending with email address lookup. That last piece is the one that makes cold outreach feasible at scale, because finding the right address was always a separate manual step. Now the model can do both in one pass.
And Daniel's point about sending being the real unlock rings true. Summarizing an inbox is a neat trick, but most people can scan their own email faster than they can prompt an AI to do it and then verify the summary is accurate. The bottleneck was never reading. It was the mechanical friction of composing, addressing, and sending at volume. That's where the efficiency gain lives.
Think about what the manual version of that workflow looks like. You're looking at a spreadsheet of potential contacts. You're searching for their email addresses one by one. You're writing each message, tweaking each subject line, checking each name for spelling. By the time you've sent ten emails, you've spent an afternoon. The AI collapses that into a single pass, but only if you trust it enough to let it.
And that trust is exactly where the review step matters. The review step gap is the part that worries me. These tools went from refusing to send anything to sending immediately, with no default staging of drafts. That's the same pattern we've seen with other agentic features. The capability ships first, and the guardrails that make it safe to use arrive later. For email specifically, the stakes are higher because a bad send carries your name and your reputation.
It's the same trajectory we saw with code generation. First the tools refused to write anything that could be executed. Then they wrote code that would run, but nobody reviewed it carefully because the output looked plausible. Then the bugs shipped. Email is the same thing, except the bug is a tone-deaf message sent to someone you actually want to impress.
And the central tension Daniel's pointing at is architectural. One general assistant versus many specialized ones. The token economics make a single giant system prompt inefficient. So the question becomes where the instructions live.
Let's dig into the robotic email problem first, because that's the thing Daniel keeps running into. It's structural, not a prompting failure. Base models are trained on averaged web text. Their default register is a bland professional-neutral that reads as stilted to anyone with a distinctive voice. Daniel's directness, his aversion to the jump on a call closer, those are exactly the kind of personal style markers that get smoothed away in training.
So when the model writes an email without examples, it's not trying to sound like Daniel. It's trying to sound like the average of every business email ever written. Which is why the default output has that hollow, committee-written quality.
And this is why examples beat instructions. If you tell the model be direct, that's underspecified. Direct compared to what? Direct in what way? But if you give it two emails Daniel would actually send, the model has concrete patterns to imitate. Sentence length, how he opens, how he signals genuine interest, how he closes. Examples are dense with information the model can pattern-match on.
It's like the difference between telling someone play jazz and handing them a recording of Miles Davis playing So What. The instruction tells them the genre. The example shows them the phrasing, the timing, the feel. The model learns more from two real emails than from a paragraph of abstract style guidance.
The jump on a call closer is a perfect example of what happens without pruning. It's a default trope. The model reaches for it because it's statistically common in business email, not because it fits Daniel's voice. A guardrail that says no shall we jump on a call, no hollow flattery, no spammy urgency, that prunes the default register.
And Daniel's observation that a couple of targeted examples and a few guardrails dramatically improved reliability suggests the failure mode is over-reliance on generic professional tropes. The model isn't bad at email. It's too good at writing the average email. The examples and guardrails pull it toward the specific.
There's an analogy to what happens when you ask a model to write a poem without examples. You get something that rhymes but says nothing. It hits the formal features of poetry without any of the actual poetic content. The same thing happens with email. Without examples, the model hits the formal features of business correspondence, the greeting, the body, the closer, without any of the actual content that makes a specific human want to respond.
Now the token economics. This is where it gets interesting. You can't write one huge system prompt covering calendar formatting, email tone, and everything else without burning tokens and degrading performance. The model's attention is finite. A sprawling prompt dilutes the signal from any one section.
Right. The more you stuff into the system prompt, the less weight any individual instruction carries. It's not just a cost problem. It's a reliability problem. The model starts to treat everything as equally important, which means nothing is important.
So the alternatives are dedicated assistants, one per task, which keep prompts tight but fragment the user experience. Or memory stores and graph backends, which let you retrieve relevant context on demand instead of stuffing it all into the prompt. Each has tradeoffs in setup cost, latency, and reliability.
And Daniel's voice-to-text preference is an interesting wrinkle on the input side. When he dictates instructions, the model receives messy, natural-language input that it has to interpret into structured email parameters. That's actually an advantage. It forces the model to extract intent rather than pattern-match on polished prompt syntax.
It's messier, but it's also more honest. The model has to figure out what he means, not just execute a template.
There's a parallel to how people actually talk to assistants in the real world. Nobody says, compose an email with a professional tone, a subject line under fifty characters, and a clear call to action. They say, tell this guy I liked his paper and I want to talk about it. The voice-to-text input is closer to how humans naturally communicate intent.
The dedicated assistant approach Daniel's been using fights the trend toward one general assistant. And I understand why the trend exists. Nobody wants to manage fifteen different assistants with fifteen different system prompts. But for high-stakes tasks like outreach, the tight prompt matters more than the convenience of consolidation.
It's the same logic as having a separate work email client and personal email client. The consolidation is convenient, but the separation prevents context bleed. Your work email doesn't need to know about your personal calendar, and your personal assistant doesn't need to know your outreach guardrails.
So what actually unlocks if we solve the tone problem? That's the next layer.
The scale argument is real. If AI-drafted outreach works reliably, job seekers and project pursuers can achieve the volume that makes outreach actually effective. The bottleneck was never willingness. It was the mechanical cost per email. If each email takes fifteen minutes to write, you send four a day. If it takes two minutes, you send thirty.
And the insincerity question is worth sitting with. Daniel argues there's nothing insincere about drafting instructions and letting AI handle mechanics. The counterargument is that recipients can often tell, and the reputational cost of AI-slop outreach falls on the sender.
That's a genuine tension. I don't think there's a clean resolution. If the email is good, it doesn't matter how it was written. If it's bad, it doesn't matter that it was written by a human. The question is whether the AI can produce good email reliably enough that the recipient's experience is indistinguishable from a thoughtful human note.
And the detection arms race is already starting. Gmail has spam and promotion classifiers. The next layer is plausibly AI-slop detection. As AI-drafted email becomes common, platforms and recipients will develop heuristics for spotting it. That changes the calculus for anyone using AI outreach at scale.
Check Point demonstrated that ChatGPT's Gmail integration can be manipulated into cross-account data access. That's a reminder that the same integration that enables convenient sending also expands the attack surface. Authorization is not the same as isolation. When you connect your Gmail to an AI tool, you're trusting that tool with a lot.
The architectural fork is where Daniel's question really bites. The industry is trending toward one general assistant with memory. But his experience suggests specialized assistants with tight prompts work better for high-stakes tasks like outreach. The resolution may be a hybrid, a general assistant that retrieves task-specific instruction sets from a memory store or graph backend rather than carrying them all in the system prompt.
That's the most interesting possibility. The general assistant stays general. But when it detects an email task, it pulls in the email instruction set, the examples, the guardrails, and applies them for that interaction. Then it puts them back. The context window stays clean, and the instructions stay specific.
It's like a chef who keeps a clean workstation but has a spice rack. When the dish calls for cumin, they reach for the cumin. They don't keep every spice on the cutting board at all times. The general assistant is the chef. The memory store is the spice rack.
This reframes the AI agent question. An email-drafting agent that stages drafts for review is a different product than one that sends autonomously. The review step is not a limitation. It's the feature that makes the tool trustworthy enough to use for outreach that carries your name.
The trigger-happy default is a phase. As the reputational cost of a bad send becomes clearer, users will demand the review step. The tools will follow.
There's a fun fact buried in the history here. The first email autoresponders were just templates with merge fields. You'd write, Dear [NAME], and the system would fill in the name. That was considered revolutionary in the nineties. But the template was always visible under the surface. The greeting was personal, but the body was obviously canned. Now the AI can write a body that isn't obviously canned, but the template is still there, just hidden in the model's training distribution.
If we can solve the tone problem, what does that actually unlock? It unlocks the ability to contact specific people at a volume that makes outreach statistically viable. Job seekers who can reach fifty hiring managers instead of five. Project pursuers who can pitch twenty collaborators instead of three.
The sincerity question doesn't go away. The mechanical layer is being solved. The strategic layer, knowing who to contact and why, is not. That's the part the AI can't do for you.
The examples Daniel wrote, the two emails he'd actually send, those encode his strategy. The model can imitate the form. But the model can't know why this particular recipient matters to him unless he tells it.
That's the thing about guardrails. They're not just about what to avoid. They're about what matters. No shall we jump on a call is a negative. But the positive is explain why you're actually interested. That's the guardrail that makes the email sincere.
Daniel's experiments showed that a couple of targeted examples and a few guardrails dramatically improved reliability. That's an empirical finding. It's not a theory. He tried it and it worked.
The question is how to scale that across different email types. A cold outreach to a potential podcast guest needs different examples than a follow-up to a business contact. The guardrails overlap, but the examples don't.
The answer to Daniel's question is probably not one system prompt. It's a retrieval architecture. Keep the examples and guardrails in a memory store or graph backend, organized by email type. When the assistant detects an outreach task, it pulls the relevant set.
The dedicated assistant approach he's been using is a reasonable stopgap. It's the manual version of retrieval. He switches to the email assistant when he's doing email, and that assistant has the examples and guardrails baked in.
The one general assistant trend is real, but it's not inevitable. The token economics push against it. The reliability evidence pushes against it. What's likely to emerge is a general assistant with retrieval capabilities, pulling task-specific instruction sets on demand.
That's the thing about AI attention. It's finite. A sprawling prompt dilutes the signal. But a focused prompt with the right examples and guardrails is dense with signal. That's what Daniel found empirically.
The practical recommendation is to organize the examples and guardrails by email type, store them somewhere retrievable, and let the assistant pull the relevant set when it detects the task. The system prompt stays lean.
The review step stays in place. Not because the tool can't send autonomously, but because the reputational cost of a bad send is high enough that you want to see it before it goes out.
The trigger-happy default is a phase. The review step will become the default, not because tools can't send, but because users will demand it.
Hilbert: You're right about the closer.
Hilbert: I wrote collections letters for a department store chain in the early nineties. My supervisor had a phrase he insisted every letter include. We value your business and look forward to resolving this matter together. I wrote that phrase thousands of times. I hated it by the end of the first week.
Hilbert: The letters that actually got paid were the ones where I broke the template and wrote something specific to the person's situation. You owe us four hundred dollars because you bought a dining set in March and stopped paying in June. Here's what happens next. That got a response. The template got ignored.
Hilbert: The model can imitate your style. But it can't know why this particular recipient matters to you unless you tell it. The examples are a start. The guardrails are a start. But the reason you're writing to this person, that has to come from you every time.
Hilbert: I still have the employee handbook from that job. There's a section titled Tone Friendly but Firm. It reads exactly like a system prompt written by a committee. Be courteous but direct. Express appreciation for the customer's business. Maintain a professional demeanor at all times. I got a written warning once for ending a letter with please just pay us.
The handbook is the default register. The model's default is the same thing. Courteous but direct, professional demeanor, all the hollow filler that nobody responds to.
The warning is what happens when you deviate from the template. But the deviation is what worked. The specific letter got paid. The template got ignored.
The question Daniel's really asking is whether the tool can know why this recipient matters. And that's not a prompting problem. That's a strategy problem. The examples and guardrails get you to a voice. They don't get you to a reason.
The reason has to come from him. Every time. The AI can handle the mechanics, the subject line, the sentence breaks, the address lookup. But the why, the genuine interest, the specific reason he's reaching out, that's the part he has to supply.
If he supplies it, the AI can shape it into his voice. If he doesn't, the AI will fill the gap with the default register. The hollow professional filler. The shall we jump on a call.
The review step is where he catches that. If the AI filled the gap with filler, he sees it before it goes out. He can add the specific reason. He can tell the AI to rewrite with the actual interest included.
The mechanical layer is being solved. The strategic layer is not. The value is shifting from the drafting itself to the judgment about who to contact and why.
That's the open question. As AI email drafting becomes reliable, does the value shift from the drafting to the judgment? The tool can write the email. But can it tell you who's worth writing to?
There's a version of this where the AI becomes a research partner, not just a drafting tool. It reads a potential collaborator's recent work, identifies what's interesting, and drafts an email that references the specific thing that caught your attention. But that requires the AI to know what you find interesting, which is another layer of examples and guardrails entirely.
Which brings us back to the architecture question. The more layers of context you need, the more important retrieval becomes. You can't stuff your entire intellectual biography into a system prompt. But you can store it in a graph backend and let the assistant pull the relevant interests when it's drafting outreach to a specific person.
The review step may become the default, not because tools can't send autonomously, but because the reputational cost of a bad send is high enough that users will demand it. The trigger-happy default is a phase, not an endpoint.
Thanks to our producer Hilbert Flumingtop for keeping the show running.
This has been My Weird Prompts, the human-AI collaboration podcast. If you enjoyed this episode, leave us a review wherever you listen. We'll be back soon.
