Map Your Operating System Before You Apply AI

Most CEOs look at AI as a tactic they can apply formulaically, like cloud computing or agile software development. It's not. To apply AI technologies effectively, you first need a deep understanding of how your business operates.

The AI outlook in the C-suite and on boards runs the gamut. At one end of the spectrum, AI is magic; it will do anything you can dream up. At the other end: what's AI? In the middle — where most strategy actually gets made — there's very little realistic understanding of what AI is, how it works, or what its limitations are.

What follows are notes from this week's Executive AI Roundtable discussion, shared under the Chatham House Rule.

Before You Even Think About AI

Every business is a system. If you understand your business system, you understand the levers you have.

The hidden gap in most AI strategy conversations: leaders are debating which AI tools to deploy without first describing how their business actually works. What the levers are. Who has permission to do what. What "good" looks like at each layer. The AI question is downstream of that one.

"Before you even think about AI, think about understanding what the operating system is." Most companies skip this step. Some are phenomenally successful anyway, by luck or timing. But businesses that understand their operating system work better. Period.

The right strategic conversations start with what are you trying to do with your company? Where do you want to be in three, five, ten years? Not with copying somebody's AI cookbook.

That's the precondition. Everything else below is a downstream symptom of skipping it.

The Intern Test

Recently, a SaaS company called PocketOS made the news because Cursor — the AI coding tool — deleted their production database on Railway. The AI had been given access to a token that could drop the prod DB, and at some point during a session, it did. (Whether the company's after-the-fact explanation is true is a separate question; the structural failure happened regardless of who or what pulled the trigger.)

You'd never give that token to an intern. Never, ever. Even if you told an intern never use this, ignore it, don't touch it — nobody would do that. They'd lock it away in a secrets manager so the intern couldn't even see it in the file system. So why was it lying around for the AI to grab?

"You're trying to create a structure for the AI piece without having a clear structure for the human piece."

That's the root of the business operating-system gap. Roles and responsibilities. If you can't say which humans should access which secrets, you have no chance of saying which agents should. The AI permissions question is the human permissions question, finally being asked because the AI made it impossible to ignore any longer.

This gap is made most visible in regulated industries. "I worked in the health space, and so there was a lot of very restricted processes we had to go through for any software in general — but AI was another lift on top of all of that." Adding AI is a challenge here, but the path is clearer. Companies that already have airtight role-permission maps for humans are the ones where adding AI becomes a configuration change rather than a re-architecture change. In other words, the AI slots into part of an existing role in the organization.

The intern test is just shorthand: would you give this access, this autonomy, this latitude to an intern? If not, an AI agent has no business with it either. The better question — the one the test surfaces — is whether you have a documented map of what each role can and cannot do. If you don't, you don't have a system governing your operation. You have habits.

With humans, habits stop working as soon as you replace an employee. In the world of AI, there is no such thing as a habit. Even if you set the model temperature to zero, behavior can still vary. Tiny changes to inputs or tooling — tools you might not even control — can impact AI behaviors.

The risk multiplies when AI agents are wired to download and run third-party "skills" — packaged behaviors written by someone else. "This is, like, the NPM of AI here — somebody gives you a random skill, and it goes and deletes your life. In nine seconds." It's actually worse than npm: there you have lock files, signed registries, audit tooling, and years of supply-chain attack-and-response. The AI-skills ecosystem has none of that yet. The intern test still applies; it just has a longer perimeter.

More on this dynamic in Where AI Quietly Goes Wrong in Small Companies: the failure mode is the AI doing exactly what you let it do.

The CEO Who Won't Stop Doing the Team's Work

A common pattern with technical founders: they're addicted to AI, deep into it for forty or eighty hours a week, while their team uses it lightly or not at all. The CEO's current project looks something like "trying to figure out how to use AI for our SEO."

You're the CEO. Why are you doing the SEO work?

There's a team of engineers. Give that problem to the team — let them use AI to figure it out. The CEO is supposed to be focused on strategy, on go-to-market, on whatever the actual constraint is for the business right now. It's certainly not implementing SEO with AI, because one of your team members can do that tactical work. Delegate.

This is the second face of the operating-system gap: the CEO who hasn't mapped their own role, so they end up doing whatever the AI makes easy instead of whatever the business needs. AI didn't create this problem — it's a classic founder trap — but AI puts it on rocket fuel. The CEO can suddenly produce output in any function and feel productive while the strategic work goes untouched.

For more on AI's biggest leverage being internal rather than in the product, see The Real AI Advantage Isn't in Your Product.

The Context Is Where the Value Compounds

Most C-level AI conversations miss the point:

"It's not the model. Who cares about the model? The AI model matters a lot less than this context, this information that you're building up alongside of it."

The value compounds in the artifacts that accumulate alongside the AI: the documents capturing what you decided, the direction you're heading, your values, what you don't want to rank for in SEO, and your hiring philosophy. Every conversation with the AI that produces a useful insight should end with write this down — go update the relevant document so we don't have to rediscover this next time.

The AI agent on top works like an intelligent librarian over that context. The model can change tomorrow — a new Claude, a new GPT, a new Gemini — and the context still works. The operating system still holds. The agent gets sharper; the foundation doesn't move.

Calling this an executive assistant undersells it. It's a Chief of Staff, at least — a counterpart who's read everything written about the business and can ask follow-up questions when the strategy is splitting in two directions at once. Is the business really aligned the way you think it's aligned, or are you heading in two directions and committed to neither? That's a great question for a Chief of Staff to ask. It's an even better question coming from a system that's read the last six months of decisions and noticed the contradiction.

AI is a smart "rubber ducky" — a duck that can talk back. The value lives in what you uncover and write down after talking to it, not in the duck's answers themselves.

Pushing Back on Polished Slop

The hardest skill to develop in the AI era is also the one that becomes most valuable: pushing back.

A new interview screen worth using: does this candidate push back? There's a strong human tendency, when something looks polished — bullet points, clean structure, a confident summary, especially if the bullet points are animated — to assume it must be substantive. AI is exceptional at producing the surface features of a real answer.

It's hard to push back on AI, and harder to tell the slop from the not-slop. The output looks like an answer. It often is — but often enough, it's the same old recycled material with prettier formatting. "It's the same old that people were putting out there. It just looks a bit prettier."

Speed and velocity in organizations are not the same thing. Speed is the rate of motion; velocity has direction. "It can delete your database really quickly! That's speed!" The pattern AI fails into looks productive precisely because it's speed without direction — confident, fast, completely wrong. The model that deletes a production database can't tell you why it did it; it confabulates an excuse, the same way a human would. We literally can't distinguish between an AI screw-up and a human one. Treating AI output like the work of a brilliant intern who needs a senior reviewer is closer to the mark than treating it as a finished deliverable.

For more on the people side of this — hiring, training, and the resistance pattern — see The AI People Problem.

Stagecoaches, Word Processors, and the Pattern That Repeats

Every technology wave has the same shape: a hype phase, a backlash, then the slow compounding payoff for whoever paused to ask the alignment question first.

In 1999, plenty of people thought the internet was a fad. In 2000, the bubble burst. Amazon took a hit, kept going, and made fundamental changes. The dark fiber laid by companies that vanished is still carrying traffic today. Bubbles produce useful infrastructure even when they take most of the investors with them. AI is the same: ten years from now OpenAI may be a memory, but the foundation models, the agent frameworks, and the inference infrastructure built around them aren't going anywhere.

One participant — with a director of engineering background — pointed out that every step in software has been a step up the abstraction ladder: assembly to higher-level languages to telling AI what and how to build things. Each step seemed likely to shrink demand for developers. Each step actually created more demand because cheaper tooling attracted smaller customers who couldn't have afforded the previous tier. Whatever AI does to who-builds-software, the floor of who can afford bespoke software keeps dropping.

In ten years, asking someone, "Do you know how to use AI?" will sound as strange as asking if they know how to use a word processor. By then, using AI is table stakes. The differentiator is judgment: knowing what to point it at and how to produce a business impact. That comes back to whether you've mapped your operating system clearly enough to distinguish high-leverage problems from make-work.

You get to use your judgment when you're using AI. That's why you'll still have a job: your judgment, applied to a context only you can build, is the part the AI can't fake.

Where to Start

The thread that runs through everything above:

1. Map the operating system first. Before you decide which AI tools to deploy, get clear on what your business actually does, who has permission to do what, and what "good" looks like at each layer.
2. Apply the intern test. If you wouldn't give an intern the access you're about to give an agent, reconsider your plan.
3. Stop doing your team's work. If you're a CEO who's eight hours deep into AI on a tactical problem your engineers should own, you're not delegating enough.
4. Invest in context, not models. The model will change. Your context — the documents, the decisions, the values, the operating system — is what compounds.
5. Hire and train for pushback. The skill that matters most in the AI era is noticing when AI output is wrong and taking corrective action.

None of this is glamorous. None of it requires a model upgrade. It's the unsexy diagnostic work of understanding your own business clearly enough to know where intelligence — human or otherwise — actually pays off.

That's also why most companies will skip it.

Resources From the Roundtable

• Business Operating System framework — the framework discussed at length, distributed as a pair of Claude Skills ("bootstrap" and "workshop") that walk a leader through diagnosing their business operating system before applying AI to it.
• Cursor — the AI coding tool involved in the PocketOS / Railway production-database deletion incident.
• Claude — Anthropic's model, the one most participants use as a Chief of Staff / rubber-duck counterpart.
• Claude Skills — Anthropic's mechanism for packaging reusable agent capabilities; both the bootstrap and workshop frameworks above are distributed as Skills.