If you tried the RCTFC prompting framework after our first session, you probably had a good week. Better output, faster decisions, maybe a document that stopped eating your afternoon.

Then the annoyance crept in. Every new chat starts cold. You paste in the company background. You restate your preferences. You explain, again, what a good output looks like. Somewhere around the fifth time, you start wondering whether the minutes you’re saving are going straight back into setup.

That friction is a signal. It means you’ve outgrown the single conversation.

We spent Session 2 of AI for Operators fixing it.

A new employee whose first day never ends

The analogy we keep coming back to: Claude is a remarkably capable new employee. The problem is that every fresh chat is their first day on the job. Same talent, zero memory of your company.

Nobody runs a team that way. When you actually hire someone, you hand them a folder on day one: company overview, services, pricing, ICP profile, a note about how you like things written. Every task they ever do starts from that foundation.

A Claude Project is that folder. It’s a persistent workspace where Claude always has your company context, and it holds four kinds of things:

  • Documents. Service descriptions, pricing sheets, case studies, ICP profiles, brand guides, past proposals. (A practical tip from Nick: plain text, markdown, and CSV files read cleanest. Word docs and very large PDFs get processed as text only, so embedded images are lost.)
  • Custom instructions. The role Claude plays, its standing jobs, the output format for each job, and the never-dos.
  • Business context. Who your customers are, the problems you solve, what separates you from competitors.
  • Writing examples. A few emails you actually sent. This is the unlock most people skip, and it’s how the output starts sounding like you instead of like AI.

Don’t upload everything on day one. Start with what the first use case needs and grow from there.

The two-line prompt that suddenly works

At the session we built a project live: business development lead qualification for Meridian Advisory, a fictional $50 million professional services firm we use for demos.

The instructions took a few minutes to write. You are the BD assistant. Your standing jobs are qualifying inbound leads, drafting replies, and prepping discovery calls. Rate every lead strong, moderate, or weak, with a one-line reason. Never open an email with “I hope this finds you well.” Never promise a price before the scope is understood. Never oversell a weak fit. Then four documents went in: company overview, ICP profile, pricing, and sample outreach emails.

Then came the test. We pasted in an inbound lead and typed: “Qualify this inbound lead and draft a response.”

Ten words. By Session 1 standards, a bad prompt. No role, no context, no format, no constraints.

It worked anyway. Back came a fit rating (strong, with the one-line reason), a note on the budget path, and a reply drafted in the tone of our sample emails, ready to send. Then we opened a brand new chat, typed “Prep me for this discovery call,” pasted a short meeting brief, and got exactly what the instructions specify for call prep: three points to raise, two questions to ask, likely objections with suggested responses, and the single outcome to aim for on the call.

The lazy prompt from Session 1 failed because all the context was missing. The same lazy prompt now succeeds because the context lives in the project. RCTFC didn’t go away. It moved out of your prompt and into infrastructure, where you write it once.

And all of it, instructions and documents together, used less than 1% of the project’s capacity.

From a project to a workflow

Once context is permanent, recurring work gets interesting. A task is a workflow candidate when it comes back weekly, monthly, or quarterly; follows the same steps with different inputs; involves data or documents; and needs a consistent output format. Status reports. Client updates. Pipeline reviews. Meeting prep.

Think of it like running payroll. The timesheets change every pay period. The process of turning timesheets into paychecks never does. Your project instructions are the payroll process. This week’s data is the timesheets.

So we built one live: a weekly operations report for a fictional $30 million services firm. The instructions define the exact structure the leadership team sees every Monday: executive summary, revenue and sales, operations, financial health, red flags only if there are any, and recommended discussion topics. We dragged in three CSV exports, typed “Here’s this week’s data, please compile the weekly operations report,” and had the full report in under a minute.

Then we did it again with the next week’s files. Same sentence, new data. The second report caught what the numbers showed: bookings short of target, ticket backlog rising, receivables aging. It surfaced the red flags and suggested what leadership should discuss.

That’s the reuse. The three hours a real ops leader spends compiling that report every Monday become a drag-and-drop and one sentence, and the thinking time gets spent on what the numbers mean instead of assembling them.

This is level one of three. Repeatable prompts you trigger yourself, then scheduled tasks that run on their own, then Research Mode for multi-step investigation. The rule of thumb for level two: Claude can schedule anything it can gather on its own. If the inputs are files only you can provide, you’re still in the loop, which is why connectors (coming in the final session) matter. They remove the download-and-upload step entirely.

The ROI math your board actually wants

Now the part most AI initiatives skip.

That Monday report takes a manager three hours. Fifty weeks a year, that’s 150 hours. At a loaded cost of roughly $100 an hour, you just recovered about $15,000 per year, per manager, on one workflow. Run five plant managers through the same report and it’s $75,000 a year.

The formula is simple enough to do on a napkin: hours saved per cycle, times cycles per year, times the number of people running the workflow, times loaded hourly cost. Put risk reduction on its own line beneath it. Keep it that simple on purpose, because a board or a PE sponsor can check napkin math in their head.

Two honest caveats from the session. ROI projections aren’t the whole decision; you also weigh the cost of AI getting something wrong in that workflow. And change management is real: a workflow nobody runs saves nobody anything. But if you can’t write this arithmetic down for your AI spend, you don’t have an initiative. You have a subscription.

Build one this week

The homework we gave the cohort applies here too: pick one recurring task, build one project around it, and run it twice. Not five projects. One.

Session 3 went further, turning a spreadsheet nobody trusted into working software with no code written by a human, and that recording is already in the archive. The final live session, Your Team + Your Strategy, runs Tuesday, August 11 at 2:30pm ET: what your engineering team should be doing with AI, how to assess it without being technical, and the adoption framework to roll it out. One free registration covers everything, recordings and materials included.

Tell Claude about your business once. Then get back to running it.

AI for Operators is the free workshop series from The Gnar Company for the leaders accountable for AI results. If you want to know where your company stands today, start with our AI readiness assessment.