AI Project Optimization Guide
Build AI workspaces that produce repeatable, source-backed work for one audience, one job, and one review standard.
Executive Summary
An AI project is worth building only when a recurring task has a named user, a stable source package, a repeatable output shape, and a human owner who can reject bad work. The goal is not a perfect prompt. The goal is a permissioned operating surface where the model knows what it may use, what it must cite, what it must avoid, and how success will be judged.
Reviewed May 20, 2026 against current Claude Projects, Google Workspace connector, Cowork Projects, and Claude Code memory documentation. Platform behavior changes quickly; verify connector scope, file sync, memory behavior, and sharing permissions in the live tool before promising workflow reliability.
1. Start With the Audience-Job Contract
Do not begin by uploading files. Begin by stating exactly who will use the project and what decision or deliverable it should improve. A workspace with multiple unrelated users usually becomes noisy context, not leverage.
| User Type | Primary Job | Best AI Surface | Do Not Include |
|---|---|---|---|
| Founder or operator | Turn company facts into a clean investor, customer, or hiring artifact. | Project with approved examples, voice rules, and source packet. | Raw data rooms, unverified metrics, or private investor notes. |
| Transcend advisor | Prepare repeatable portfolio support or strategic analysis. | Project plus local docs, structured templates, and review checklist. | Company-specific incidents unless the company folder is the source. |
| Analyst or associate | Run first-pass synthesis before senior review. | Project with source hierarchy, open-question log, and citation rules. | Unsupported market claims or uncited relationship context. |
| Team-wide workflow owner | Standardize a recurring internal process. | Shared project, skill, or repo rule depending on execution surface. | Personal preferences that conflict with team-owned instructions. |
Build a project only when four answers are crisp
| Question | A+ Answer | Failure Signal |
|---|---|---|
| Who is it for? | One primary audience, named in under 15 words. | "Everyone on the team." |
| What job does it do? | One recurring output or decision with an acceptance standard. | "Help with AI stuff." |
| What sources can it use? | Ranked source stack with forbidden-source rules. | "Search Drive and figure it out." |
| Who reviews it? | Named human owner with rejection reasons logged. | "The model should know." |
2. Build Context as a MECE System
Context should be organized by function. Mixing instructions, examples, facts, and corrections in one long file reduces adherence and makes later updates risky.
| Context Layer | Owns | Update Cadence | Quality Gate |
|---|---|---|---|
| Operating instructions | Role, tone, process, output shape, hard constraints. | When workflow rules change. | Specific, testable, and non-contradictory. |
| Source packet | Approved facts, data, links, docs, and citation requirements. | Every task or tranche. | Current enough for the decision being made. |
| Approved examples | Outputs the human owner would ship again. | After approval. | Labeled by audience, channel, date, and why it worked. |
| Rejection log | Bad outputs, hallucinations, tone misses, and review notes. | After rejection. | States the pattern to avoid, not just "bad." |
| Review checklist | Pre-send or pre-use validation criteria. | When defects recur. | Short enough to run every time. |
The Two-Lens Improvement Loop
Use one production project to test real tasks and one clean review conversation to challenge the project design. The clean reviewer should see the task, sources, output, and rubric, but not the messy project history. This keeps the critique sharper.
| Step | Action | Owner | Exit Test |
|---|---|---|---|
| Design | Define the source stack, output contract, and review checklist. | Workflow owner | A new teammate can explain what belongs in the project. |
| Run | Test a real task in the production project. | Project user | Output includes sources, assumptions, and explicit gaps. |
| Challenge | Ask a clean reviewer what would fail, confuse, or overfit. | Reviewer | Critique produces specific edits, not broad preference notes. |
| Patch | Update one context layer at a time and version the change. | Workflow owner | The next golden task improves without breaking prior winners. |
3. Source and Connector Rules
AI workspace quality is bounded by source authority. Connectors can help retrieval, but a connector is not a source-of-truth by itself. The project must state which source wins when files disagree.
Never Make Search the Quality Gate
For sensitive or external-facing work, "find it in Drive" is not enough. Provide the canonical files, require citations or source excerpts, and keep an open-question section for anything the model cannot verify.
| Claim Type | Minimum Source Floor | Required Model Behavior |
|---|---|---|
| Company fact | Company folder, approved memo, profile, or source artifact. | Cite the file and flag conflicts. |
| Portfolio or LP fact | Portfolio Tracker, Fund III docs, or approved CRM/Drive source. | Do not infer missing values. |
| Current platform behavior | Official vendor documentation or dated primary source. | Name the date reviewed and avoid timeless claims. |
| External-send content | Source packet plus human approval. | Surface assumptions before final copy. |
Connector Reality Check
| Surface | Useful For | Caveat |
|---|---|---|
| Claude Projects | Reusable project knowledge and standing instructions across chats. | Context is not shared across chats unless added to project knowledge. |
| Google Drive connector | Adding Drive files to chats or private projects and keeping Google Docs current. | Connector scope and organization settings determine availability; cataloged updates may lag. |
| Cowork Projects | Local folders, links, instructions, and project memory for agentic work. | Cowork projects and claude.ai projects are separate surfaces. |
| Claude Code memory | Persistent coding instructions and learned preferences. | Memory is context, not enforcement; concise rules perform better. |
4. Test With Golden Tasks
Before rollout, the project must pass tasks that represent its real workload. Golden tasks should include normal cases, edge cases, and a source-conflict case.
| Test Type | Example | Pass Criteria |
|---|---|---|
| Normal task | Draft a founder-facing note from approved company facts. | Uses the right voice, cites sources, and asks only useful follow-up questions. |
| Adversarial task | Ask for a claim not present in the source packet. | Refuses to invent and logs the missing source. |
| Conflict task | Give two files with different metrics. | Applies source hierarchy and flags the conflict. |
| Reuse task | Run the same job one week later with a new example. | Improves from the new example without drifting from rules. |
Acceptance Scorecard
| Gate | Pass Standard | Blocker |
|---|---|---|
| Audience fit | The output speaks to the named audience and their decision. | Generic prose or wrong stakeholder. |
| Source fidelity | Every factual claim maps to the source packet or is labeled as assumption. | Uncited numbers, dates, names, or policy claims. |
| Action clarity | The first screen states the recommended action or next decision. | Background before answer. |
| Security | No unauthorized data, secrets, or private material appears in output. | Data from outside the approved access surface. |
| Maintainability | A future owner knows where to update rules, examples, and rejections. | One giant prompt or unlabeled file pile. |
5. Govern Access Before Scale
Most AI project failures are not model failures. They are ownership failures: unclear permissions, weak source hierarchy, no review owner, or examples that quietly go stale.
| Risk | Control | Review Cadence |
|---|---|---|
| Sensitive data leakage | Keep secrets, raw exports, LP personal data, and company-confidential files out unless the project is explicitly permissioned for them. | Before every new source class is added. |
| Stale examples | Date every approved example and retire examples that no longer match voice, market, or policy. | Monthly for high-use projects. |
| Instruction drift | Version project instructions and change one layer at a time. | After each meaningful rejection pattern. |
| False confidence | Require assumptions, missing sources, and confidence limits in the output contract. | Every external-send workflow. |
One-Week Implementation Plan
| Day | Work | Evidence of Completion |
|---|---|---|
| 1 | Pick one audience-job pair and name the human owner. | One-sentence contract approved. |
| 2 | Assemble the source packet and forbidden-source rules. | Source hierarchy table exists. |
| 3 | Add approved examples and a rejection log. | At least three examples and three failure patterns. |
| 4 | Write the output contract and review checklist. | Checklist has five or fewer gates. |
| 5 | Run golden tasks and patch only the layer that failed. | Scorecard shows pass/blocker by task. |
6. Current Source References
Use these only to validate platform behavior. Transcend workflow rules, source hierarchy, and security decisions still come from the relevant repo, company folder, tracker, or fund document.
| Reference | Use in This Guide |
|---|---|
| Claude Projects help | Project knowledge, instructions, sharing, and context boundaries. |
| Claude Google Workspace connectors | Drive file access, project attachment, sync, cataloging, and privacy caveats. |
| Cowork Projects documentation | Local folders, links, instructions, memory, and difference from claude.ai projects. |
| Claude Code memory documentation | Persistent instructions, auto memory, rule specificity, and memory limitations. |