Claude Projects that survive a year (and ones that don't)

The four traits of a Project that survives

Across the Claude rollouts we’ve installed and audited, the long-lived Projects share a consistent shape. The dead ones share the opposite shape. Both are predictable enough that you can spot which side a Project is on inside a few weeks.

• Clear function-level scope. One Project per function - operations, sales, marketing, finance, support. Not one per task, not one for everything. The cross-function “Company Brain” Project sounds like it should work and almost never does.
• Curated context, kept under 10-20 documents. Above this size, the team stops trusting what’s in there, the model has more chance to lean on stale information, and adding more docs has diminishing returns.
• Explicit instruction prompt. One paragraph at the top of the Project’s instructions describing how the model should behave - tone, format, when to push back, what to do if something is out of scope.
• Named owner who reviews monthly. Someone’s job. Usually the function lead. 15 minutes a month is enough to keep a Project sharp.

Projects that hit all four survive. Projects that miss one or more drift, and drift kills.

Instructions vs documents

Confusion about what goes where is the most common quality issue we see. The clean rule:

• Instructions describe how the model should behave. Tone. Format. Whether to push back on the user. What level of detail to default to. What to do when a question is out of scope. How to handle uncertainty. These are behavioural rules.
• Documents are the substantive context. SOPs, templates, frameworks, examples, internal jargon. These are knowledge.

Don’t embed substantive knowledge in instructions - it’s harder to maintain and harder to share between Projects. Don’t put behavioural rules in documents - the model will treat them as content rather than guardrails. Get this split right and the maintenance burden drops noticeably.

The 15-minute monthly review

The single highest-leverage maintenance habit. The Project owner spends 15 minutes a month doing four things:

1. Check what’s been used. Skim recent chats in the Project. Are the team’s actual queries hitting what the Project knows?
2. Prune stale documents. Has anything in the context been superseded? Out of date? Anything the team doesn’t trust any more? Remove it.
3. Update instructions if behaviour has drifted. Is the model defaulting to the wrong tone? Producing too much or too little? Tweak the instruction paragraph.
4. Note what’s been working. If a particular prompt pattern keeps producing great results, that’s a candidate for a custom Skill. Skills compound; loose prompts don’t.

That’s the whole job. Done monthly, the Project stays sharp. Skipped for three months, the rot starts.

When to split a Project

Two signals say a Project should split into two narrower ones:

• The context has grown beyond ~20 documents and you can’t confidently say what’s in there
• The team is using the same Project for materially different kinds of work that need different tones, formats or guardrails

Splitting is cheap. Don’t treat it as failure - treat it as maturation. A six-month-old Operations Project that splits into “Operations - Internal” and “Operations - Customer” is a sign the team is using AI seriously, not a sign something went wrong.

When to retire a Project

When the team stops opening it. The signal is real - if a Project hasn’t been touched in 30 days, either the function it served has changed (split or rebuild it) or it was never the right shape (delete it). Long-dead Projects sitting in the workspace dilute trust in the rest of them, and they look like clutter to new joiners.

Pruning is part of healthy Project maintenance. Two or three retirements a year is normal in a thriving rollout.

What doesn’t help (even though it sounds like it should)

A few patterns we see owners try that don’t actually keep Projects alive:

• Adding more documents. Almost always makes things worse, not better. The team trusts smaller, sharper context more.
• Long instruction blocks. Instructions over a few paragraphs get ignored by the model and forgotten by the team. Tighter is better.
• Multiple owners. “The whole team owns the Project” means nobody owns it. Single name.
• Quarterly reviews instead of monthly. Three months is too long for AI maintenance. Drift compounds in that window.

How XLev sets Projects up

Setting up function-level Projects with the right scope, context, instructions and named owners is part of every Claude Implementation we run - typically weeks 2-4 of the engagement. We hand each Project off with the maintenance habit installed: a named owner, a monthly review meeting on their calendar, and a checklist they can run through in 15 minutes. See Claude Implementation for the full service detail.