AI for a virtual assistant: four recipes that work every day

What do I hand to the model and what do I keep?

The boundary is simpler than it looks and comes down to one question: if the output is wrong, what does taking it back cost? A draft that has not been sent costs nothing; a message that has gone costs an apology; and money that has moved or access that has been granted may not come back at all. The cheaper the undo, the freer the model.

So the four jobs in this lesson are all of one kind: every one of them produces a draft and none of them sends anything. Inbox triage proposes a sorting, meeting notes propose a task list, a research summary proposes text, and the weekly update writes a first version. In all four, sending is a button you press.

What never goes to the model is not somewhere else either: promising something to a client, deciding about money, granting access, and choosing which task goes first today. People underrate that last one; setting priorities without knowing what the client is worried about this week is not calculation, it is guessing.

One note that saves a lot of time: anything a simple rule can answer does not need a model at all. An email filter by sender, a dated reminder, a saved reply for a repeated question. A model is more expensive, slower and less consistent than a rule, and its place is where the answer needs judgement.

Inbox triage and drafting replies in the client voice

This is the most frequent job in the work and it takes the most time, not because replying is hard but because deciding about each message is hard. What the model genuinely does well is that first decision: which bucket each message falls into.

Four buckets are enough: needs a reply, is only information, needs the client decision, and irrelevant. The third is the most important, because those are the ones that become next week problem if they slip through. And a fifth bucket is needed that most people forget: "I do not know". A model that is not forced to classify everything is not forced to guess either.

These are today messages from my client inbox. Names, numbers and amounts have been removed.

Client tone card:
{the tone card, or three of the client own approved messages, verbatim}

Things I am allowed to handle myself:
{short list}

Messages:
{each message in its own paragraph}

What I want:
1) Put each message in one of these four buckets: needs a reply, is only information, needs the client decision, irrelevant.
2) For the reply bucket, write a draft reply in the voice of the card and not in your own. If a message needs something that is not on my list of permissions, do not draft it and say why.
3) For the client decision bucket, write one sentence: exactly what has to be decided and what options are on the table.
4) Put any message you are unsure about in a fifth bucket, "I do not know", and write the reason. Do not guess.
5) Do not reply to anything yourself and do not send anything.

Rule two is what separates this from an ordinary prompt. Once your list of permissions sits at the top, instead of manufacturing an answer for everything the model stops itself and says this one is outside your authority. That list of permissions is settled with the client in the first week and has nothing to do with AI; the lesson on what a virtual assistant is covers that same conversation.

How do I turn meeting notes into a task list?

Meeting notes are usually a messy text with three things tangled together: work assigned to someone, decisions that were made, and things that were raised and went nowhere. The value of this recipe is in that separation, not in summarising. Nobody needs a summary of a meeting; everybody needs its task list.

These are the raw notes of a meeting. I have replaced names with roles.

{note text}

Produce three separate lists:
1) Tasks: what, assigned to which role, by what date. If a role or a date was not stated in the text, leave the field empty and write nothing there.
2) Decisions: what was settled. Only what was actually decided, not what was proposed.
3) Open items: what was raised and reached no decision.

Rule: do not add any task that is not in the text, even when it looks sensible and necessary. If the meeting missed something, the fact that it was missed is information too.

That last rule looks simple and is in practice the most important line in the recipe. Models are helpful, and that helpfulness adds a task nobody assigned, and at the next meeting you are chasing work that was never anyone job. One occurrence of that and the client trust in the whole list is gone.

Empty fields must also stay empty. A task with no date should stay blank so that you ask by when in your very next message. If the model fills the date with "next week", you have handed the client a fabricated deadline and called it planning.

A research summary that demands its sources

"Give me a summary of this topic" is the worst way to use a model for client work, because the output looks exactly like what it should look like and you have no way to tell right from wrong. What makes this job safe is one rule: no claim is written without a link, and anything without a link is confessed in a separate list rather than dropped.

I want to prepare a short summary about {topic} for a client.

The decision that will be made from this summary: {decision}

