How to turn a team into a compounding knowledge organism. Not by adding AI — by re-architecting around it.
A field guide to re-architecting a company so AI is the substrate, not an add-on. Three primitives: vault (one git repo of truth) · agents (role personas with codified frameworks) · graph (your knowledge, navigable). Five bootstrap commands install the OS in ~90 minutes. Tickets stop being typed; they get drafted from transcripts and reviewed.
If you only have 5 minutes: §02 (the four shifts) → §06 (this week, day-by-day) → §10 (closing). If a CFO asks "why now?": §01 (thesis) + §08 (the 90-day milestones). If you want to act today: jump to §10.
Most companies have added AI. Few are AI-first.
The difference matters. Adding AI looks like a Slack bot, a Notion plugin, an "AI-assisted" feature on the product page. AI-first looks like the company itself running on different rails — where the way work is captured, decided, executed, and remembered is rebuilt around what AI is actually good at.
This handbook is the playbook for the second one. It's what I tell the teams I work with. It's what we run inside Cone Red. And it's what I'm asking of you, this week.
Read it as a colleague, not a manual. The instructions are concrete (you'll cd into a folder before noon Friday) but the bet is philosophical: your company gets to compound. Every conversation, every commit, every decision feeds back into a substrate that makes the next decision faster and better.
That's the prize. Here's the plan.
Before the architecture, the painkiller. This handbook isn't a thought-experiment. The reason every section below is written sharp is that the cost of ignoring it has been measured, dated, and disclosed in public — by analysts, by audited filings, by CEOs writing their own walk-back memos.
42% of organizations scrapped most of their AI initiatives in 2025 — up from 17% in 2024. The fastest-deteriorating spend category in the enterprise.
— S&P Global Voice of the Enterprise, n=1,006 (Oct 2025)
Even MIT's most-cited number, its critics admit, captures what every CFO is feeling: 95% of GenAI pilots produce no measurable P&L impact.
— MIT Project NANDA, "The GenAI Divide," Jul 2025
Klarna FY2025 disclosure: revenue per employee $1.24M, +3.6× since 2022; headcount down 49%. Cone Red's own AI-PM pipeline: replaced a $5K/mo PM, runs three projects in parallel, instant onboarding to any new domain.
— Klarna Form 6-K, Feb 19, 2026 · Cone Red internal
29% of knowledge workers admit to sabotaging their company's AI strategy — 44% among Gen Z. Tactics measured: metric tampering, performative compliance, refusing mandated tools.
— Writer × Workplace Intelligence, Apr 2026, n=2,400
Three takeaways before you read further. First: the failure rate is real and disclosed. Second: the gap to AI-first operators is also real, audited, and widening. Third: most consultants will tell you the failure is architectural. Some of it is. The harder part is that your people are not neutral evaluators of AI — when their next performance review depends on AI not working, they make sure it doesn't. McKinsey will fix your architecture. We will name what they will not.
If those four panels describe what you've been seeing without being able to name it, the rest of this handbook is the manual for the other side of the gap.
When most teams "go AI," they buy software and bolt it onto an unchanged operating model. The org chart stays. The meetings stay. The handoffs stay. The result is a faster version of the same friction — and a quiet feeling that something profound is being missed.
The thing being missed is this: AI is genuinely good at three things, and your operating model is probably hostile to all of them.
One: AI works on text. Markdown, frontmatter, plain English. It doesn't care about Notion's block model or Salesforce's object schema. The more your knowledge lives in plain text under version control, the more leverage you get.
Two: AI is a colleague, not a search engine. Treat it like a junior consultant who's read everything in your repo and forgets nothing. That's a different kind of relationship than "I typed a query." It rewards giving context, asking for thinking, reviewing output.
Three: AI compounds when memory is durable. Every conversation can become a deposit in an institutional memory bank — but only if you give it a place to land. SaaS apps own their data. Your repo doesn't. So your repo wins.
Combine the three and you get an operating model that looks deeply weird from the outside. Engineers commit ticket files instead of clicking buttons. Account managers ask the repo about a client they've never met. Product managers don't write tickets — they review tickets the AI drafted from yesterday's call. Strategy reviews happen with a virtual McKinsey partner trained on your last fifteen wins.
Those three primitives are the spine of this handbook. The rest is how to install them.
Bret Taylor — CEO of Sierra, Chair of OpenAI — put the failure mode in nine words on a podcast last year: "Big companies struggle to adopt AI because they are shipping their org charts." That's the diagnosis. AI gets bolted onto the team-by-team org chart without changing how work flows across it. The chart wins; AI looks broken. The fix isn't a smarter model. It's a different operating model — and a vault, agents, and a graph are how you install one.
If you're keeping score on what's different from how your company runs today, here are the four hinges. Three are mental, one is mechanical.
Today: ClickUp owns your tasks. Notion owns your docs. Slack owns your decisions. Google Drive owns your files. Each one charges per seat, locks you in, and answers to nobody when you ask "where's the latest version of X?"
Tomorrow: a single git repository owns everything that matters. Markdown for the body, YAML frontmatter for the structure, git for the history. The SaaS apps become render layers — pretty windows into the truth, optional and replaceable. The repo IS the company's operating system.
Today: every ticket, every spec, every status update is typed by a human who heard a thing and tried to remember the thing. The bottleneck isn't thinking — it's transcription.
Tomorrow: a transcript drops, three agents take it in turn — the transcript-extraction agent pulls pains and decisions, the PM agent synthesizes them into proposed tickets, the ticket-file generator writes the markdown — and a draft of the next sprint shows up in your editor for review. You spend your time editing what's wrong and approving what's right — never starting from a blank page. The throughput math changes by an order of magnitude.
Today: you have folders. The folders contain files. You search by filename. If you're lucky, someone tagged a thing.
Tomorrow: every document in your vault is a node in a knowledge graph. /graphify walks your repo and produces a navigable mind-map of your company's actual thinking — clusters of decisions, lineages of ideas, who-said-what-when, what's connected to what. Your knowledge becomes inspectable. Gaps become visible.
Today: when your top performer leaves, half the company's intelligence walks out with them. Tribal knowledge. "Ask Sarah, she'll know." Knowledge work that lives in heads.
Tomorrow: knowledge lives in the vault, indexed in the graph, accessible to any team member with cd company-os && claude. The next person to onboard reads what the last person learned. The institution becomes the memory. The hero becomes optional.
These four shifts are not independent. They reinforce each other. The vault makes the graph possible. The graph makes the AI agents useful. The agents make the vault grow without burning your time. The compounding makes the cost of leaving the SaaS apps trivial.
That's the loop. Now the parts.
Every AI-first company I've helped build runs on the same four layers. They're stackable, replaceable, and small enough to fit in your head.
One git repository per company. Inside it: every document, every ticket, every meeting transcript, every decision, every customer record, every playbook. The folders organize by domain (customers/, tickets/, playbooks/, transcripts/) but the universal rule is: if it matters and it isn't already here, that's the bug.
Why git? Three reasons. Version history — you can see what your company thought last quarter, last week, ten minutes ago. Branching — two people can work on the same thing without colliding. No vendor — GitHub, GitLab, self-hosted, doesn't matter. The repo is yours.
Markdown without conventions is a swamp. Markdown with thin, consistent YAML frontmatter is a database. The schema is the agreement: every ticket has a state field, every decision has an owner field, every customer-facing document has a client_visible flag. A pre-commit hook validates the schema on every change — invalid frontmatter blocks the commit. The schema is what lets you query your repo like a database without ever standing up a database.
Each role on your team gets an agent counterpart — a persona with codified principles, frameworks, and outputs. Strategy review, product management, design critique, transcript analysis, negotiation prep, presales drafting. These aren't chatbots. When you load the strategy agent in Claude Code, you're loading a McKinsey-grade consultant who reads your vault and applies frameworks to it. (Each agent has an internal codename — Conny, Prody, Riot, Conversa, Council, Preston-X — used inside the team for shorthand. The roles are what matter.)
The team uses these agents constantly. Engineers route hard architectural reviews through the strategy agent's /redteam. Salespeople run pre-call prep through the presales agent. Designers get adversarial critique before showing work to clients. The cost of a "second opinion" drops to zero.
The vault grows. After six months, you can't read all of it. Two systems make sure that's fine.
The knowledge graph (built by /graphify) turns the vault into a navigable map. Nodes are concepts, edges are co-occurrence, clusters are themes. You can ask "what topics did we work on most last quarter?" and get a visual answer. You can ask "which customers cluster with which use cases?" and see relationships you didn't know you had.
The cross-project memory (at ~/.knowledge/) is what makes Claude Code start every session knowing who you are, what you're working on, what you decided last time. It's the company's institutional memory, persistent across sessions, queryable at any moment. You bootstrap it once with /init-memory and it grows with every session.
Four layers. Each one cheap to install, expensive to skip.
Most of the architecture above sounds like infrastructure work. It mostly isn't. The init-* family in Claude Code does the heavy lift — five commands that bootstrap a project from "empty folder" to "fully instrumented AI-first OS" in under an hour.
The pattern is the same for each: you cd into the project folder, run the command, answer a few questions, and Claude Code scaffolds the layer. They're idempotent — re-running them on a project that's already partially set up just upgrades the gaps.
/init-os — bootstrap the operating systemThe first command you ever run on a new project. It detects what's already there, classifies the folder as "no OS / partial / full," and either scaffolds or upgrades. Outputs:
CLAUDE.md — the project's constitution. Who, what, why, where things live.BOARD.md — at-a-glance status board for the team.JOURNAL.md — append-only activity log.DECISIONS.md — durable decision record with rationale..claude/commands/ — project-specific slash commands..claude/agents/ — project-specific agent definitions..claude/settings.json — model, permissions, env config.You run this once per company project. After it finishes, the team can clone the repo and Claude Code in any folder will instantly understand the context.
/init-knowledge — connect to the cross-project knowledge hubBootstraps a knowledge manifest for the current project and wires it into a central knowledge directory at ~/.knowledge/. The manifest tells Claude Code: "here's what this project is about, here's its key vocabulary, here's where its sources live, here's how to find similar work in other projects."
This is what lets you ask Claude Code questions like "have we solved a problem like this before, anywhere across our portfolio?" and get an actual cross-project answer. Without it, every project is an island.
/init-memory — bootstrap the durable memory systemSets up a persistent memory layer that survives across Claude Code sessions. Built on an embedding model plus a small knowledge graph: it records facts about you, the project, your preferences, and recent decisions, then surfaces them at session start without re-prompting.
The result: when you open Claude Code tomorrow morning, it already remembers that you're working on the Q3 retention project, that Sarah is the lead, that the Tuesday meeting decided to use the long-form approach, and that you don't want to revisit the SQL question again. No re-explaining yourself.
/init-agents — install the persona libraryAudits your project's agent folder against the central persona library and installs or updates the agents that fit. By default a project gets the strategic core (strategy agent + PM agent) and any role-specific agents you point it at (design-critique for design-heavy work, presales for sales-led work, transcript-extraction whenever transcripts will land).
Running /init-agents after a few weeks of work is also how you keep the personas current — new versions of any agent ship to the central library, and this command rolls them forward in the project.
/graphify — turn the vault into a knowledge graphThe capstone. Walks through your repo (or any subset — case studies, customer folders, transcripts) and produces a navigable knowledge graph: nodes, edges, communities, an HTML viewer, a JSON export. Reveals clusters you didn't know you had. Surfaces orphans (documents nothing references — usually stale or wrong).
Run /graphify once a quarter to see how your company is actually thinking. The first run is a revelation. The second run is calibration. The fifth run is strategy.
Run them in this order: /init-os first, /init-knowledge second, /init-memory third, /init-agents when you know which roles you need, /graphify when there's enough content to be worth mapping (usually after 4-6 weeks).
Once the four layers are in place, the most powerful workflow lights up: tickets stop being typed by humans and start being drafted by a pipeline of agents that read the same things humans read.
The pipeline has three stages and a safety net.
You finish a meeting. The transcript drops into transcripts/. The transcript agent (internal codename: Conversa) parses it line by line and produces structured output: pains, decisions, action items, BANT signals, stakeholder positions, open questions. Each item is timestamped to the line range in the transcript that produced it.
This is what humans do anyway, just slower and less consistently. The agent does it in two minutes and forgets nothing.
The structured extraction hands off to the PM agent (internal codename: Prody). It reads the extraction alongside the project's existing tickets and decides: which action items become tickets? What's the right epic / story placement? What's the estimate? Who's responsible? What's blocked by what?
The PM agent outputs a proposal.yaml — a list of new tickets it wants to create, plus an "ambiguities" section listing the things it isn't sure about (e.g., "this action item could be owned by Dima or MG; defaulting to MG; please confirm").
After you review the proposal and approve (or edit), the ticket generator (internal name: PM-Vault) writes the actual ticket files into the vault. Each ticket is a markdown file with frontmatter (RACI, dependencies, state, story points, risk, sources, AI-context refs) and a body (Context, Acceptance Criteria, Definition of Done, Out of Scope, Activity Log). The first activity-log entry says: "Generated by AI-PM from transcripts/<file>.md#L40-L80."
The generator writes but does not commit. The ticket files sit in your working directory waiting for you to inspect.
When you commit, the pre-commit hook validates the frontmatter against the schema. Invalid output (missing RACI, broken dependency reference, mismatched assignee, schema violations) blocks the commit. The hook is the same gate humans pass through — AI doesn't get a pass.
You read the diff, edit anything wrong, commit. The activity log records who reviewed and approved. The transcript line-range citations let you trace any ticket back to the exact moment in the call where it came from.
The math: a 90-minute meeting produces 5-10 tickets. By hand: ~3 hours of someone's time, with details lost. By pipeline: ~5 minutes of agent work, plus 15 minutes of human review. The human spends their time reviewing, not transcribing — which is the higher-leverage version of their job anyway.
This is the loop you'll feel inside three months. The vault grows by itself. The team's writing time collapses. The signal-to-noise on tickets goes up because the PM agent, unlike a tired human PM at 5pm, actually reads the project's existing tickets before proposing new ones.
The first week is the only week with friction. Get through it and the rest is downhill. Here's the plan.
Yes, even non-tech. It's a CLI but it behaves like a chat. Tech: npm install -g @anthropic-ai/claude-code. Non-tech: same line, run it in Terminal. If it scares you, that's the point of Day 1. 30 minutes max.
git clone <url>. Then cd in. Then claude. Three commands. The repo IS the OS.
Top-level CLAUDE.md is the project's constitution. Read it like a new-hire handbook. Then ask Claude Code "summarize what you just read for me" as a comprehension test.
We screen-share. I run /init-os, /init-knowledge, /init-memory live in front of you. You see what each does, ask questions. No homework — show up and watch.
Pick a real piece of your work — a customer call to summarize, a doc to draft, a question to research. Do it in Claude Code instead of the tool you'd normally use. It will feel slower the first time. That's normal.
/journal + retro
Run /journal to log your week's work to JOURNAL.md. We meet 30 minutes Friday afternoon: what worked, what was clunky, what you want fixed for week two. The first retro is the most important.
If you've used a terminal before, this is fast. Three commands install it; three more get you working. The rest is muscle memory.
# Install (one time)
npm install -g @anthropic-ai/claude-code
# Auth (one time)
claude login
# Use (every day)
cd company-os
claude
> /whoami
> /journal
> /task init T-042From there, work is normal git: branches per piece of work (your-name/feature-description), pull requests for shared files, merge to main when reviewed. The ticket lifecycle (/task init → build → verify → complete) replaces ClickUp click-throughs entirely.
This is the part where I lose half the room. Stay with me.
You are about to use a terminal. Yes, the black box with the blinking cursor. Two reasons it's not as scary as it looks.
One: you're not coding. You're chatting. Claude Code is a chat that happens to live in a terminal instead of a browser tab. You type in plain English. It answers in plain English.
Two: three commands cover 90% of your daily use.
# Open the company repo
cd ~/Desktop/company-os
# Start Claude Code
claude
# Ask anything
> What's the latest doc on the Tampere deal?
> Summarize Tuesday's call with Doug.
> What did we decide about pricing last quarter?
> Draft an email to Mike about the Friday call.That's the daily loop. cd, claude, ask. When you get an answer, paste it into Telegram or email or wherever you needed it.
The mental shift: stop searching, start asking. You used to open Drive and search for "tampere notes." Now you open Claude Code and ask "what's the latest on Tampere?" The repo answers. Two seconds, no clicks.
If any of this feels intimidating, we'll do it together. Wednesday 90 minutes, screens shared, you watch me run the loop. Bring a real question you'd normally Google or ask in Slack. We'll answer it from the repo on the call. Most non-tech teammates flip the switch in this session — it stops being abstract and becomes "oh, that's it?"
If after the co-work you still feel stuck, we book a 1:1. Goal: by end of Week 1, you've used Claude Code at least three times for real work without help.
The technical primitives are easy. The cultural primitives are what determine whether this works in your company or rots in three months. Four norms make the difference.
Every meaningful piece of work happens on a branch. Not on main. Branches are not bureaucracy — they're the room you do work in before showing it to people. Name them your-name/what-you're-doing. They're cheap to create, cheaper to throw away.
Non-tech people: yes, you too. When you draft an email to a client, branch. When you write a meeting recap, branch. The branch is your private thinking space. Merging it back is the moment you say "this is good enough to share."
A pull request (PR) is not paperwork. It's how the team reviews work before it lands in the company's permanent record. The pattern: branch → draft work → push branch → open PR → at least one teammate reviews → merge.
Reviewers aren't gatekeepers. They're a second pair of eyes who catch the thing you missed. The norm: review within 24 hours. If you can't, say so on the PR — silence is what kills the loop.
For AI-generated content (drafts, ticket files, summaries), reviewers check facts and tone. AI hallucinates; humans catch it before it hits the vault.
When you merge to main, you're saying: this is now part of the company's truth. Future hires will read this. Claude Code will index this. The graph will see this. Be intentional. Write commit messages your future self will thank you for.
The format: type(scope): description. feat for new things, fix for corrections, docs for documentation, chore for housekeeping. scope is the area of the codebase or knowledge.
feat(tickets): I-042 — pricing decision for Tampere
fix(playbooks): correct stakeholder hierarchy
docs(customers): Doug profile update from Apr 03 callJOURNAL.md is append-only. Anyone on the team adds entries. Format is one line per item, dated and signed:
- **[2026-04-27] Dima** — Kicked off E5 vault-as-tickets. Schema doc shipped. Team brief in active/deliverables/.
- **[2026-04-28] MG** — Tailscale onboarded for the team. Doc in team/CLAUDE.md.
- **[2026-04-29] Martin** — First /pm-from-transcript run on Tampere call. 7 tickets generated, 5 approved.The journal is what feeds /progress-report, what makes weekly reviews trivial, what gives a new hire a real sense of "what's happening here lately." Five minutes a day. The compounding is enormous.
Telegram (or Slack) is for now-talk: questions that need an answer in five minutes. The journal is for forever-talk: things the company should remember in six months. Don't confuse the two. A clever observation lost in a Slack thread is gone. The same observation in a journal entry feeds the next quarter's decisions.
Everyone installs Claude Code, clones the repo, runs through the co-work session. Friction is highest now. This is normal. By Friday, every team member has used the new flow at least once for real work. Retro on Friday. Capture what was clunky, fix the top three things by Monday.
Daily journal entries become routine. First branches and PRs from non-tech team members. The pre-commit hook catches its first schema violation (it will — and that's the proof it's earning its keep). At least one transcript-to-tickets run, even if rough. By end of Week 2, no one is opening ClickUp out of habit.
End of month one, run /graphify on the vault. The output reveals: which projects are most active, which are starving for attention, which clusters are dense (mature) vs sparse (early). Use the graph to decide what to invest in next. This is the first time most teams "see themselves" — it's worth a 30-minute team session walking through the visual.
By month two, the AI-PM pipeline (transcript agent → PM agent → ticket generator) is shipping its first auto-generated tickets into the workflow. Goal: 80% of new tickets come from the pipeline; 20% are still hand-authored (the truly novel work). Hand-authoring goes from being the default to being the exception.
Around the 90-day mark, you'll have a moment that feels like magic. A new project lands. Someone asks "have we done something like this before?" Claude Code answers with a real cross-project synthesis from your ~/.knowledge/ memory. The team uses the synthesis to skip a week of discovery. That's the compounding showing up. Mark the date.
The metrics that matter aren't the obvious ones. Don't measure "AI tokens used" or "tickets per week." Measure these:
DECISIONS.md per week. More = better. Decisions you don't log are decisions you'll re-litigate.I've seen this rollout work and I've seen it fail. The failures look distinct but they share a root: people treating AI-first as a tool change instead of an operating-model change. Here are the five killers, in rough order of frequency.
Symptom: people type one-line prompts, get a one-line answer, copy it out, never come back. Fix: teach the team to converse. Multi-turn dialogues. Ask for thinking, not just answers. "Walk me through how you'd approach X" beats "give me the answer to X."
Why this is failure mode #1: Mike Leone, Principal Analyst at Omdia, named the second half of this pattern in 2025: "You test on a curated dataset, maybe a few thousand clean documents, the AI looks amazing. Then you point it at production. Fifteen years of SharePoint folders. Teams threads nobody's cleaned up since 2021. Governance overhead alone can get close to what they're spending on the technology itself." The skill gap and the data debt are the same gap. Skip either, the rollout dies in pilot.
Symptom: the team uses Claude Code to draft emails and summarize meetings but never to red-team strategy or pressure-test product specs. Fix: use the agents (strategy, negotiation, PM) for the high-leverage thinking work, not just the typing. The thinking work is where the leverage is.
Symptom: everyone agrees frontmatter "would be nice" but nobody writes the pre-commit hook. Six weeks in, the vault is messy and queries don't work. Fix: write the schema and the hook on Day 1. Treat schema violations the same as broken builds — fix immediately, no exceptions. The hook is the immune system.
Symptom: the one engineer who set everything up is the only person who can fix anything. They become a bottleneck. They get tired. They leave. The system rots. Fix: from week one, everyone touches everything. Pair on the co-work session. Document the bootstrap. Let non-tech people commit. Bus factor > 1, always.
Symptom: beautiful infrastructure, perfect agents, immaculate folder structure, and three people using it. Fix: ship the minimum viable OS in week one. Add layers as the team's actual usage demands them. /graphify on a vault with 20 docs is silly; on a vault with 200 it's revelatory. Time the layers to the team's growth.
Symptom: all the real conversations happen in chat; nothing lands in the journal; six months later nobody remembers why anything was decided. Fix: at the end of every meaningful chat thread, someone writes the takeaway into the journal. Five seconds. The principle: nothing important survives in chat. Move it or lose it.
Symptom: the rollout is mandated top-down. AI tools are deployed. Adoption is "compliance" — counted in seat licenses, not outcomes. Meanwhile, employees are running their own quiet referendum on whether AI keeps them employed.
The number, plainly: 29% of knowledge workers admit to sabotaging their company's AI strategy. 44% among Gen Z. Tactics measured: tampering with performance metrics, generating intentionally low-quality outputs, refusing mandated tools, performative compliance (Writer × Workplace Intelligence, Apr 2026, n=2,400). The same survey: 60% of executives are considering layoffs of employees who refuse to adopt AI. The threat is not paranoia. The resistance is rational.
Carl Eschenbach, CEO of Workday, named the only frame that breaks the deadlock: "Employees today believe they're competing against AI. They're not. They're competing against their peers who are using AI." If you don't make that frame explicit — repeatedly, with named examples — the rollout dies in passive resistance. Mandate without enablement is the corporate equivalent of an unloaded gun. Looks scary. Doesn't shoot.
Fix: name the threat at kickoff. Show what AI-first looks like for each role before measuring adoption. Tie performance reviews to outcomes (decisions logged, cycle-time, customer-facing wins) — never to prompt count, token spend, or seat-license utilization. Vanity metrics are the bug. If your KPI is the number of prompts your team runs, employees will write meaningless prompts to clear the bar. Meta tried it publicly in April 2026 with the "Claudeonomics" leaderboard ranking 85,000 employees by token spend; pulled it after two days. Don't be Meta.
If you avoid these seven, you'll succeed. If you don't, you won't, and the failure will look like "AI just doesn't work for our company." The failure is operational. Own it.
You've read 7,000 words about repos, frontmatter, agents, and graphs. The temptation is to walk away thinking "interesting tooling."
It isn't tooling. It's an operating model.
The companies that get this right in 2026 will compound differently. Their week-100 hire will start fully briefed. Their week-100 customer call will pull from week-1 customer learnings. Their week-100 strategy review will have a virtual partner who's read everything. Their week-100 product spec will be drafted from the customer call that ended six minutes ago.
The companies that don't will keep buying AI seats and wondering why nothing compounds.
The proof is already public. Klarna's FY2025 disclosure (Form 6-K, February 19, 2026): revenue per employee $1.24M, +3.6× since 2022, headcount down 49%, AI assistant doing the work of 853 full-time agents. That's not a press release — that's audited disclosure. Tobi Lütke, Shopify CEO, made it operational in a public memo on April 7, 2025: "Reflexive AI usage is now a baseline expectation. Before asking for more headcount and resources, teams must demonstrate why they cannot get what they want done using AI." One sentence. Whole operating model. Most companies don't have an equivalent. Write yours this quarter.
Three things to do this week:
npm install -g @anthropic-ai/claude-code.cd into it. Run claude. Ask it "what is this project?" Read what it tells you.Do those three and the rest is downhill.
I'll see you in the repo.
If you want this rolling at your company tomorrow: book a 15-min intro at cal.com/dima-levin or email dima@cone.red. First fit-call slots usually open within 48 hours. Bring one workflow you want AI-first by Friday.
— Dima Levin
Practice Lead · Cone Red AI-First Transformation Practice · 2026-04-27
cd company-os
claude
> /whoami
> /journal
> /task init T-XXX
> /task verify T-XXX/init-os # OS scaffold
/init-knowledge # connect to hub
/init-memory # durable memory
/init-agents # persona library
/graphify # knowledge graphgit pull
git checkout -b your-name/work
# do work
git add . && git commit -m "feat(scope): what"
git push
# open PR, request review@agents/conny_5/ # strategy
@agents/Prody_8Feb26/ # product
@agents/RIOT...md # design critique
@agents/Conversa.md # transcripts
@agents/negotiators/ # negotiationCodenames are internal shorthand for the role agents above. Path syntax for Claude Code.