How to build a personal AI assistant that actually knows your job

TL;DR: An assistant that knows your job is three things: a precise role definition, a set of context files describing your work, and a small library of task instructions you reuse. No code required. The reason most people’s AI output is mediocre is that they supply none of the three and start every conversation from zero.

Why generic AI gives generic answers

Ask a model to “write an update for my manager” and it writes an update for a manager — some manager, somewhere, in some industry, about some project. It has no idea that your manager reads on a phone between meetings, hates preamble, and only wants to know what is blocked.

The gap is not intelligence. It is context. Everything below is a method for supplying context once instead of retyping it forever.

What you are building

Three layers, in order of leverage:

1. The role definition — who the assistant is and how it behaves. Set once, applies always.
2. Context files — what it needs to know about your job, your organisation and your standards.
3. Task instructions — saved prompts for the things you do repeatedly.

Built in a Project (Claude or ChatGPT — compared in the Projects comparison), all three persist across every conversation.

Layer 1: The role definition (20 minutes)

This is a system prompt, and it is the highest-return thing you will write. Not “you are a helpful assistant” — that is the default and adds nothing. Be specific and operational:

“You are my work assistant. I am a [role] at a [type of company] in [industry], based in [location]. My work involves [3-4 concrete responsibilities]. The people I write for are [audiences and what each cares about].

How to respond:
– Lead with the answer, then the reasoning. Never open with a restatement of my question.
– Default to under 200 words unless I ask for depth.
– Assume I understand [domain basics] — do not explain them.
– When there is a real trade-off, name both sides rather than picking the safe one.
– If you are uncertain or lack the information, say so explicitly. Do not fill gaps plausibly.
– Never use: delve, landscape, leverage as a verb, ‘it’s not just X, it’s Y’, or ‘I hope this helps’.
– If I ask for something where you need context you do not have, ask me one specific question rather than guessing.”

Every rule here should be something you could check compliance with. “Be professional” is decoration; “under 200 words” is enforceable.

Layer 2: Context files (45 minutes, once)

Four short documents. Short is deliberate — long context files dilute themselves and cost tokens on every turn.

1. my-role.md — what you actually do. Your responsibilities, what success looks like, who you report to, what you are measured on, the recurring deliverables you produce. One page.

2. my-organisation.md — how your company works. What it sells, to whom, the internal jargon and acronyms, the named teams and what they own, the tools you use. This one file eliminates most “what do you mean by X” friction.

3. my-standards.md — what good looks like to you. Include two or three examples of your own work you were happy with, and one you were not, with a line explaining the difference. Examples teach far more effectively than instructions.

4. current-work.md — the live one. Active projects, current priorities, who is involved, what is blocked. This is the file you update; the others are stable.

Anonymise anything genuinely sensitive, and check your employer’s policy before uploading company information anywhere.

Layer 3: Task instructions (ongoing)

Every time you get an output you are happy with, save the prompt that produced it. Keep them in a single tasks.md file in the Project. Mine includes things like:

• Weekly update: “Using current-work.md, draft my weekly update. Structure: what moved, what is blocked and what I need from whom, what is next. Under 200 words. Lead with blockers — that is what my manager reads for.”
• Meeting prep: “I have a meeting with [person] about [topic]. From my context files, tell me: what they care about, what I need from this meeting, the three questions I should ask, and the objection most likely to come up.”
• Inbox triage: “Here are today’s messages. Sort into: needs a decision from me, needs a reply I can send in under two minutes, can wait, and can be ignored. For the two-minute ones, draft the replies.”
• Document review: “Review this against my-standards.md. Do not rewrite it. Give me the three weakest parts and why.”

After a month you will have 10-15 of these, and they cover most of your recurring written work.

Before and after, on one real task

The same request, with and without the three layers. Task: draft an update after a difficult client call.

Without context — “Write an update to my manager about a client call that went badly.” You get four paragraphs opening with “I wanted to provide you with an update regarding my recent client engagement”, a diplomatic summary of nothing in particular, and a closing offer to discuss further. It is grammatical, generic, and you will rewrite all of it.

With the three layers — the same request, but the assistant knows you are an account manager, that your manager reads on a phone between meetings and wants blockers first, that “difficult call” in your context usually means a commercial objection, and that your standards file contains two updates you were happy with.

What comes back opens with the blocker in one sentence, states what the client actually objected to, what you propose doing, and what you need from your manager — under 150 words, no preamble, in a register that matches your previous updates.

The difference is not model capability. Both outputs came from the same model on the same day. The difference is that one had been told who it was writing for and what good looks like, and the other was guessing.

That is the entire argument for spending ninety minutes on setup: you are not making the model smarter, you are stopping it from guessing. And it guesses toward the average of everything it has ever seen, which is by definition unremarkable.

The habit that makes it improve

When output is wrong, do not just fix it and move on — that teaches the assistant nothing, because the model does not learn from your corrections between conversations. Instead ask:

“That was not what I wanted because [specific reason]. What should I add to my context files or role definition so you get this right next time?”

Then actually add it. The assistant gets better because the files get better. That is the entire mechanism, and it is worth understanding why: nothing is being learned by the model itself.

What this cannot do yet

At this stage the assistant knows about your job but cannot see your actual documents, and cannot do anything in the world. Those are the next two layers: giving it your files in the documents and memory guide, and connecting it to your tools in making it act rather than answer.

Common mistakes

• Context files that are too long. Five pages of company history is worse than half a page of what matters. Ruthlessly cut.
• Vague standards. “Professional tone” means nothing. Show examples instead.
• Never updating current-work.md. A stale live file produces confidently outdated answers — the most annoying failure mode because it looks correct.
• One Project for everything. If your work has genuinely separate domains, separate Projects beat one bloated one, for the same reason narrow collections retrieve better.
• Trusting it on facts. It still fabricates. Everything checkable gets checked — see the hallucination explainer.