Here is the pattern I see constantly. A team subscribes to Claude Pro or Claude for Teams. They use it for a few weeks. Early results are promising — the model is clearly capable. Then something shifts. The outputs start feeling inconsistent. Same question, different answer. Good one day, generic the next. One person on the team gets great results; everyone else gets mediocre ones. Leadership starts asking what the ROI actually is.
The natural response is to blame the prompts. Write better prompts. Try harder. Add more detail. So the team spends two months chasing prompt engineering tips. Some things improve marginally. The fundamental inconsistency stays.
The problem is almost never the prompts. It's the layer beneath the prompts that's missing.
The 60/30/10 rule nobody tells you
Here is a frame I use with every team I work with. Production AI systems — the ones that actually produce reliable, specific, useful outputs — are roughly:
- 60% structure. How the work is organized. What context Claude has before you type a single word. What files it can see, what conventions you've established, what the project is and who it's for.
- 30% prompting. How you ask for things. Task framing, specificity, format guidance.
- 10% the model itself. Which model you use, how you invoke it, the actual API or chat interface call.
Most teams invest almost exclusively in the 10%. They agonize over prompts (the 30%) while ignoring the 60% entirely. Then they wonder why the outputs feel like they came from someone who doesn't know them, their work, or their standards — because from Claude's perspective, every session starts fresh. It doesn't know any of those things. You never told it.
The model is not the product. The system around the model is the product.
What "structure" actually means
I don't mean custom software. I don't mean a $200,000 platform build. I mean something much simpler: a set of plain text files that give Claude the context it needs to do your work the way you want it done.
The most important of these is a file called CLAUDE.md.
Claude Code — the terminal and VS Code interface that reads your actual file system — automatically loads CLAUDE.md when it opens a folder. This is the project's instruction document. Not a prompt. Not a system message you paste at the start of every session. A permanent, editable document that lives in the folder alongside the work.
A well-written CLAUDE.md tells Claude things like:
- What this project is and who it's for
- What the conventions are (voice, format, naming, output structure)
- What tools are in use and what the technical stack looks like
- What to avoid, what to protect, what to flag before doing
- Where the relevant files live and how the work is organized
With that file in place, the model isn't starting from zero every session. It knows the project. You stop explaining the background every time. Outputs start feeling like they came from someone who's been paying attention — because structurally, they did.
The three-layer system
A CLAUDE.md file alone gets you most of the way there. But the teams that get the most out of Claude are typically running a three-layer system:
- The root
CLAUDE.mdfile. The top-level routing map. Tells Claude what's in the workspace, what the rules are, and how to navigate the folder structure. - Workspace context files. Each project or major work area has its own context document. Client-specific conventions, project background, standing instructions for that particular body of work.
- Task-level routing. Specific instructions for specific types of tasks — prompts and context that get loaded on demand for recurring work like proposals, reports, content drafts, or research summaries.
None of this requires code. No APIs, no engineering team, no build process. It's folder architecture and markdown files. The same tools the team already uses, organized so Claude can actually use them too.
Without the structure
- Every session starts from zero
- Repeating the same background every time
- Outputs don't match your voice or format standards
- One good user, everyone else gets mediocre results
- Prompt quality drives everything
With the structure
- Claude knows the project before you type a word
- No pasting, no re-explaining, no context buildup
- Outputs match your conventions, audience, and process
- Consistent results across the whole team
- Structure does the heavy lifting; prompts refine it
Why most teams skip this
Because nobody sells it to them. Anthropic sells the model. Prompt engineering courses sell techniques. The idea that the most valuable investment is a folder structure and a markdown file doesn't generate much revenue for anyone, so it doesn't get much airtime.
There's also a subtle misdiagnosis happening. When outputs are inconsistent, the instinct is to fix the last thing you touched — the prompt. The structure is invisible precisely because you never built it. You can't see what isn't there.
And frankly, building this layer takes a few hours and a bit of thought. It requires someone to make decisions about how the work is organized, what the conventions are, and what Claude actually needs to know to be useful. That's not hard, but it does require attention and ownership. Most teams would rather buy a tool than make decisions.
A team pays for Claude subscriptions, uses it from the chat interface with no persistent context, gets inconsistent results, concludes that "AI doesn't work for us," and either abandons it or commissions a $150,000 custom tool. Both outcomes could have been avoided with a folder and a markdown file.
What it looks like when it's working
Here's what a team running this system well actually experiences:
An account manager opens a client folder in VS Code. Claude Code loads automatically. It already knows the client's name, the engagement type, the tone conventions, the preferred output format, and the standing instructions for that client's work. The manager asks it to draft a weekly status update. First draft is 80% there. Two rounds of iteration, five minutes total. Done.
A different person on the same team opens the same folder. Same experience. The institutional knowledge isn't locked inside the one person who set everything up. It's in the files, where anyone can read it, update it, and use it.
When a convention changes, they update the context file. The whole team's outputs change on the next session. No retraining, no re-prompting everyone, no institutional drift.
That's not magic. It's architecture. It's the 60% that most people skip.
The question worth asking
Before you conclude that Claude isn't working for your team, or that you need a custom tool, or that you need to hire a prompt engineer: ask whether you've built the layer underneath the prompts.
- Does Claude know what project it's working on before you type anything?
- Does it know your voice, your format standards, your naming conventions?
- Does it know what to avoid and what to protect?
- Can someone new to the team get consistent outputs, or only the one person who built their own context in their head?
If the answer to most of those is no, the problem isn't the model. It isn't even the prompts. It's the 60% that's missing.
Field notes
New Ark Digital runs on this system. Our own workspace — client work, proposals, operations, internal projects — is structured so Claude knows what it needs to know before we ask it anything. It's not impressive to look at: some folders, some markdown files, a routing table. But it's the reason we get reliable, specific outputs across different projects, different clients, and different types of work. The architecture is the product. The prompts are just the daily use of it.
R.P.
