Old way: the person on your team who's been at the company since you were in high school knows the one-off customer contracts, the fire-drill playbook, and the right external contacts that keep a bad week from becoming a lost account — and every one of those decisions waits in a queue behind that person's calendar.

New way: that same knowledge lives in a folder your company (or specific team) actually owns, wired up with a handful of instruction files, so any teammate (with the help of Claude) can answer the question and draft the proposal.

Key Takeaways

• The interaction model flips from "ask the person" to "ask the folder." Instead of a customer question sitting unanswered because the one person who knows the pricing rules is out for the weekend, anyone on the team opens Claude, points it at the shared folder, and gets an answer built from the same rules that person would have used.

• What you actually need is small. Any Claude tool that reads local files — Claude Code, Claude Desktop, or Cowork — plus a shared drive your team already uses (Google Drive, OneDrive, Dropbox) or a git repo if you want version history. Don’t pay for a CRM or dataroom, even if the VDR sales team takes you out to dinner.

• The real prerequisite is a willing owner. This system only works if whoever holds the tribal knowledge — usually the founder or an ops lead — actually sits through a 10–20 minute interview per topic. If you skip that step, you’ll have a system with severe brain rot.

• There's no access control. Anyone who can open the folder can read everything in it — emails, approval thresholds, customer-specific concessions included. If your business has information that shouldn't be visible to every seat (junior reps seeing exact cost basis, for instance), this system doesn't have an answer for that out of the box. That requires some custom tinkering from you :)

• It plugs into whatever your team already runs on. The folder itself can be surfaced inside Slack, ClickUp, or Asana channels — but none of that is required to get value on day one.

• Skills become incredibly useful. A skill is a small instruction file — "when someone asks for X, use these files, follow these rules, and say whether it needs approval or not." That last bit (the approval check) combined with the encoded standard procedure makes a skill safe to hand to a whole team or a new employee.

• Output lands as plain files inside the same folder. The interview produces a markdown document. The skill-creation prompt produces a skill file. Nothing disappears into a proprietary, separate database — which is the entire point of the exercise, since the standard alternative (a CRM, a help desk tool, a chatbot subscription) keeps your knowledge in their database instead of yours.

• This is built on top of Claude Skills and IS NOT a packaged Anthropic product — something worth remembering before you treat any specific step here as a fixed feature. The underlying primitives (file reading, Skills, a shared folder) are stable, but the exact assembly is something you build and maintain yourself, and its quality depends entirely on how well you build it.

Step-by-Step Workflow: Setting Up and Using a Company (or Team) Brain

I’d budget one 6-hour block for the initial build, plus 10–20 minutes per topic for each interview. No coding required.

We created Company Blue Chip — a fictional CPG company selling healthy snack bars — as a running example to help you follow along.

1. Open your Claude tool and create the folder. Claude Code, Claude Desktop, and Cowork all work, since the only requirement is the ability to read files in a folder.

   Blue Chip: the ops lead creates a single "Company Brain" folder and starts dragging in whatever already exists — the current wholesale and distributor price lists, the customer/account list sorted by channel, the co-packer contract with its MOQs and lead times, the new-retailer onboarding form, and a handful of Slack threads and emails where a promo discount or a short-ship decision got resolved. If you have any call transcripts, these are gold.
   
   

2. Decide where the folder lives and who can see it. Put it in whatever shared drive the team already uses (Google Drive, OneDrive, Dropbox) so every employee's Claude instance can point at the same location. If the team is technical, a git repo gets you change history for free.

   Blue Chip: the folder goes into the shared drive the commercial team already uses. Before sharing further, someone deliberately holds back the raw per-SKU cost-basis spreadsheet — the team has decided that's the one thing sales reps shouldn't see, even though list prices, tier discounts, and MOQs all stay in.
   
   

3. Ask Claude what the company knows and what's missing. "What does this company know, and what important knowledge is missing?"

   Blue Chip: Claude reports back that pricing tiers, the co-packer's MOQs, and the account list are all well documented — but flags that how trade-spend and promo discounts actually get approved, and how private-label and co-manufacturing pricing gets set, exist only in the head of sales.
   
   

