My AI team member Mike creates social media posts. He knows our brand voice, our audience, our rules. He does not guess. He delivers. 25 minutes of work, done in 3. Ten times a week.
I built Mike in about an hour. The value compounds every single week.
But here is the thing most people miss: the building part was not about AI. It was about thinking clearly about what I actually do and what "good" looks like. The AI part took 15 minutes. The thinking part took 45.
That thinking process is what I turned into a framework. I call it BUILD.
Why Most People Get Stuck
People get stuck because they prompt a generic chatbot instead of building an AI team member with their own knowledge and rules.
Most people try AI by typing something into ChatGPT, getting a generic answer, and concluding it does not work. I see it in every team I train.
The problem is not the tool. The problem is that the tool knows nothing about you. It does not know your clients, your brand voice, your way of working, your quality standards. So it gives you something that sounds fine but feels wrong. Close enough to be annoying, not close enough to be useful.
The fix is simple: stop prompting. Start building.
An AI team member is not a chat window you type into. It is a colleague you brief once and then put to work. It has instructions, context, and rules. Just like a real colleague would on their first day.
BUILD gives you the five steps to get there.
The BUILD Framework
BUILD is a five-step framework for individuals who want to create their first AI team member: an AI assistant that knows your context, follows your rules, and produces output you can actually use.
The first three steps are thinking. The last two are building. Most people skip the thinking and jump straight to the tool. That is why their AI produces generic output.
Begin With Your Goal
Pick one task you do at least twice a week that follows a repeatable pattern. That is your starting point for BUILD.
Goal: one specific, recurring task that is well-suited for an AI team member.
Not "help me with everything", but something specific that you do regularly, that follows a pattern, and where you can tell whether the output is good or not.
Four Criteria for a Good First Task
A good first task for the BUILD framework is specific, recurring, patterned, and assessable. If your task meets all four, it is ready for an AI team member.
Specific
Not "help me with content" but "create weekly social media posts for LinkedIn."
Recurring
Something you do at least a few times a week, not a one-off project.
Patterned
It follows a recognisable workflow each time.
Assessable
You know what a good result looks like.
For me, that was social media content. Every week, same format, same channels, same brand voice. Repetitive. Predictable. Perfect starting point.
Your version might be: writing weekly reports, summarising meeting notes, drafting client emails, or creating training plans.
One task. That is where it starts.
Pick one task that is specific, recurring, patterned, and assessable. Start small. You can always build the next one later.
Unpack the Skills
Unpacking means writing down exactly how you do the task, including every "always" and "never" rule you follow instinctively.
Goal: a written description of how you actually do this task, including the "always" and "never" rules.
Write down how you actually do this task. Not the ideal version. The real one.
What steps do you follow? What do you always include? What do you never do? What does a good result look like, and what makes a bad one bad?
For my social media AI team member, I wrote down:
- Always use our brand voice
- Never use more than two hashtags
- Always include a call to action
- Start with a hook, not a summary
- Keep sentences under 15 words
- No jargon
These are not prompts. These are instructions. The difference matters, because instructions persist across conversations. A prompt is a one-off question. Instructions are the operating manual for your AI team member.
Write down the real workflow, not the ideal one. Your "always" and "never" rules are your first instructions.
Identify the Knowledge
Knowledge identification is gathering the documents your AI team member needs: voice guidelines, rules, reference examples, and domain expertise. This step is 80% of the real work in BUILD.
Goal: a collection of documents that contain everything the AI needs to do this task well.
What does someone need to know to do this task well? Gather that information.
This is 80% of the real work. Most people skip it and wonder why the output sounds generic. The reason is simple: the AI has nothing specific to work with. Give it your context, and the output changes completely.
Typical Knowledge Documents
The four types of knowledge documents for a BUILD AI team member are voice guidelines, rules and standards, reference examples, and domain expertise.
- Voice and tone guidelines. How should the output sound? Include examples of good and bad output. "Professional but accessible" means nothing. "Write like this example, not like that example" is clear.
- Rules and standards. What must always happen? What must never happen? Formatting requirements, compliance rules, quality thresholds.
- Reference examples. Show what good output looks like. Five posts that represent the style you want. A finished report at the quality level you expect.
- Domain expertise. Brand guidelines, target audience descriptions, product details, terminology. The things an outsider would get wrong.
You probably have most of this already. It lives in your head, in scattered documents, in your email. Collect it into one place.
Generic: "Write in a conversational tone"
Useful: "Write short sentences. Max 15 words. Use 'you' more than 'we'. No jargon. Here are three examples of posts we consider good: [...]"
Collecting knowledge is 80% of the work. Most of it already exists somewhere. Good/bad examples teach AI more than paragraphs of description.
Layout the Instructions
Layout is where you combine everything from the previous BUILD steps into one instruction document using the 3C approach: Character, Context, and Clarity.
Goal: one set of instructions that tells your AI team member who it is, what it knows, and what to do.
Combine your skills and knowledge into one set of instructions for your AI team member. Write it as if you are briefing a new colleague on their first day. Use the 3C approach:
Character
What role should the AI play? "You are a content specialist for our marketing team" is better than "You are a helpful assistant."
Context
What does the AI need to know about the situation? The team, the audience, the purpose.
Clarity
What exactly should it do, step by step? "Summarise" is vague. "Write 3-5 bullet points, max 15 words each, focusing on decisions and action items" is clear.
The instruction document does not need to be long. Mine is about two pages. But every line is there for a reason.
Setting It Up
You can set up your BUILD AI team member in ChatGPT (Custom GPTs), Claude (Projects), Gemini (Gems), or any AI platform that supports persistent instructions and file uploads.
- ChatGPT: Create a Custom GPT, paste the instructions, upload your knowledge documents
- Claude: Create a Project, add instructions and knowledge files
- Gemini: Create a Gem, paste instructions and upload documents
- Any other tool: If it accepts system instructions and file uploads, the same principle applies
Use the 3C approach: Character, Context, Clarity. Brief the AI like a new colleague. Two pages of good instructions beat twenty pages of vague ones.
Debug and Improve
Debug is the final BUILD step where you test your AI team member with real work and fix gaps in the instructions. The first version is typically 70% right, and each fix makes it permanently better.
Goal: an AI team member that consistently produces output you are happy with.
Give your AI team member a real task. Not a demo scenario. Actual work from this week. Check the output. What is good? What is off?
The first version is usually about 70% right. The last 30% comes from tweaking your instructions based on what you see.
Common Problems and Fixes
The four most common BUILD debugging issues are wrong tone, unwanted disclaimers, incorrect structure, and generic output. Each points to a specific part of your instructions that needs improving.
| Problem | What to fix |
|---|---|
| "The tone is too formal" | Your voice description is not specific enough. Add before/after examples. |
| "It keeps adding disclaimers" | Add a rule: no disclaimers. Be explicit about what to avoid. |
| "The structure is wrong" | Your workflow description is missing a step. Walk through the task again. |
| "It gives generic advice" | Your knowledge documents need more specifics. Add examples, frameworks, edge cases. |
Run three to five real tasks through it. Compare the output to what you would have produced manually. Every gap tells you which document needs improving.
After a week of small tweaks, my social media AI team member was producing posts I could use with minimal editing.
Test with real work, not demo data. The first version is 70% right. Every fix improves the AI team member permanently.
What This Looks Like in Practice
Mike gets a topic and a channel. He produces a complete post: hook, body, call to action, hashtags, alt text for the image. In our tone, for our audience, following our rules. 25 minutes of manual work, done in 3.
But Mike is just one AI team member. I have built several now, each specialised for a different task. A research assistant that knows my sources. A writing validator that checks against our style guide. The principle is always the same: one task, one set of instructions, one knowledge base.
You do not need to plan for a whole team from the start. Build one. Use it for a week. Then decide if you want to build the next one.
When you are ready to take this from individual AI team members to a team-wide approach, that is where the DRAFT framework comes in: a five-step method to move your team from scattered AI experiments to shared workflows.
Three Things You Can Do Right Now
You can start the BUILD framework today by picking one task, writing your "never" list, and collecting one knowledge document. That covers the first three steps.
- Pick your task. What do you do at least three times a week that follows a pattern? Write it down in one sentence.
- Write the "never" list. What should the output never contain? Bad habits, wrong tone, common mistakes. These are your first instructions.
- Collect one knowledge document. Your brand guide, your process description, an example of good output. Just one to start with.
That covers your B, U, and the start of I. The foundation is done. The rest is iteration.
The Real Point
Building an AI team member is not a technical skill. It is the ability to articulate what you know and how you work. And that thinking part makes you better at your job, whether the AI works perfectly or not. Because you have now documented what "good" looks like. Most teams never do that.
Start with one task. Build one AI team member. Use it for a week. Then decide if you want to build the next one.
The BUILD framework was developed by Guus Witjes at Step Ahead AI, based on training 1,000+ people at HAN University and running hands-on workshops where participants build their own AI team members in a single session.
Frequently asked questions
What is an AI team member?
An AI team member is a persistent AI assistant built with your knowledge, your rules, and your voice. Unlike a generic chatbot, it knows your brand, your workflows, and your quality standards. You build it once and it gets better over time as you add more knowledge.
How long does it take to build an AI team member with the BUILD framework?
A simple AI team member can be built in a few hours. The first version should take no more than one week. The real quality comes from iterating: testing with real work, finding gaps, and improving the knowledge documents over time.
What tools do I need to build an AI team member?
You need an AI platform that supports persistent instructions and knowledge: ChatGPT Plus with Custom GPTs, Claude Pro with Projects, or Google Gemini Advanced. The BUILD framework works with any of these. The tool choice comes last, after you have defined the goal and gathered the knowledge.
What is the difference between BUILD and DRAFT?
BUILD is for individuals who want to create a personal AI team member for a specific task. DRAFT is for team leads and managers who want to move their whole team from scattered AI experiments to shared AI workflows. BUILD focuses on building one tool well. DRAFT focuses on team adoption and making AI the way your team works.