Context Engineering and building the OS

6/4/2026
Jake Bivens
5
min read

Context Engineering and building the OS

Most teams use AI individually — building context in silos that never transfer. We built a shared operating system on GitHub, connected to Claude Code and every tool we already use, so the whole team pulls from the same brain.
Written by
Jake Bivens
Published on

Most teams use AI individually — building context in silos that never transfer. We built a shared operating system on GitHub, connected to Claude Code and every tool we already use, so the whole team pulls from the same brain.

We Built a Brain for Our Team. Here's What Happened.

Context engineering, multiplayer AI, and the QC Growth OS.

For a long time, the problem was obvious but hard to solve. Every time someone on our team opened Claude, they started from scratch. Client context lived in people's heads, in Slack threads nobody could find, in Google Docs that stopped getting updated after week two. If you needed to know what was happening on an engagement you weren't running, you had to ask someone. And that someone had to stop what they were doing to catch you up.

We tried a lot of things. Google Sheets for list management. ClickUp for project tracking. Airtable for campaign data. Notion for docs. All of them still useful - but none of them solved the core thing: how do you get everyone pulling from the same brain?

That's what we set out to build. And over the last few months, it's changed how we operate.

THE PROBLEM

Everyone had their own Claude. Nobody had the same one.

Think about what actually happens when a team uses AI tools individually. You build context in your own window. You get good at prompting for your clients. You develop a feel for what works. But none of that transfers. The person next to you is starting from scratch on the same client, making the same mistakes, rebuilding the same context you already have stored somewhere in a chat history you'll never find again.

That's not AI-native. That's just AI-assisted chaos.

The goal is not to have AI tools. The goal is to have one brain that the whole team pulls from and builds on top of.

The shift we needed was from personal AI sessions to multiplayer AI. A single source of truth that every team member, every tool, and every Claude session can tap into at any point.

THE BUILD

The QC Growth OS

We built it on GitHub, connected to Claude Code. The repo is the operating system for everything we do. Every client folder holds their ICP, personas, voice guide, messaging, campaign history, DNC list, and current strategy. Every playbook, SOP, and skill lives there too. 

The way it works in practice: you open Claude Code, point it at the repo, and every session loads all the context automatically. No copying. No pasting. No explaining who the client is or what you're working on. Or the classic favorite, “review this website and learn about what they do” - nope, you just work.

Here's where it gets interesting. The tools we were already using - Slack, our outbound stack, Airtable, Fireflies - they didn't go anywhere. But the way we use them changed completely. Through MCP connections, Claude Code can now talk directly to all of them. It reads Slack channels, pulls live data from our outbound stack, analyzes Fireflies call transcripts, and pushes updates to Airtable - all from inside a single session, without anyone having to manually export, copy, or reconcile anything.

Real use case: 

One of the first real tests was onboarding a client engagement that had been running for almost six months. Normally, getting someone up to speed on that history would take hours of back and forth. Instead, we pointed Claude at the relevant Slack channels, the outbound stack data, and three months of Fireflies transcripts from weekly calls. Ten minutes later it had a complete picture - from day one of the engagement to today, every decision, every campaign result, every blocker.

How it works day to day:

Commands, context, and the feedback loop

The real power isn't the storage. It's what you can do with it. We've built a set of commands that anyone on the team can run against any client folder. Here are the ones we use most:

/[client name]

Loads the client folder into context. Everything Claude needs to know, instantly.

/todo [client]

Pulls from Slack, the outbound stack, and the last call transcript. Surfaces priority actions for the day.

/follow-ups [client]

Finds replies that need a response, reads your last 5-10 messages to match your tone, and drafts suggested replies.

/weekly-report [client]

Pulls from the outbound stack, Slack, and Fireflies. Generates the full client report and asks if you want to post it or save it to Airtable.

/new-client-setup [name]

Creates the full client folder in GitHub with all required fields. Prompts you to add onboarding responses or run account research.

/agent-refresh [client]

Finds new influencers and competitors to track based on client context. Refreshes the signal pool when leads start to dry up.

One thing worth calling out: when the output of a command isn't quite right, you tell Claude what to adjust. It regenerates the response - and then automatically pushes your feedback into the underlying prompt so it's better next time. The system learns from the team as it runs.

We also built an OS log channel in Slack. Every time something gets pushed to the main repo, a message fires. The whole team sees it. The brain stays updated in real time.

What this actually changes:

Less setup. More powerful operators.

A go-to-market engineer who used to spend 30 minutes rebuilding context before doing anything now runs a command and starts in 30 seconds. A go-to-market lead who used to manually dig through campaign data to write a client report now runs /weekly-report and spends their time on the parts that actually need judgment.

The tools didn't change. The relationship to the tools did. Airtable is still where campaign data lives. Slack is still where the team communicates. Fireflies still captures every call. The outbound stack still runs the sequences. But now Claude sits on top of all of it, connected via MCPs, with full context loaded from the repo. The whole stack works together instead of in parallel.

The AI tool space is flooded right now. Everyone's got something new to try. But tools without context go haywire fast. The effectiveness is only as good as the operator running them - and the operator is only as good as the context they're working from.

This is the infrastructure layer that makes everything else work better. Not more tools. A better foundation.

We're building this for our team and for the teams we work with. Still early, still learning. But the results are speaking for themselves.

Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
Read about our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.