Session Notes: Group AI Productivity Training
2026-06-15 · Wendy, Karen, Andrea, Cindi, Briana (Megan and Kurt joined briefly)
Overview
This was a roughly two-hour group working session with the RCB team, run remotely over video with screens shared. The format was a guided walkthrough: Nate worked through a single reference guide (the "Getting Real Work Out of AI" field guide the team is keeping) as a spine, and along the way demonstrated several working tools he had built specifically for RCB based on what people had raised in earlier conversations. The first stretch was a high-level tour of how the main AI tools work and how to get good results out of them; the back half moved into live demonstrations of real RCB tools and an open discussion about where the team could use this in their own work. The room was encouraged to interrupt with questions throughout, and Karen in particular drove a lot of the Q&A.
The Landscape — Which AI Tools, and How They Differ
Nate started with the lay of the land: the major general-purpose tools (ChatGPT, Claude, Gemini, and Microsoft's Copilot) all do roughly the same core thing — you type a request in plain English and they respond — so the practical advice is to pick one and get comfortable rather than agonize over the choice. He added Perplexity as a fourth worth knowing, noting it's better suited to live web searching than the others. Copilot got called out as the natural fit for RCB specifically, since it's already embedded in the Microsoft programs the team uses and already "knows" the files being worked on; Nate's guidance was to reach for Copilot first when working inside Microsoft documents, and step out to one of the others when a more powerful general answer is needed. He also noted Claude has recently become usable inside parts of the Microsoft stack.
On free vs. paid: the free versions are fine for learning, but the roughly $20/month paid plans open up a lot — more usage, smarter models, and the ability to build reusable assistants. Nate's line was that the moment you're using it for real work, the paid plan pays for itself quickly.
Karen raised that she'd been running out of usage on Claude partway through the day and having to wait a few hours. Nate clarified the two separate limits people hit: a usage cap (how much you can do in a given window, which is what Karen was hitting — this lifts with a higher-paid plan) versus the conversation-length limit (a single chat can only hold so much before its quality degrades, which is solved by starting a fresh chat, not by paying more). He explained that everything is metered in "tokens," that all the activity across your chats draws from one shared bucket on your account, and that you can't get around a cap by jumping between chats.
Getting Good Results — Instructions, Context, and Model Choice
Nate framed two things as mattering more than anything else: clear instructions and good context. On instructions, the advice was to tell the tool who it should be, what you want, and what "good" looks like — and to treat the first answer as a draft, going back and forth until it's right. He contrasted a vague request ("write a tagline") with a detailed one (role, audience, length, tone) to show the quality difference.
On context, his point was that the public tools know nothing about RCB until you tell them — and that the more relevant material you hand them, the more the answer sounds like your business. Ways to do that: paste material straight in, upload files (including images), or — the bigger step — load the context once into a reusable setup so you never have to repeat it.
A question from Karen about model selection led to a useful aside on choosing models: more capable models (like Opus on Claude) can handle harder, deeper thinking but cost more to run and use up usage faster, while the standard model (Sonnet) is the sensible default for everyday work. Nate's rule of thumb was to only reach for the more powerful model when the task genuinely calls for deep thinking or holding a lot of information at once. He used his own setup as the example — most of his automated processes run on the standard model, with only a handful of the most complex ones set to use the more powerful one.
There was also a short clarifying conversation about terminology — what "LLM" (large language model) means, how "generative AI" differs from the older AI that's been quietly running things like search and autocomplete for years, and where Claude Code fits (Nate's advice to Karen: she doesn't need Claude Code, which is an advanced developer tool, though "Claude Cowork" is a friendlier on-ramp if she's ever prompted to try it).
Reusable Assistants — Projects, Folders, and Custom GPTs
This was a core teaching section. Nate explained the distinction people find confusing: a "Project" (Claude) or "folder" (ChatGPT) is a workspace where you load your context and instructions once, and every chat inside it automatically knows all of that — so you never re-explain your business. A "Custom GPT" (ChatGPT's term; Gemini calls its version a "Gem") is built to be shared and handed out to others. He walked through the back-end of where these get created — the name, the description, the instructions, and the knowledge files — using a couple of his own simple image-poster tools as examples to show how a set of instructions, written once, gets applied automatically every time.
Briana asked how the team could share these with each other so that everyone benefits when someone adds context. Nate explained that true shared access requires a Teams plan (which is a per-person monthly cost), but that there's a workaround for now: keep the knowledge files in one agreed shared folder, and each person uploads the same files to their own individual version of the tool. The team noted they currently have a few individual paid accounts rather than a shared plan.
The RCB Company Brain
Nate showed the "RCB Company Brain" — a Claude Project he built and is handing over to the team, loaded with over 50 pages of context about RCB (an "about us" narrative covering the company's story, work, and operations, plus the AI opportunity work he's been doing). The point he demonstrated: any chat inside this project reads all of that company context first, so it answers as if it already knows RCB, without anyone having to provide background each time. He ran a few live examples — including a 45-second elevator pitch tailored to someone from the Milwaukee Bucks' corporate partnerships, and a "top 10 ways AI can help our business right now" ranking that surfaced order intake as the number-one item on its own. He emphasized this is a clean version, stripped of his internal strategy notes, and that the team can and should keep adding their own material (price lists, customer lists, anything) to make it more powerful over time.
Live Tool Demonstrations
Nate showed three working tools built to address things people had raised:
Product imagery in a real scene (Concept Studio). A Gemini-based tool where you upload a product blank and a logo, say where you want it, and it places the product into a setting — a tumbler on a desk, product on an office table. He was candid about the limits: it works well for clear logos on clean shapes, struggles with intricate logos and complex shapes (it invented a shape on one example), and the free version adds a watermark. His framing was that it's a useful starting point and a concepting tool, not finished production art.
This sparked discussion. Briana raised the idea of a tool that produces a clean, repeated series of a product at multiple sizes — the polished look high-end brands use for product images — as a way to upgrade RCB's product photography. Wendy was skeptical that the AI-generated images beat what she can already produce in Photoshop, and noted the generated ones look fake; she also said her real constraint is having the time to make images, not the ability. Karen raised a related but separate need: a large number of products aren't listed on the site at all because they lack images, and she wondered whether a tool could help generate consistent basic product shots to fill that gap.
Cycle count weeder. Built for Andrea, who currently has to manually delete irrelevant products from a cycle-count export before she can work with it. Nate showed a version that takes a messy export and returns a cleaned list of what to count, plus a note of what it removed and why. Andrea said it would need more work and that she'd have to be very specific about exactly what she's looking to count, but agreed it would be faster than her current tedious manual process. Briana suggested a smart way to teach the tool: feed it the last ~10 exports she'd already trimmed by hand, so it can learn the pattern of which items to keep or drop, then have Andrea edit those rules.
Customer reply drafter (built live). At Briana's request, Nate built a simple version from scratch during the session to teach the process. It drafts customer email replies in RCB's voice, and — using an uploaded customer tier list — gives white-glove treatment to top-tier ("A") customers and crisp, professional, detail-confirming replies to others. He walked through each step: defining who the assistant is, defining what good looks like, creating sample customer-tier and reply-example files, loading them as knowledge, and then testing it live on both an A-list and a B-list customer email. Briana saw immediate potential to grow it with a library of canned explanations for the things the team explains repeatedly — vector artwork requirements, why copy changes need an Excel file rather than a long PDF.
Background Knowledge — Markdown, and How Nate Works
A few questions led Nate to explain markdown files: simple text files (just headings, bullets, and a little formatting) that AI tools read more cleanly and cheaply than heavy formats like PDF or HTML. His tip: if you have a long PDF manual you want a tool to use, convert it to markdown first. He also gave the team a brief look at his own working setup — how his client work is organized as a large set of markdown files and step-by-step commands he runs to do the analysis work, including the prioritization work he did with Briana and Cindi — to illustrate where these simple text files ultimately lead.
Agentic AI and NotebookLM
Nate closed the structured portion with an explanation of "agentic AI" — the difference between AI that answers and AI that acts, carrying out multi-step tasks across apps on its own. He gave everyday examples (an order email arriving, details getting pulled out, a row added to a spreadsheet, a reply drafted) and named the no-code tools that enable it (Zapier, Make, n8n), while pointing the team toward Power Automate and Copilot Studio as their natural fit given they're a Microsoft shop. His honest caveat: even the "simple" automations get tricky to set up — authentication and quiet failures trip up even people who do this for a living — and anything that has to touch real systems, handle sensitive data, or run reliably every time becomes a real engineering job worth getting help with.
He also briefly demonstrated Google's NotebookLM as a standout for turning dense source material into readable, teachable formats. Briana immediately saw a fit: loading equipment manuals and SharePoint SOPs into it to help train people and get new hires up to speed.
Good Habits
Throughout, Nate returned to a few principles: always read anything before you send it (the tools are confidently wrong sometimes); keep genuinely sensitive information — customer payment details, personnel info, competitive financials — out of the public tools, while treating everyday working material (logos, art files, specs, order details) as fair game; treat the tool as a draft partner, not the final word; and push back when an answer is off. He also gave a practical, balanced take on data security — drawing a line between low-risk internal use and the more real liability of exposing client-protected information — while recommending the team talk to a lawyer for anything they're unsure about.
Wrap-Up and Takeaways
In the closing round, Briana said she'd learned a lot and felt she could now see past "just chatting" into using projects, folders, and custom assistants. Her personal takeaway was that she should be asking Claude to help her use it better, the way Nate demonstrated. Wendy's takeaway was to look into the AI tools built into Photoshop for her image work, since she's already paying for that platform. The team discussed possibly starting, as a group, to build out the customer reply tool with real examples.
Follow-Ups
- Nate is sending the team the reference field guide (the link they can keep), the RCB Company Brain, and the example tools he built (cycle count weeder, the product imagery tool, and the reply drafter).
- Briana requested a short quick-start guide for projects and custom GPTs — how to build them.
- Nate is continuing build work with his engineering partner on the freight tool.
- A more advanced session is scheduled with Briana and Cindi for June 17 at 8:30am.