How to Structure Claude for Your Business: Skills, MCP, and the Instruction Architecture That Actually Scales

The one-project trap

I watched it happen again last month. A company creates a Claudeproject called “Company AI” or “Marketing Assistant.” They paste in their website, a few product descriptions, maybe a brand guide PDF. The system prompt says something like “You are a helpful assistant for [Company Name]. Use a professional tone.”

And it works. Sort of. Claude knows the basics, drafts emails that sound vaguely on-brand. But by week three? The cracks show:

• Sales uses the same project for proposals, cold emails, and CRM summaries, and the instructions that help with one hurt the others
• Someone updates the pricing sheet but forgets to update the knowledge file, so Claude quotes last quarter's rates
• The project instructions are now 3,000 words of accumulated patches, and nobody remembers which rules are still relevant
• Two departments have created their own projects with conflicting versions of the company description

Have you noticed this at your company? I call it the one-project trap. It's why most teams plateau at “Claude is useful for drafts” and never reach “Claude runs our workflows.”

The three-layer architecture

The fix is the same pattern Katherine Yeh describes for design work, adapted for business operations. Three layers, each with a clear job.

Layer 1: Reference knowledge

This is everything Claude needs to know about your business. Not what to do, just what to know. It's the foundation every workflow builds on.

I split reference knowledge into two buckets:

Company-wide references get shared across every project and department:

• Brand voice and tone — Not just “professional,” but specific patterns. Do you use contractions? Do you address the reader as “you” or by role? What words do you avoid? What's the difference between how you write to customers vs. partners?
• Product and service specs — What you sell, how it works, pricing tiers, technical capabilities. This is the “source of truth” that every project references.
• Compliance and legal rails — What Claude must never say. What claims require disclaimers. What data can be shared externally. What regulatory language is mandatory in certain contexts.

Domain-specific references stay within a department or function:

• Sales: competitor positioning, objection handling playbook, pricing negotiation boundaries
• Procurement: vendor evaluation criteria, approved supplier list, RFQ templates
• Customer service: escalation policies, SLA definitions, common issue resolution scripts
• HR: job description standards, compensation bands, interview scoring rubrics

Here's the principle that makes it all work: separate knowledge from instructions.Yeh puts it well. Specs answer definitional questions (“what is our return policy?”) while workflow instructions handle judgment calls (“how should we respond to this complaint?”). Most companies mash these together. Separating them means you can update a policy without touching every workflow that references it.

Layer 2: Capability workflows

This is where Claude learns what to do. Each capability is a specific, repeatable workflow, not a vague description of a role.

Bad: “You are a helpful sales assistant.”

Good: “Generate an offer document. Pull the customer's history from the CRM connector. Reference the current pricing sheet. Use the formal proposal template. Include delivery timelines based on current production capacity. Flag any line items that exceed the customer's credit limit.”

See the difference? The second version tells Claude exactly what “done” looks like. A well-structured capability specifies:

• Trigger — What initiates this workflow? A user request, a scheduled event, a data change?
• Inputs — What information does Claude need? Where does it come from?
• References — Which Layer 1 knowledge files should Claude consult?
• Steps — The specific sequence of actions, in order
• Tools — Which MCP connectors or external tools are needed?
• Output format — What does the finished product look like?
• Review gates — Where does a human check the work before it goes further?
• Edge cases — What happens when data is missing, conflicting, or outside normal ranges?

At Orient Printing & Packaging, I deployed 11 capabilities in the first engagement. Each one is a distinct workflow with its own instructions. There's no monolithic “Orient AI” project. The offer generator references the pricing knowledge file, the product spec sheet, and the proposal template, but it doesn't know anything about HR policies. It doesn't need to.

Layer 3: Connectors (MCP)

This is the integration layer. Model Context Protocol servers that connect Claude to your actual business systems.

Common connectors I build:

• ERP connectors — Read inventory levels, production schedules, cost data. Write back order updates.
• CRM connectors — Pull customer history, deal stage, contact information. Log interactions.
• Document systems — Access templates, past proposals, knowledge bases from SharePoint, Google Drive, or Notion.
• Email and calendar — Read incoming requests, draft responses, schedule follow-ups.
• Custom databases — Any system with an API can become an MCP server.

The key insight about MCP is that it creates clean boundaries between what Claude knows (Layer 1), what Claude does (Layer 2), and what Claude can reach(Layer 3). Changing your CRM from Salesforce to HubSpot? Rebuild one connector. Every workflow that touches customer data keeps working without a single edit.

For a deeper dive on MCP, read my plain-English explainer.

Why the layers matter

I know. This might feel like overkill if you just want Claude to help with emails. But the layers solve three problems that kill every single-project deployment I've seen:

Drift. Without shared reference files, every project slowly develops its own version of reality. Sales says the product does X. Marketing says it does Y. Customer service says something else entirely. A single reference layer forces one source of truth.

Maintenance. When your pricing changes, do you want to update one knowledge file, or hunt through 15 projects to find every place the old price appears?

Quality at scale.A prompt that works for one use case breaks when you stretch it across five. Separate capabilities with explicit specifications produce consistent results on the 500th run, not just the first. I learned this the hard way, after watching a “catch-all” project produce increasingly bizarre outputs as more teams piled their needs into it.

What this looks like in practice

Here's a simplified version of the architecture I deployed at a 200-person manufacturer:

Notice how it flows: the offer generator (L2) references the pricing rules and product catalogue (L1) and uses the ERP connector (L3) to pull real-time data. If the pricing rules change, the offer generator automatically uses the new numbers. If you swap SAP for Oracle, you rebuild the connector but the workflow stays identical.

Getting started (without boiling the ocean)

You don't need to build all three layers at once. That would be overwhelming, and honestly, counterproductive. Here's the progression I recommend:

Week 1: Start with Layer 1. Gather your core reference materials: brand guide, product information, compliance rules. Upload them to a Claude project as knowledge files. Even without workflows or connectors, this immediately makes every conversation better because Claude has accurate context instead of guessing.

Week 2: Build your first capability.Pick the workflow that eats the most time. Write explicit instructions following the trigger → inputs → references → steps → output → review pattern. Test it 20 times. Find the edge cases. Refine. This part is more tedious than it sounds, but it's where the real value lives.

Week 3+: Add connectors. Once a workflow is reliable with manually provided data, add MCP connectors so Claude can pull the data itself. This is the step that turns Claude from an assistant into an agent.

Month 2: Scale. Add more capabilities, one at a time. Each new workflow builds on the reference knowledge you already have. The cost of each new capability drops because the foundation is in place. This is where the compounding kicks in and things start feeling almost unfair.

Why instruction engineering matters more than you think

Something in Katherine Yeh's article struck me. She's a designer, no coding experience, and she built a scalable Claude architecture in four weeks. The core skill wasn't technical. It was architectural thinking: deciding what goes where, what references what, and how pieces compose.

That's what I call instruction engineering. It's not prompt writing. It's not software engineering. It's something new that sits between the two: understanding your business deeply enough to decompose workflows into structured specs, and understanding Claude well enough to write instructions that produce reliable results at scale.

The companies that figure this out build a compounding advantage. Every workflow they deploy makes the next one cheaper to build, because the reference layer grows and the connectors multiply.

The companies that don't? They end up with 20 disconnected Claude projects and a team that says “AI is useful but not transformative.”

The difference is architecture. And it's a gap I'd love to help you close. Start a conversation →