🔒 Private — prepared for Briana and Cindi (RCB principals). Not for staff.
Overview / Session Notes / AI Power-User Walkthrough

Session Notes: AI Power-User Walkthrough

2026-06-17 · Nate St. Pierre, Briana Riordan, Cindi, Karen

Overview

This was an open-ended, unstructured working session — Nate sharing his screen and walking Briana, Cindi, and Karen through how he actually builds and runs the AI-powered system he uses to deliver his consulting work. Rather than a class or a slide deck, it was a guided tour: Nate used this very engagement as the live example, showed the room how the pieces fit together, and the group reacted, asked questions, and talked through where this kind of approach could go for RCB. The back half of the day moved on to hands-on work on the freight quoting tool (captured in separate notes).

The throughline of the conversation: this way of working is genuinely powerful, it is not magic (it takes real effort to set up well), and — importantly — Nate believes the people in this room actually have the aptitude and the appetite to learn to do it themselves.

How Nate's System Is Built

Nate opened up his working environment and showed that, underneath everything, it is simply a folder of organized text files — meeting transcripts, notes, structured documents — that both he and the AI read and write. Those text files can then be turned into PDFs, presentations, or websites, but the core is plain text, cleverly organized.

He walked through how a single recorded conversation moves through his system: the raw transcript becomes a clean summary, then a more structured document, then a version that pulls out the technical specifics worth keeping. At each step, the AI does a first pass and Nate refines it — he described it as the machine doing roughly 80% and him adding the last 20% of judgment. He showed how the system automatically captures different "views" of every conversation (the client's own words, his strategic read, and the technical details), so nothing gets lost and everything is categorized for later use.

He also showed how he organizes the work into phases and "playbooks" — essentially, written instructions for what needs to happen at each step — and a library of reusable "commands" that carry out those steps consistently. The point he kept returning to: he has taken the things he would normally do in his head, as an experienced consultant, and written them down so a machine can do the repeatable parts and free him to focus on the parts only a human should do.

Nate was candid that he is not a programmer — his most technical background is front-end web design — but that he thinks in systems, workflows, inputs, outputs, and edge cases. He credited the recent arrival of Claude Code running inside a development environment (like VS Code) as the thing that finally let him make his way of organizing work real on his own computer, just by talking to it, without having to write code by hand.

What This Could Mean for RCB

Nate was direct that most people cannot — or will not — work this way: you have to be willing to think it through carefully and put in the work to get it right. But he said the reason he wanted to have this conversation is that he thinks Briana, Cindi, and Karen have both the capability and the ambition for it.

He laid out a few honest options, explicitly noting he was not trying to sell anything: - Learn it on your own. Using the wealth of material already available, the team could teach themselves the basics and start building independently. - Have him help you get started. A separate piece of work where Nate comes in, works alongside the team, helps build the initial pieces, and gets everyone familiar enough with how it all works that they can then build their own tools from there. - Have it built for them. The most hands-off option, where the heavy building is done for them and they simply use their own workflow — drop things in, get the outputs they need — without ever touching the back end.

The room responded with real enthusiasm. Briana said she was inclined to learn to do it themselves because it gives the most flexibility and options, and connected it to a long-standing wish she'd had to invest more in understanding technology — noting that this kind of tool lets her be the architect without needing to know multiple programming languages. Cindi, who Nate noted is usually the quietest in these meetings, said she was "all in" and would love to do the work to learn it. Karen, who has the most technical instinct of the group, recognized the approach immediately as a higher-level version of programming and tracked the underlying logic closely throughout.

Live Example — Turning Meeting Notes Into Useful Outputs

To make it concrete, Nate built a small throwaway example in real time, prompted by Briana's interest. She described one of her biggest day-to-day pressures: most of her week is meetings, and keeping up with follow-up — documenting what was said, sending it out, circling back, prepping for the next meeting — is a constant struggle.

So Nate had the system stand up a quick demonstration: take a set of messy meeting notes and automatically produce four different things from the same input — a list of action items, a log of decisions made (and who made them), draft follow-up emails, and a one-screen status digest. He showed the room that it correctly pulled the real tasks out of the noise (turning a buried "someone needs to call Henderson" into an actual flagged task), ignored the irrelevant chatter, and made sensible judgment calls about what was urgent.

The teaching point landed, especially with Karen: building an example like this also builds the reusable machinery behind it, so the next time you simply drop in a transcript and the outputs come back — you don't rebuild it each time. Nate also sketched how, further down the road, this kind of flow could be wired up to run more automatically (for instance, a recorded meeting landing in a folder, getting processed, and feeding into a task system), while noting that the more automated versions get trickier and are where deeper engineering help comes in.

Nate emphasized throughout that he keeps a human in the loop at every step by choice, and that even the simple version he was showing has meaningfully changed how he works.

Looking Ahead

Nate closed by recapping the remaining schedule: the next working day is him pulling everything from the engagement together into the final set of deliverables, followed by an on-site session to walk through everything, hand it all over, and talk through what comes next. He described what RCB will end up with: a complete, self-contained package of all the work, plus a navigable website layer on top to make it easy to move through — delivered as a portable file they own permanently, and optionally available through a private, access-controlled web page he can stand up for them.

Follow-Ups

  • Open conversation to be continued about whether RCB wants to pursue learning this with Nate's help as a dedicated piece of work, after the current engagement wraps.