I Gave My Company an AI Operating System

Everyone at Vardot uses Claude every day. It took me longer than I'd like to admit to notice that everyone was effectively using a different one.

Drafts came back hyped up. Em dashes kept sneaking into client emails, which is about the fastest way to make something read as AI-written. Estimates quoted delivery norms from years ago, as if our engineers weren't building with AI all day. And each person kept re-teaching the same context, chat after chat: who we are, how we write, what we never say to clients.

The fix wasn't prompt training. It was writing the context down once, centrally, and shipping it with every conversation. Claude's Team and Enterprise plans let an admin set organization-level instructions: a block of text that loads into every employee's chat before they type a word. Ours is under 500 words. Drafting it took an afternoon. Getting it right took a couple of weeks of iteration against real usage, and those iterations taught me more than the final version.

Here's what went in, what I deliberately left out, and what I'd tell you before you write yours.

What Went In

Identity, not credentials. My first draft opened with the trophy case: certifications, partner tiers, marquee client names. The result was that every output led with badges. Proposals, emails, even internal notes started sounding like a capabilities deck. I rewrote it to describe how we work instead: enterprise open-source platforms, AI-driven solutions, deep Drupal expertise, global delivery. Certifications got demoted to a rule of their own: proof points when relevant, never boilerplate. Your certifications are not your identity. How you work is.

Confidentiality as behavior. Client names, project details, and contract terms never appear in public content unless it's an approved case study. If someone pastes a credential or API key into a chat, the AI flags it and tells them to rotate it. We're ISO 27001 certified, and this turns every AI conversation into a second pair of eyes on the practices that certification demands.

Accuracy above helpfulness. The most dangerous AI failure mode in an agency is confident fabrication reaching a client: an invented contract term, a guessed invoice amount, a made-up date. So the instructions are blunt: never invent client, contract, billing, or time facts. Verify in connected sources, and if you can't verify, say so. "I couldn't confirm this" is a fine answer. A wrong number in a client email is not.

Writing style as rules, not vibes. This section does the most visible work day to day. A few of ours, verbatim:

• Never use em dashes; use commas, colons, parentheses, or restructure.
• Lead with the point, then the ask.
• No superlatives, fear framing, or manufactured urgency.
• Write dates unambiguously (21 July 2026) and always state timezones.

Notice these are behaviors, not values. "Write clearly and professionally" changes nothing, because a model can't act on it. "Never use em dashes" changes every draft.

Estimation for the AI era, both halves. Our engineers build with Claude, agents, and AI tooling, so estimates start from that baseline: weeks often become days. But the second half matters just as much: discovery, client reviews, dependencies, and QA still take real time, so don't blanket-compress. Without that second sentence, the AI will cheerfully promise a two-day migration. With it, estimates stay honest in both directions.

Principles for when nobody's watching. Optimize for real client outcomes, not metrics that look good, and flag any process that rewards appearances over substance. And one more that pays compounding dividends: when someone's task is repetitive and manual, say so, and offer to turn it into a reusable skill. The instructions literally teach the AI to help us automate ourselves.

What Stayed Out

Anything a skill does better. My early drafts included blog and LinkedIn writing guidance. I cut it, because a dedicated brand skill enforces all of that in depth, on demand. Same for document templates, contract lookups, and time reporting: each is its own skill. Org instructions are the constitution; skills are the playbooks. Keep the constitution short.

The layering rule I landed on: if it applies to every conversation, it's an org instruction. If it applies to a type of task, it's a skill. If it applies to one project, it goes in that project's instructions.

Anything that changes monthly. Rate cards, org charts, active deals. Stale instructions are worse than no instructions, because people trust them.

Tool tutorials. Claude doesn't need us to explain how a spreadsheet works. What it can't know, unless we write it down, is how we behave.

What Changed

First drafts land much closer to final. Client emails come back leading with the point. Proposals stopped hyping. The em dashes are gone. Review cycles that used to be about tone are now about substance, which is the only thing review cycles should be about.

New teammates absorb the company voice from day one, because the AI they draft with already writes like us.

And one result I didn't expect: writing the instructions forced clarity I'd been avoiding. I had never actually written down how we communicate, how we estimate, or what we refuse to optimize for. The company had norms. Now it has them in writing, and the AI applies them more consistently than I ever did in review comments.

To be honest about the limits: none of this makes anyone a better thinker. It raises the floor. Judgment is still on us, and people can still ignore good advice. What we ended up with is a company handbook that actually gets read, every single time, because the reader is the AI sitting in every conversation. Turns out that's worth a lot.

Write Yours

A starter skeleton you can adapt:

ABOUT US
[2-3 lines: what you do, for whom, how you work. Identity, not awards.]

CONFIDENTIALITY
[What never leaves internal chats. What to do when someone pastes a secret.]

ACCURACY
[What must never be invented. Where to verify. What to say when you can't.]

WRITING STYLE
[5-8 concrete rules. Behaviors, not values.]

DELIVERY & ESTIMATION
[Your baseline assumptions, and the ones AI must not compress.]

PRINCIPLES
[The trade-offs you want made when nobody's watching.]

Three tips from my iterations:

1. Write behaviors, not aspirations. "Be professional" does nothing. "Never use em dashes" works instantly.
2. Treat it like code. Version it, review it with your team, and update it from real failures. Every time an output misses, ask whether the fix belongs in the instructions, in a skill, or nowhere.
3. Keep it under a page. Every line competes for the model's attention. The longer it gets, the less any single rule matters.

The whole thing is still under 500 words, and it now sits inside every AI conversation my company has.

Next up: the skills layer, and why I've mostly stopped building internal apps.