The 3-Hour AI Email Assistant That Sold for $1,650

Three hours of work. A $1,650 invoice. A business owner who paid without hesitation. The story behind this project is not about a clever workflow canvas or an impressive node count. It is about one conversation that turned an enormous, vague ask into a single solvable problem, and why that narrowing is the skill behind the fee.

I am Madhuranjan Kumar. I want to walk through this build in the order it actually happened, because the sequence matters more than the technical components.

The conversation that turned an executive assistant request into one inbox

The client came in wanting a full executive assistant. That phrase is the widest net a potential client can cast. It encompasses calendar management, meeting prep, research queues, follow-up sequences, project tracking, and communication drafting across every channel the business uses. Building all of that in one pass is not a project scope; it is a product roadmap spanning months of work. The correct response to a request that broad is not a price quote. It is a question.

The question that changed everything was direct: if you had a capable assistant sitting next to you starting tomorrow morning, what is the first thing you would hand them? The answer came immediately. Email. The inbox was where the day started going sideways before anything else could happen. The owner was spending close to an hour every morning sorting messages, deciding which ones needed attention today versus next week, and then drafting responses to the ones that could not wait. By the time that sorting hour ended, the real work of the day had not yet started.

That is a defined problem with a clear before-and-after. It is one slice of the full executive assistant vision, but it is a slice that causes real, daily, measurable pain. Solving it delivers a result the owner feels the next morning and every morning after. Scoping down to this one problem is not a concession to a smaller budget. It is a diagnosis. A doctor seeing a patient with a headache does not prescribe the full formulary. They identify the specific source of the pain and prescribe the targeted solution. That posture is what turns a workflow builder into a consultant who earns premium fees, because the client is not paying for hours of node dragging. He is paying for the diagnosis that found the right problem and the build that solved it cleanly.

The project fee covered the discovery conversation, the design of the system, the build itself, testing against real messages, and a clean handoff. The client did not hesitate when he heard the price. He could see exactly what he was buying before a single automation ran.

The phrase "act like a doctor, not a pharmacist" is the most useful frame I have found for explaining this to builders who are new to selling AI work. A pharmacist hands over whatever is requested. A doctor finds out what is actually wrong and prescribes what will fix it. Clients instinctively know which one they are working with, and they pay accordingly.

Fifty emails, a style guide, and a two-agent split

The system has two distinct parts. The first is an inbox router that labels incoming messages and logs metadata to a shared spreadsheet. It is mostly deterministic, sorting by sender, subject pattern, and keyword rules. It is not the part that earns the client's attention.

The second part is the assistant the owner actually talks to. He types a request in plain language: find my emails from last week from the planning committee, or draft a reply to the most recent message from this person. The assistant interprets the intent, extracts the relevant date filters and sender name, queries Gmail with those parameters, and either returns the messages or passes the thread to the writing subworkflow.

Making drafts sound like the owner is the genuinely interesting challenge. The common approach is to load hundreds of sent emails into a vector database and instruct the model to write in the owner's style based on those examples. That approach rarely works as expected. The model averages across all the examples rather than extracting the consistent voice, and the drafts end up sounding like a composite of several different registers of how the owner writes rather than any particular one.

The better approach is to take fifty to one hundred real sent emails, feed them to a language model in a single session, and ask it to produce a tone and style guide. That guide captures how the owner opens messages, the transitions they use, how they handle requests they want to defer without refusing, how they close with clear next steps, and any formatting habits they consistently apply. The guide distills the voice into a compact document rather than making the drafting agent re-read a hundred examples on every single call.

That style guide lives in the system prompt of a dedicated writing agent, and the writing agent is a separate workflow from the main assistant. That split is deliberate and it matters for both cost and clarity. The main assistant handles inbox retrieval, label sorting, and contact lookup. When a draft is needed, the main assistant calls the writing subworkflow and passes two things: the full message thread and the recipient's contact record. The writing agent does one job, producing a subject line and body in the owner's voice, returned as structured output so nothing needs to be parsed or cleaned up manually.

The split saves money at volume. Without it, every time the owner asks the assistant to find an email, the system reprocesses the entire style guide even though the style guide is irrelevant to a retrieval request. With the writer as a separate agent, the style guide only runs when drafting is actually requested. Each agent stays focused on one clearly defined job rather than switching between modes on every call.