4. Run the interview to capture what's missing. For each gap: "You are helping me get my wholesale and distributor pricing rules out of my head and into a document my team can use. Interview me one question at a time until you know enough to price any retail or distributor order yourself, and then write it into the folder as a pricing rules document."

   Blue Chip: the head of sales answers roughly 10 questions — tier structure (D2C vs. independent retail vs. regional chain vs. distributor), standard promo discount bands, MOQ-based price breaks, who can approve a discount below the “best and final offer” floor, how slotting fees get quoted. Fifteen minutes later, a complete wholesale pricing-rules document exists in the folder — knowledge that lived only in her head now belongs to the entire team.
   
   

5. Turn the documented process into a skill, with an explicit approval clause. "Create a skill called 'price a wholesale order.' When someone asks what to quote a retailer or distributor, price it using the pricing rules, account tier, and current promo calendar in the company brain folder. Show the discount stack step by step. Check the margin floor and end with whether it needs the head of sales' approval or not." The approval clause is the single most important line in that prompt.

   Blue Chip: the resulting skill is saved into the same shared folder and is immediately usable by anyone — customer service, the ops lead, account managers — the moment their Claude instance points at that folder. No separate rollout or training needed.
   
   

6. Push skills centrally if the team is on a Claude Teams plan (optional). This distributes the skill file to every seat automatically vs having to share and download/add each skill file.
   
   

7. Run the skill against a real request. "GreenAisle Regional wants to increase their standing order from 200 to 450 cases of the Peanut Butter Cocoa bar ahead of their fall reset, and a competitor has already quoted them — what should we send back?"

   Blue Chip: the skill returns the per-case price, confirms the account's tier and margin floor still hold at the new volume, and states plainly that no approval is needed — that number can go out today. It also flags two judgment calls the pricing math alone doesn't settle: whether to upgrade the account to the next tier to lock in the volume, and how the timing lines up with an already-scheduled fall price change. The routine 90% — the price itself — is answered in seconds; the two real judgment calls are handed to the employee.
   
   

8. Edit the skill. If the skill runs unsuccessfully, is not built for the current use case, or generates an output that’s clearly wrong, feed that feedback to Claude. Skills are not built to self-improve unless you provide specific feedback.
   
   

9. Run the quit test. "If our head of sales left tomorrow, what would we need to know to manage our top five retail accounts without her?"

   Blue Chip: the brain answers confidently on pricing, but comes back short on relationship context — which buyer prefers a call over email, which account has an informal exception nobody wrote down, who the deputy should be. That shortfall becomes next week's documentation task instead of a surprise the week she actually gives her two-week notice.

How It All Fits Together

The Company Brain isn't a new product sitting alongside your existing Claude setup — it's a specific way of combining two things Claude already gives you: file access and Skills. The folder is the knowledge layer (equivalent to what you might otherwise put in a Claude Project's knowledge base, except here it's a literal shared folder your whole company controls rather than something scoped to one Claude account). Skills are the behavior layer — the same reusable-instruction mechanism you'd use for any other repeatable workflow, just written by whoever actually does the job.

New Skills Can Ship With Bugs

When a skill is generated in one pass from a prompt, it can contain a logic error that does not show up until someone asks it to handle something the original instructions did not account for. Nothing in the workflow guarantees those scenarios get tested before the skill is used for a real customer-facing answer.

In the source demo, a newly built “price a quote” skill was run against a real order. Midway through the answer, the system caught and flagged a bug in its own discount logic because the requested volume exceeded available inventory, something the skill had not been explicitly designed to handle. The quote still came out correctly because the model reasoned around the gap in real time, but the underlying skill file had to be fixed manually afterward.

What bothers me more is how the bug was found. It surfaced because that particular order happened to expose the problem, not because the skill had been tested against a broader set of scenarios before anyone used it. If the first unusual request is a strange tier combination or a rounding rule that never came up during the interview, you may not find the gap until the skill gives someone the wrong number.

Practically, I would treat every newly written skill as a draft until you have tested it against a few scenarios you know could cause problems. Try a volume that crosses a margin floor, a request that exceeds current inventory, or an account that does not fit neatly into an existing tier. Testing only the example you used to build the skill does not tell you much about how it will behave once people start using it.

That does not change the broader value of the setup. A folder of documents and a handful of plain-English skill files can still turn “wait for the one person who knows” into “ask Claude and get a defensible answer in seconds,” without adding another software subscription or writing code. You just need a few operating rules around it: be deliberate about what goes into a shared folder, review newly written skills before they are used with customers, and rerun the quit test periodically as the business and the underlying processes change.