Rule: every sentence that makes a factual claim must carry a direct link beside it. If you have no link for a sentence, do not write that sentence and put its subject in the "could not find" list.

1) The summary, at most ten points.
2) Beside each point, a link to the page where that exact statement appears, not the site home page.
3) The "could not find" list: things the decision above needs and for which you found no source.
4) The "contradictory" list: places where two sources say different things, with both links.
5) Finish with one sentence: with this summary, can that decision be made yet or not.

Point four is the thing an ordinary summary never gives you. A contradiction between two sources is itself one of the most important things a client should know, and it is precisely what a smooth readable summary sweeps under the rug.

And one step no prompt replaces: open the links. A model can produce a link that looks right and does not open, or point at a page that does not contain the statement. We keep that same rule for ourselves, and the cost is clear: a wrong link in a text you hand a client is recorded as your mistake, not the model.

The weekly update you sign yourself

The weekly update is the thing people put off most, because writing it takes patience and it moves no work forward by itself. Yet this single message decides what the client believes they got this week. An assistant whose work is excellent and whose updates never arrive looks worse to a client than one with average work and a steady update.

These are my tasks from last week for one client, taken from the task list. Names have been removed.

{task list with statuses}

Write a short update with three sections and no more:
1) What is finished.
2) What is still open and exactly what is blocking it.
3) What I need from the client: each item a specific decision or a specific access, not a general request.

Rules: do not write anything that is not on the list. Do not attach adjectives to any task, not "successful" and not "excellent". If section three is empty, leave it empty and do not write "nothing needed for now" unless nothing really is.

Those three sections are the three things every status update needs, and the third is the one most people drop. The difference between an update that reduces the client work and one that creates an extra round trip is always that third section.

The no-adjectives rule is not arbitrary either. Models write encouragingly by default, and an update in which every task was completed "successfully" stops being read after two weeks. An update that only says what happened gets read.

What never goes into a prompt?

All four recipes on this page open with one sentence: names and numbers have been removed. That sentence is not a formality, it is the condition for running any of them. The reason is one thing people understand too late: what has been pasted cannot be unpasted.

The list of what stays out is short and has no exceptions: names, phone numbers and addresses of real people, amounts tied to a specific person, customer lists, anything under a confidentiality undertaking, and passwords, keys and tokens in any form. A password does not go anywhere except where it belongs, which is the conversation the tools lesson ended with a shared vault.

Whether a conversation is used to improve a model depends on the plan and on a setting, not on how you feel about it. Anthropic own privacy page says that in its consumer products, chats are used to improve models when the user has chosen to allow it, when a conversation is flagged for safety review, or when the user has explicitly opted in. Which means the honest answer to "is my data used" is always the same: it depends on a setting you have not looked at yet.

And the human half matters more than the technical half: once, in that first week, tell the client which tools you work with and what part of their work never enters them. It is one sentence, and it removes the only version of this that ends badly, which is the client finding out on their own. If you want to see why the caution is not misplaced, the lesson on what cybersecurity is shows the same thing from the attacker side.

Does AI replace the virtual assistant?

Our position is clear: no, and someone who takes these four recipes seriously becomes more expensive rather than cheaper. The reason has nothing to do with what a model can do and everything to do with what a client is actually buying.

A client does not buy text. If text was what they wanted, they have access to the same models you do. What they buy is that an open loop gets closed and one person is responsible for it: someone who remembers that the supplier never replied, someone who recognises that this message is different and has to be answered today, and someone who answers for it if something goes wrong. A model closes no loops and accepts no responsibility.

What genuinely changes is the mix of the work. Typing shrinks and checking and deciding grow. An assistant who has built these four recipes into their week does not spend the freed time typing less; they spend it on more clients or on deeper work for the same one. Quality rises too, because an update that arrives every week and a summary that carries its sources beat an assistant who never had time to write either.

One warning is needed, because missing it is expensive: these recipes make you faster and you will be tempted to sell the speed. If you promise a client a reply within the hour, what you have sold is availability rather than assistance, and that is a different product at a different price. If you are reading from the other side and want to hand this work over, the RGB virtual assistant service page shows how we deliver exactly these jobs.