One technical detail that makes the drafts genuinely useful: when fetching email content from the API, turn off any option that simplifies or truncates message bodies. A snippet is almost never enough context to write an accurate reply. The writing agent needs the full thread to produce a response that addresses what the email actually says rather than what the subject line suggests.

Short-term memory is the third element of the build, and it is the one most builders forget in the first version. Without memory, every follow-up the owner types starts a fresh conversation with no continuity. He cannot type "now reply to the second one" and expect the assistant to know what the second one refers to. With memory enabled for the last several exchanges, the assistant holds context across a session the way a human assistant would after being briefed on a batch of messages together. The memory window is kept short, covering only recent interactions, because storing every exchange indefinitely adds cost without adding meaningful value in an inbox context where the owner cares about today and this week rather than exchanges from six months ago.

The first morning the system ran, and what it revealed

The delivery was framed explicitly as iteration one. That framing is not a hedge or a disclaimer. It sets the relationship between the owner and the system correctly from the start.

When a business owner receives an AI system and believes it is complete, the first edge case it fails on produces frustration. When the same owner receives iteration one with the clear understanding that real usage will reveal cases no test bench anticipated, the same failure produces a note about what to fix next. The framing changes the experience of imperfection from a broken promise into an expected part of the process.

For a law firm, the initial system handles client status updates and routine scheduling replies. The partner recovers roughly an hour per morning from inbox sorting and draft writing. A human approval step sits before anything sends. In a professional context where a wrong word in a client message carries real consequences, the approval step is the correct design for the first phase. It is not a weakness in the system; it is the responsible posture for a new system handling sensitive communications. As the drafts prove consistent across weeks of actual use, the partner gains confidence to adjust that gate on lower-stakes reply types.

The value becomes visible within the first few days. It is not that every draft is perfect on the first pass. Most are very good, and the ones that need adjusting take thirty seconds to edit rather than three minutes to write from scratch. The accumulated time savings across a week are what the owner actually paid for. The relief of not beginning every morning buried in an unsorted inbox is what they mention to colleagues when the conversation comes up.

The conversations that follow a successful first delivery are not about whether the system works. They are about what to automate next. That pattern, a working first project that immediately opens a follow-on conversation, is the clearest indicator that the scope was right and the delivery landed well. It is also where the relationship transitions from a one-time project into something longer.

Where the ongoing engagement begins after delivery

An AI system is not finished on delivery day, and the clearest path to recurring revenue from this kind of work is making that fact explicit before the first project is done. Real usage surfaces edge cases that no testing reveals in advance. A message phrased in an unusual way returns a draft with the wrong tone. A contact whose name is formatted differently than expected does not surface correctly in search. A reply to a legal notice drafts with technically accurate language but the wrong register for the context. Each of these is a tuning task, and the tuning is where the ongoing arrangement lives.

For a builder, these tuning tasks are the recurring work that makes a monthly retainer straightforward to justify. The owner does not want to become an expert in the system. They want the inbox problem solved and kept solved as the types of messages change over time, as new vendor and partner relationships develop, and as the underlying model capabilities shift with API updates. The builder who provides that continuity earns ongoing value rather than a one-time fee.

The economics look clear in this light. The initial project fee covered discovery, design, build, testing, and handoff. The ongoing arrangement, where a working system that returns an hour of productive time to the owner every morning is maintained and improved, earns out over time for both sides.

For a service business with a heavy communication load, the email assistant connects naturally to a CRM and website stack that already holds the owner's contact history, deal stages, and client notes. When those two systems are connected, the assistant knows who the client is, where they are in the relationship, and what the last several interactions covered before it writes the first word of a draft reply. That context is what turns a generic draft into one that reads as if a knowledgeable person who knows the situation wrote it.

A business owner running Facebook and Instagram ad campaigns alongside a busy inbox operation has two places where well-built automation returns meaningful daily hours. The email assistant handles one. An ad management workflow handles the other. Both start with the same diagnostic question: where does the first hour of the morning actually disappear, and what changes if that hour comes back.

The $1,650 project demonstrates a principle that applies to every AI automation engagement. The skill that earned the fee was the conversation that turned an enormous vague ask into one concrete problem. The build was the straightforward part. The diagnosis was the service. Understanding how to have that diagnosis conversation, how to scope the right first project, and how to deliver it in a way that earns the follow-on engagement is the compounding skill that this kind of work rewards over time.