Onboard Your First AI Team Member
Last lesson you wrote the instructions. This one you hand them to someone.
Noelle Russell returns to pick up the other side of context engineering. Last session was about getting clear: the role, the task, the examples, the constraints. Useful, and also a little abstract, because the words sat in a document and nothing happened to them. This session is where those words go to work.
She frames her own instinct honestly. Her temperament is go, ship it, build it, get it out the door. What her career taught her is that design comes first and building comes second, and that the journey is shorter that way, though it is still a journey. So the order here is deliberate. You are not learning a platform today. You are learning what to do with clarity once you have it.
Two demonstrations carry the lesson. First a pre-built system where six agents already exist and your only job is to give them context, which is the fastest way to feel what a working AI team is actually like. Then Claude, where nothing is pre-built and you construct the thing yourself. She calls them a walking tool and a running tool, and the order matters as much as the tools do.
Listen to an audio summary of this session here.
A felt sense of what six context engineered agents can do for you in an afternoon, and then the more durable skill underneath it: writing a full persona document, understanding that guardrails arrive in layers you did not all choose, and knowing where the real leverage sits once the big platforms catch up.
Writing your role, task, examples, and constraints by hand, into a document, one careful prompt at a time.
Those same words dropped into a harness that holds them, and then into a system where you build the harness too.
The model is the processor. The context is the working memory.
Noelle reaches for hardware to explain what a context window actually is. A computer has a central processing unit, the part that does the thinking, and it has random access memory, the working space the processor uses while it does that thinking. Neither is useful without the other.
In this analogy the language model is the processor. It can reason, but on its own it knows nothing about your situation. The context window is the working memory: the space where you tell that processor what it has access to, who it is being right now, and what finished work looks like in your world.
This reframes a complaint you have probably had. When a model gives you something flat, the processor did not fail. The working memory was empty. You handed a capable thinker an empty desk and asked for a finished report.
Who it is being. The role it plays in this particular conversation.
What the work is, and who it serves. The task, and the person on the other end of it.
What good looks like. Examples. And a useful permission from Noelle here: the examples do not have to be real. You are allowed to write the example you wish existed. The model needs a target, not a history.
The rest of this lesson is about what happens when you stop leaving it blank, and where you put all that context once you have written it down.
Before you add another system, look at the ones you already have.
Noelle asks the room a question before she demonstrates anything. If you are using an AI system and you are not paying for it, what are you paying with? Someone says time. Her answer is blunter. You pay with the inner workings of your mind. When you talk to a model you do not pay for, there is no barrier and no agreed boundary that says this material is yours and no one else may use it.
Her conclusion is not that free tools are wrong. It is that the work you are moving into deserves a real relationship with the vendor. A paid, transactional relationship is one you can hold someone to. That framing sits underneath everything else in this session, because you are about to connect a system to your email and your calendar.
Then comes the discipline she says matters more than any single tool. Keep an inventory of every AI system you buy. Not a list of names and links, which decays into wallpaper. An inventory with a little metadata attached: who you were when you bought it, what problem you were solving, and whether it is still solving that problem. She keeps hers as a small app rather than a spreadsheet. She has somewhere between fifty and seventy of these subscriptions, and says the discipline is the biggest gift she can offer you, because the alternative is death by a thousand small charges. Large organizations lose track the same way, at a scale where nobody can name what is running.
Type straight into the table. Nothing is saved or sent, it is here to think in.
Three rows is enough to feel it. The one you had forgotten about is usually the one that teaches you something.
A harness that already exists, waiting for your words.
The first demonstration uses Marblism, a platform that provisions six agents for you in a single setup pass. Noelle is careful about why she is showing it, and it is worth repeating, because it is the actual lesson. The harness is built. The context engineering is not. That is still yours to do, and it is the only part that makes any of them useful.
The onboarding asks for your role and your website, then reads the site and infers your company, what you do, and who you do it for. Noelle points out the uncomfortable implication immediately. If your website is vague, everything downstream inherits that vagueness. The system is only reflecting the clarity you already published.
Tap any teammate to open what it needs from you and the boundary it cannot cross.
Noelle's own framing of the real prize: once the commoditized work is handled, what would you build? Do not spend your time building a custom agent that reads your inbox. That problem is solved. Spend it on the thing only you can see.
Some of the rules are yours. Some were decided before you arrived.
This is the quiet, important correction in the session. When you write a persona document you are setting constraints, and it is easy to assume those are the only constraints in play. They are not. The platform has its own, written by people you will never meet, and they are not up for negotiation. Eva archiving but never deleting is the clean example. Noelle did not choose that. She discovered it, and knowing it is part of the job.
Every time you connect a system to your email, your calendar, or your social accounts, a permission screen describes exactly what access you are granting. Noelle's name for what most of us do with it is YOLO mode: click, click, click, in. Her ask is modest. Read it once. Or paste it into NotebookLM and have it read to you. Then decide.
Plenty of tools take meeting notes. What changes here is that the note taker can reach the social media agent, the legal agent, and the sales agent. Ask Eva to tell Sunny to build a campaign from what was just decided in that meeting, and it happens. The value is in the connections, not in any one agent.
RTEC was the sketch. This is the finished thing.
Last lesson gave you RTEC: role, task, examples, constraints. Noelle is direct about what that was. A mini version. A place to start. What it grows into is a full document, one per agent, and she calls it a persona document or a guardrails guide.
She shares three of her own, for her executive assistant, her blogger, and her social media associate, and then says the thing that keeps this honest: do not use mine. These are my words and my rules. Build your own. Hand mine to Claude as a shape to follow if that helps, and then write yours.
Her framing for what the document actually is: it should look a great deal like a job description. That is the whole trick. You already know how to describe a role to a person you are hiring, including the parts about judgment and boundaries that never make it into a task list. You are writing that, for a machine.
Noelle's caution is worth carrying with you. Not every conversation needs this level of control, and you should not overthink it or feel behind for not having one yet. The point of AI Mastery is that you are leaving vending machine behavior behind. You are training a model to give you results worth having, and this is how that is done.
The walking tool showed you what is possible. Now you build it.
The second half moves to Claude, and Noelle's framing of the relationship between the two is the clearest line in the session. Claude is the engine. The pre-built platform is one of the cars. Seeing the car first tells you what engines can do. Then you go and build your own.
Here the vocabulary shifts, and it is worth getting straight, because these three words get used loosely everywhere else.
A job to be performed, once or on a schedule. Noelle runs a daily brief that reads her calendar and inbox, gathers stories she can use on stage, and cites every source so she can follow the trail.
The instructions that let the model perform that task properly. Skills are the mechanism by which you train the model. There is a skill creator built in, which interviews you and writes the skill from your answers.
A collection of skills bundled together, so one action triggers six. Noelle runs an internal communications plugin covering status reports and newsletters.
Access to the systems where your work actually lives. Hers reach her project tracker, her design tools, her code, her mail, and her domain registrar, so a skill can go and check whether a domain is free and then register it.
She is unusually honest about where people actually get stuck, and it is not the part the marketing shows you. Ask Claude to rebuild one of those six agents and it will tell you plainly what you would need: a telephony service, a voice provider, a lead database. Connectivity is the glue, and most people never get to that part. It is the hard bit, and pretending otherwise does you no favours.
Noelle's rule in her own company: the second time you do something, it becomes a standard operating procedure. What is different now is that the procedure no longer waits for a person to notice the trigger and act. Written as a skill, it says when this condition exists, do this thing, and then it does it. The document became the doing.
The system worked. She was the one who had not changed.
This is the most useful story in the lesson, and it is a story about failure that turned out not to be one.
Noelle asked Claude to organize her downloads folder every morning. It did. She opened it, found something that looked like a five year old's bedroom, nothing alphabetical, nothing sorted by size, and concluded the thing was broken.
Then she remembered Amazon. When their fulfillment centers went fully robotic, the robots reorganized the shelves by how often items were retrieved rather than by any human category. Toothpaste beside batteries beside bananas. To a person walking in, chaos. To the system, a thirty eight percent efficiency gain. The shelves were not disordered. They were ordered for a different reader.
Her downloads folder was the same. The organization was real, it just was not built for scrolling. And she had kept scrolling, because that is what she had always done. The old habit arrived before the new capability could be used.
Now she does not scroll. She asks. That presentation from last week, the one about such and such, where is it. And it comes back instantly. The model became her index rather than her filing clerk. Watch for this in yourself over the next few weeks. When a system feels like it made things harder, ask whether the tool failed or whether an old routine is still running underneath it.
Point at where the knowledge already is. Do not drag it into one room.
A question came up that this program has been circling for weeks: where exactly do I build my brain? Noelle's answer has two halves, and both are true at once, which is why it is worth sitting with.
Tap either heading to switch between the two ways of holding your knowledge.
Start here when you are new. One contained set of material, a single place, so you can build an end to end system without drowning. Noelle calls this a data set: one piece of the very large puzzle that is you.
This is where it goes. Noelle's own knowledge is spread across drives, sites, and podcasts she does not even own, and she treats it as a mesh rather than a location. Large organizations learned the same lesson the expensive way, which is why the industry now builds data fabrics instead of central copies. She has worked with a client running two thousand sources. Nobody was going to move those.
The resolution between the two is sequencing, not contradiction. Begin contained so you can finish something. Grow toward the mesh as your material outgrows any single room. What matters either way is that you can name the scope of your brain and say where each piece of it lives. She keeps an actual map of hers.
Her practical route: load your sources into NotebookLM, which will ingest drives, sites, documents, images, and audio, and then generate a mind map of what you have. It will also produce a podcast, a slide deck, a video overview, flashcards, quizzes, and reports from the same material.
The move worth stealing is how she divides it. One notebook per campaign, per project, per class. The mind map then shows one line of thinking clearly instead of showing everything at once and teaching you nothing.
Nothing you build should be a black box, least of all to you.
Noelle learned this one by living it. After roughly five years and seventeen hundred days of prompting inside one platform, she moved most of her work to another. Everything she had taught the first system was gone. What saved the migration was documentation she had written along the way, not memory.
Her hack is small enough to adopt today. When you finish building something, ask the model to document it for you, so that you could rebuild it from the description alone. It costs one sentence.
You get two things from that, and the second is the one people miss. The obvious return is disaster recovery: a rebuild path when an account is lost or a platform changes. The less obvious return is the audit trail. Read how the system actually reached its answer and you may find sourcing that does not sit right with you. Noelle's example is direct. It may be able to get past a paywall. That does not mean you want it to.
This is also, she notes, how you keep systems safe as they get faster. The temptation as speed increases is to stop checking and assume it is fine. Making a system explain its own reasoning is the discipline that holds against that drift.
She points out that this documentation is your intellectual property. The words that make your agents behave like yours are an asset. Store them accordingly.
Everything you build will be commoditized. Build it anyway.
Someone asks the question everyone building on top of a platform eventually asks. The pre-built system is adding the feature I was going to sell. What happens to me? Noelle's answer reframes the whole enterprise, and it is the most strategically useful minute of the session.
There is always a distance between what a large platform has shipped and what a particular customer actually needs. She calls that distance the AI gap. Big companies move in quarters and years. You move in days. The gap is not a risk to your business. It is your business.
Noelle is unsentimental about her own work because of this. She builds, it serves for a while, a large platform absorbs it, and she asks what the next thing is. She credits the habit to something she learned at Amazon: you innovate on behalf of your customers, continuously. And she adds the part that makes it sustainable rather than exhausting. Solve one problem for someone and new problems appear, problems they could not have had until the first one was gone.
She keeps checking this in the room, because roughly half the people there are growing a career rather than a company. The gap works identically. Before she owned a business her question was how do I solve my customer's problem, where the customer happened to be her employer. Employee or founder, you are looking at the distance between what exists and what is needed, and closing it faster than a large organization can.
Her advice for a first win is to stop trying to invent something nobody has built. Find people doing it well, become a customer, and study the craft. She was not a customer of that six agent platform at first. She was looking for something she could hand to other people, and then noticed the intentionality behind it and stayed.
Then the part most people would never think to do: interrogate the agents. Ask where these leads came from. Ask what you are not allowed to do. Ask how you were trained, and why that rule exists. She says she has collected more understanding of ethics, policy, and governance by asking models those questions than by almost anything else. A production system in the wild is a playground for anyone willing to ask.
Nine cards. Answer before you turn them over.
The quick reference below is there to be read. These are here to be retrieved, which is the part that makes a thing stay. Say your answer out loud first, then turn the card.
Tap a card to turn it over.
What was actually on screen.
Where you build skills, plugins, and connectors of your own. The engine underneath the demonstration, and where Noelle now does the large majority of her work.
Six pre-built agents with the harness already assembled, so the only work left is context. Shown as a worked example of a well built agentic system, not as a requirement.
Ingests your sources and generates a mind map, plus podcasts, slide decks, video overviews, flashcards, and quizzes from the same material. One notebook per project keeps the map readable.
Not a product. The screen that appears when you connect an AI system to your mail, calendar, or social accounts. Noelle's suggestion if the language is dense: paste it into NotebookLM and have it explained to you.
A note on cost, since the session is candid about it. Noelle spends thousands each month across her systems, against a business that supports it, and she is explicit that this is not the expectation for anyone here. The tools shown run in the range of thirteen to thirty dollars a month. Her actual instruction is the inventory: know what you pay for, and know whether it still earns its place.
The words from this session.
Our job is not to write code. Our job is to write words that tell a machine how to operate.