Implementation Lab: Building Your First AI Assistant
This is a working session, not a talk. You pick one real use case, you build a Claude project that interviews you and writes project instructions on your behalf, and then you use it to produce your first genuine AI assistant, with its instructions and its knowledge files in place.
Vykintas Glodenis is explicit about the intent. He wants the class to end with something tangible you could be proud of, that starts creating value straight away, rather than an hour of watching someone else work.
Last week you met a team someone else assembled. This week you hire your own.
Noelle showed a platform with six agents already built, where the harness exists and only the context is missing. That was the fastest possible route to feeling what an AI team is like. This session goes the other way. Claude Projects is a blank canvas. It asks more of you at the start, and in return it will build anything you can describe.
The reason the program teaches it this way is worth naming. A packaged tool solves the use cases its makers chose. This course is not built around any one use case, so it teaches building blocks instead, and then shows you how to combine them into whatever your own situation actually needs.
Listen to an audio summary of this session here.
Whatever the platform calls them, an AI assistant is made of two things: instructions, and knowledge files. Custom GPTs, Gemini Gems, Copilot, Claude Projects, the pre-built agents from last week. Same two elements underneath. Learn them here and the rest is naming.
Packaged tools solve their use cases. You have your own.
The pre-built platform from last week is genuinely good at what it does. It picked six roles most small businesses need, built the onboarding to extract what it needs from you, and connected the agents to real tools so they can act. You clicked through and got value the same afternoon, without having to think about context at all.
That last part is the trade. Because it thinks about context for you, it can only serve the situations it already anticipated.
Ask a room of people what they actually want to build and you get nutrition and fitness assistants, email triage, ISO audit management, electronic file organization, LinkedIn content, brand marketing. No packaged product covers that spread. This is why the harder tool earns its place.
Cowork and Claude Code spin up many agents working independently in the background. They can do things regular Claude cannot, and they consume your usage far faster.
For most day to day work you want the conversational shape: you ask, it produces, you refine together. Anthropic recommends regular Claude for the majority of tasks, and that is what this lab uses. The others come later, once you can tell which jobs need them.
You are writing a job description and packing an onboarding folder.
This is the analogy the whole lab rests on, and it makes the abstract part concrete immediately.
The job description. Who this assistant is, the work it does, the process it follows, the standards it is held to. Written once, then passed silently to Claude as the first message of every conversation you start inside that project. You never see it go, and you never retype it.
The onboarding pack. The documents specific to your business, your processes, your standards, none of which exist in the model's training data. A new colleague reads these before starting. So does this one, on every task, without being reminded.
Vykintas is emphatic that this pair is not a Claude feature. It is the shape of the thing everywhere. Custom GPTs on ChatGPT, Gems on Gemini, agents on Copilot Studio, the pre-built platform from last week. Different names, same two elements. And when the course reaches genuinely autonomous agents later, these remain the foundation everything else is built on.
You cannot put several assistants inside one project. You can give one assistant a broad remit, and sometimes that works. If the results start feeling unfocused, split it.
His reasoning is the same one you would apply to a person. Instructions for a newsletter writer can be precise. Instructions for someone who handles all of marketing end up being about everything and nothing at the same time. Focus improves performance, for people and for models alike.
A room you prepare before anyone arrives.
Projects sit in the Claude sidebar and follow you across web, desktop, and phone. Inside one you will find four things, and one of them behaves in a way that surprises people.
When you create a project you are asked for a name and a description. Neither is read by Claude. They exist so you can find the thing later. All the behavior comes from the instructions field, which is a separate box you open with the plus button. This trips up nearly everyone the first time.
Drag files straight into a project and the interface can get stuck, refusing to let you start a conversation. It is not something you did. Refresh the page and it works. He hits it live during the session, which is a reasonable argument for demonstrating on real software.
Once you can name the four shapes, you start noticing candidates everywhere.
This is offered less as a taxonomy and more as a habit of attention. Knowing the four types is what lets you look at something you did twice this week and think, that is a workflow, I could build that.
His own examples across the types: a marketing strategy advisor, a weekly strategy thinking partner, a personal finance advisor and a curriculum design advisor as roles; a weekly newsletter pipeline as a workflow; a meeting summary formatter as a tool. And two containers, one simply called Conversations and one called Tools, where he drags any chat that has quietly turned into something he keeps coming back to.
Three questions, asked while you are already working.
Not everything deserves a project. These three criteria are meant to be run in your head mid conversation, the moment you notice yourself doing something familiar.
Tap each criterion that is true of what you are working on. The verdict updates as you go.
The rule he gives is deliberately loose. Two or three yes answers and you should almost certainly build a project. One is often still worth it. All three no, and an ordinary conversation is the right tool, which is a permission worth having, because the enthusiasm after a lab like this can turn into projects for things that never needed one.
You do not need to know how to write the instructions.
This is the first of his two principles, and it removes the exact obstacle most people are stuck behind. You do not need to know how to write good instructions. You do not need to know what context matters for this particular assistant. You do not need to work out in advance which knowledge files it will want.
Because you can ask AI to do that part. The same move from the vision session applies here: rather than trying to produce the finished thing yourself, you ask the model to interview you, collect what it needs through targeted questions, and then use what it knows about writing instructions to write them properly.
There is one constraint that makes this work, and it comes straight from the framework in lesson 5. Models are eager. Left alone they will skip the interview and hand you a finished draft built on assumptions. So you tell it plainly not to generate anything yet, and to interview you first. That single line is the difference between a real conversation and a confident guess.
A project whose only job is to build your other projects.
Here is where the lab turns clever. Rather than handing out a prompt you paste in each time, he has you build one project, once, whose instructions turn it into an interviewer. From then on, every future assistant starts as a conversation inside it.
Worth noticing, and he asks the room to work it out: this project is a workflow, not a role. It leads you through a defined sequence and delivers a specific result at the end.
Tap any phase, including the pre-flight check, to open what happens inside it.
Does this need foundational documentation written first? Do you already have materials that should go in? And the useful one: does this scope actually make sense as a single project, or should it be split in two? It may tell you to build A now and come back for B in a separate conversation.
You never have to request the interview, because it is already written into the instructions. One detail he built in deliberately: for questions with short answers it uses a selection widget, so you click options instead of typing them. Small change, and it makes the whole thing usable on a phone.
Once it has enough context it says so, then writes the full project instructions. You read them, and you push back where it misread you. This is a draft to react to, not a verdict.
It works out which files this assistant needs: what you already have and could upload today, and what does not exist yet and will have to be created. That second list is where the next section of this lesson picks up.
It checks what connectors and skills already exist on your account and designs around them. He admits this phase is ahead of where the class is, and left it in on purpose, so the builder keeps being useful as you learn more. At that point it is designing a system on your behalf, not just writing a prompt.
He also keeps a second, more advanced version of these instructions, and tells the room plainly not to use it yet. Once skills, connectors, and plugins have been covered, you swap the instructions out and the same project gets sharper. That is a good pattern to copy: version your own instructions as your understanding grows.
Paste that into the instructions field of a new project, name it whatever you like, and it is ready. His own version lives in the Airtable he shares with the class, and is worth comparing against once you have used this one a few times.
Four assistants, built in an airport, on a phone.
The demonstration that makes the case better than any argument. Waiting at an airport in Jakarta, chasing a toddler who would not stay still, he opened the Project Builder on his phone and started conversations. By the time he boarded he had the makings of four assistants: an email triage, a video script writer, a newsletter writer, and a content strategist. No typing to speak of, because the interview offers options to tap.
Follow the newsletter one through, because it shows the whole shape. The conversation produced two things.
A newsletter DNA document, researched for his actual position as a technical AI educator. He points out why that matters: what works for him is not what works for someone teaching manifesting. Generic best practice would have been worse than useless.
A full instruction set with a role, his context, voice rules, audience, co-writing principles, and frameworks broken out by email type: content bridge, insight drop, story email, sales email, plus rules for subject lines. He never asked for a role. It knew to write one.
Then he assembles it, which takes about a minute. New project, paste the instructions, download the DNA document and drop it into the files. Then he adds a second file that he did not create at all: his company's existing autoresponder guide, already full of hard won knowledge about what makes their emails work.
The live test is honest about what you get. He drops in the framework from lesson 5 as raw material, answers three tapped questions, and out comes a newsletter email that opens on the vending machine idea from Noelle's session. Good, not finished. His point is that if you are unhappy with it you keep going: add examples of your own writing so it learns your voice, add instructions where it drifted. The first output is the beginning of the conversation, not the end of it.
If the document you need does not exist, generate it.
A worry surfaces in most rooms at this point. Large companies have documentation. Individuals often have none, and it can feel like the whole approach depends on paperwork you never wrote.
His answer is to make the missing document. Building the video script assistant, he needed a social media DNA specific to technical AI education, which no company handbook was going to give him. So he turned on deep research and let it work. It read one thousand one hundred and seventy nine sources over thirty minutes, then produced a full report he downloaded as a markdown file and dropped straight into the project.
He is candid that his own prompt was not sophisticated. It was a plain description of what he wanted, followed by a block of personal context that he did not type either. He asked the earlier conversation to summarize what it had learned about him, copied that, and pasted it in. The context you already generated is reusable material.
An ordinary answer optimizes for getting back to you quickly. Deep research does the opposite: it spins up many searches, works through a large number of sources, and synthesises a long document rather than a chat reply. That is why it suits building a reference file and not much else.
When you export a document, choose .md or .txt. Markdown looks a little strange to us, with its symbols and hashes, and it is ideal for a model. Nothing technical is being asked of you here, just a different item in the same save menu.
Do not try to build the perfect assistant. Build a working one and use it.
The second principle, and the one that decides whether anything from this lesson survives the week. Observe, orient, decide, act. Then again, quickly.
Without it you get a long stretch of nothing happening. You research, you plan, you try to gather enough information to be certain, and you never can be, so the plan rests on assumptions anyway. Then you release the thing you spent months and budget on and discover it was not what anyone wanted. The information you needed was only ever available on the other side of shipping.
With it you build a rough version, use it immediately, notice what is wrong, and improve one thing. Ask the assistant directly what it would need from you to do better. Update the instructions. Add a file. You will move up and down rather than in a clean line, and the direction of travel is up.
He ends the point on himself, which is what makes it land. He is analytical and critical by nature, and he gets caught overthinking, asking whether a feature really works the way it appears to. He watches Vishen simply try the thing, and move fast, and he names his own tendency as something he is still working against. If the person teaching the lab finds this hard, you are allowed to find it hard.
It will act on your behalf. It will not start on its own.
The honest limitation, stated plainly rather than left for you to discover. A Claude project does not run on a schedule. His inbox triage assistant works well, and every morning he has to open it and ask. Nothing happens until he does.
Once triggered it does real work: it reads recent mail, flags what genuinely needs him today, labels what needs following up, and drafts replies where it has enough context. On the day of the session it surfaced a security issue on sites he had built. Useful. Still waiting to be asked.
What lets a project reach your actual work. From the plus button inside any chat, open connectors, add one, and authorise it. Connect Gmail and you can see exactly what it is permitted to do: create a draft, retrieve a thread, label a message, list your drafts.
This gets a proper session later. It appears here only because phase four of the builder will ask about it, and because an assistant with no reach is limited to advice.
Automatic operation is what Cowork and Claude Code are for, and both are coming. For now the shape is: you decide when, it does the work.
Finish with something that exists.
Build one AI employee, on Claude or on the platform from last week, and submit it as an artifact with a title, a cover image, and a description. You choose whether it is visible to the community.
Tick each step as you finish it.
The word artifact is used deliberately across this program. It means a tangible result, evidence that you applied the thing rather than watched it. The showcase fills with them, and browsing what other people built is its own source of ideas.
What was on screen.
Where the whole lab happens. Projects live in the left sidebar and follow you across browser, desktop app, and phone. Instructions and files are the two fields that matter.
Not a separate product. The plus button in any conversation, then research. Trades speed for breadth and returns a long synthesised document rather than a reply.
Shared in the session as a live base you copy into your own account rather than a static handout. Holds the examples, the four types, the three filters, the principles, and the builder prompts. Airtable itself gets taught next week.
Custom GPTs, Gemini Gems, and Copilot Studio agents are the same two elements under different names. Learn the pattern once and it transfers.
One note on how the material is built, because it is a teaching choice worth stealing. The Airtable is not slides. You copy it into your own account, tick the examples you want to build, and a filtered view turns your ticks into a backlog. The handout becomes an application you keep using after the class ends.
The words from this lab.
Ship the imperfect version and use it. Waiting for certainty is how the work never starts.