The Two-Way Problem: Getting Tacit Knowledge In and Out

You've been in your role for three years. You know why things are done a certain way—not because it's written down, but because you were there when the decisions got made.

Maybe you're a lawyer who knows which judges prefer concise briefs versus detailed ones, which opposing counsel will negotiate in good faith, and which contract clauses your firm has learned to avoid after a costly dispute five years ago. Maybe you're a marketing director who knows that this particular client hates the word "synergy," that their CEO responds better to data than stories, and that the Q4 campaign failed not because of the creative but because of timing with their product launch. Maybe you're a research scientist who knows which methodologies your reviewers trust, which citation styles signal credibility in your field, and which collaborators actually respond to emails.

None of this is documented. It lives in your head, in email threads nobody will ever search, in the institutional memory of colleagues who were there when the decisions got made.

Now you're working with AI. It can read your documents. It can follow your instructions. But it doesn't know why. It doesn't carry the weight of decisions that shaped your practice. It treats every contract clause, every client, every methodology as equally neutral—without the context that makes your expertise valuable.

This is the Two-Way Problem—and solving it is the difference between an AI that helps you and an AI that actually understands your work.

The Two-Way Problem

Greg Foster, writing about the real bottlenecks in AI-assisted work, identified what he calls the Two-Way Problem. It's not about prompts or context windows. It's about knowledge transfer in both directions.

Direction	Challenge	Why It's Hard
Professional -> AI	Transfer tacit knowledge	Documentation records what someone thought to write down, not the dozens of micro-decisions that shaped current practice
AI -> Professional	Extract understanding	Reviewing AI-generated work takes different cognitive effort—you're reverse-engineering intent from output rather than following reasoning

Both directions matter. If you can't get your knowledge into the AI, it makes decisions that violate unwritten rules. If you can't extract understanding from what the AI produces, you're using deliverables you don't fully comprehend.

Most professionals focus only on the first direction. They spend hours crafting instructions and system prompts. But the second direction—actually understanding what the AI created—gets neglected. The result is work products where the AI understands the reasoning better than the humans responsible for defending or maintaining them.

What IS Tacit Knowledge?

Tacit knowledge is what experienced professionals carry that never makes it into documentation. It's the unwritten rules—the stuff you'd tell a new colleague over coffee but would never think to write down.

Examples of tacit knowledge across domains:

Domain	Examples
Legal	Which judges prefer concise briefs; which opposing counsel negotiates in good faith; which contract clauses have caused problems before; how to read a client's risk tolerance
Marketing	Which clients hate certain buzzwords; what creative approaches have failed with this audience before; timing considerations that aren't in the brief; internal politics about brand voice
Research	Which methodologies your field's reviewers trust; which journals actually read submissions thoroughly; which collaborators deliver on time; citation conventions that signal credibility
Consulting	Which stakeholders have real decision-making power; how much detail this client wants; which recommendations will actually get implemented; historical context on failed initiatives
Business Analysis	Which processes are actually followed vs. documented; who the real subject matter experts are; which systems have unreliable data; political sensitivities around process changes
Software	Why certain architectural decisions were made; which parts of the codebase are dangerous to touch; performance vs. readability tradeoffs in specific areas; historical incidents that shaped current practice

What tacit knowledge is NOT:

• Documented procedures and policies
• Written style guides and standards
• Formal decision records
• Onboarding materials and handbooks

The distinction matters because AI systems can read documentation. What they can't read is the knowledge that never got documented—the context that makes documentation make sense.

A Legal Example: Your instructions say "Use standard indemnification language." That's explicit knowledge. But the tacit knowledge is: "We use standard language except for this client, who had a $2M claim two years ago, so we always add carve-outs for gross negligence—but only on service agreements, not licensing deals." Without that context, AI might use standard language where it shouldn't.

A Marketing Example: Your brand guide says "Use conversational tone." That's explicit knowledge. But the tacit knowledge is: "Conversational means different things for different audiences—our B2B clients want professional-conversational, while the consumer brand can be casual. And the CEO hates exclamation points." Without that context, AI might produce copy that's technically on-brand but wrong for the audience.

A Software Example: Your CLAUDE.md says "Use async/await for database calls." That's explicit knowledge. But the tacit knowledge is: "We switched to async because of connection pool issues during traffic spikes, but only on the product catalog service. The user service still uses sync calls because it's read-heavy and the added complexity wasn't worth it." Without that context, AI might refactor code that's actually fine.

Strategies for Getting Knowledge IN

The first direction of the Two-Way Problem: how do you transfer what's in your head to the AI?

Strategy 1: Structured Context Documents for AI Consumption

Most professional documentation is written for humans. It's full of context that assumes shared experience, references that require interpretation, and explanations that build on knowledge the reader already has.

Documents for AI consumption need to be different. Let's look at examples across several domains:

---

Legal Context Example:

For Humans:

## Client: Acme Corp

Standard enterprise client. See the Henderson matter for background on their risk tolerance.

For AI:

## Client: Acme Corp

### Relationship Context

- Client since 2019, mid-market manufacturer
- General Counsel is highly risk-averse after the Henderson litigation (2021)
- Prefers plain language over legalese—CEO reviews all agreements personally

### Contract Preferences (Non-Negotiable)

- ALWAYS include gross negligence carve-out in indemnification clauses
- Limitation of liability must specify actual damages cap (they won't accept consequential)
- Arbitration clause required—they had bad experience with jury trial in Henderson

### Historical Context

- The Henderson matter cost them $1.8M—any similar liability language will be flagged
- They terminated their previous firm over a missed filing deadline—punctuality matters
- CFO overshadows GC on financial terms—get buy-in from both

---

Marketing Context Example:

For Humans:

## Brand Voice

Conversational but professional. See last quarter's campaign for examples.

For AI:

## Brand Voice: TechStart

### Core Voice Principles

- Conversational but not casual (no slang, no exclamation points—CEO hates them)
- Confident without arrogance (avoid "leading" or "best-in-class")
- Technical credibility (can use jargon with developer audience, plain language for executives)

### Constraints (Non-Negotiable)

- NEVER use: "synergy," "leverage" (as verb), "disrupt," "game-changing"
- ALWAYS use Oxford comma (brand guide exception from AP style)
- Product name is "TechStart" not "Techstart" or "Tech Start"

### Audience-Specific Adjustments

- Developer content: Can be more technical, humor OK
- Executive content: Formal tone, emphasize ROI and case studies
- Social media: Shorter sentences, more direct, still no exclamation points

### Historical Context

- Q2 2024 campaign with casual tone underperformed—audience found it unprofessional
- Competitor MegaTech owns "innovative"—avoid that word in positioning
- Founder's story resonates—reference bootstrapping narrative when appropriate

---

Research Context Example:

For Humans:

## Methodology

Standard qualitative approach. IRB approved.

For AI:

## Research Methodology: User Behavior Study

### Methodological Framework

- Grounded theory approach (Strauss & Corbin tradition, not Glaser)
- 30-minute semi-structured interviews, recorded and transcribed
- Theoretical sampling until saturation (typically 15-25 participants in this domain)

### Constraints (Non-Negotiable)

- NEVER deviate from IRB-approved protocol without amendment
- Informed consent must be documented before any data collection
- Participant identifiers use P001-P999 format (never names, even in internal docs)

### Field-Specific Conventions

- This journal prefers APA 7th edition with DOI links
- Reviewers in this subfield expect reflexivity statements
- Mixed methods requires separate findings sections (not integrated)

### Historical Context

- Previous study (2022) was criticized for insufficient member-checking—always include
- Lab's reputation is methodological rigor—never shortcut triangulation
- Funding agency expects quarterly progress reports—design timeline accordingly

---

Software Context Example:

For Humans:

## Authentication Architecture

We use a microservices approach for auth, similar to what Netflix described in their 2019 blog post.

For AI:

## Authentication Architecture

### Why This Design

- Original monolithic auth couldn't scale past 10K concurrent users
- Q4 2023 incident: 47 minutes downtime during Black Friday traffic spike
- Solution: Decomposed into 3 services with circuit breakers

### Current State

- auth-gateway: Handles all external auth requests, rate limits at 1000 req/s
- token-service: Issues and validates JWTs, 15-minute expiry
- session-store: Redis-backed, 24-hour session TTL

### Constraints (Non-Negotiable)

- NEVER modify token-service without security review
- All auth changes require integration tests against production-like load
- Circuit breaker thresholds: 50% failure rate triggers open state

### Historical Context

- The "legacy_auth" module still exists for enterprise customers on old contracts
- It will be deprecated Q3 2025—don't invest in improvements
- If you see legacy_auth patterns in new code, flag it

---

The AI versions across all domains share common characteristics: they're explicit about constraints, include the "why" behind decisions, and call out what NOT to do. They're not trying to be comprehensive—they're trying to transfer the tacit knowledge that shapes decisions.

Strategy 2: Encoded Preferences (Examples Over Rules)

Rules are ambiguous. Examples are concrete.

Rule-based (weak):

## Style Guide

- Write clearly
- Be professional
- Follow best practices

AI already knows these generic principles. They don't help.

Example-based (strong):

Here's how this works across different domains:

---

Legal Writing Example:

## Brief Writing Style

When summarizing case holdings, follow this pattern (from Smith v. Jones brief, p.12):

GOOD: "The Court held that contractual ambiguity must be construed against
the drafter where the non-drafting party lacked bargaining power. Smith v. Jones,
123 F.3d 456, 461 (9th Cir. 2023)."

NOT this pattern (from the Johnson draft - do not copy):

BAD: "The Court said contracts should be interpreted fairly."

---

Marketing Copy Example:

## Product Description Style

When describing features, follow this pattern (from Q3 landing page):

GOOD: "TechStart processes your data in 3 seconds—not 3 minutes.
That means your team reviews insights while they're still relevant,
not after the meeting already ended."

NOT this pattern (from the rejected Q1 copy):

BAD: "Our innovative, best-in-class solution leverages cutting-edge
technology to disrupt the data processing space."

---

Research Writing Example:

## Findings Presentation

When reporting qualitative results, follow this pattern (from published Chen study):

GOOD: "Participants consistently described a tension between organizational
expectations and personal values. As P007 noted, 'I know what the policy
says, but that's not how things actually work here.'"

NOT this pattern (from the rejected first draft):

BAD: "Many participants felt conflicted about their work."

---

Software Example:

## Error Handling Style

When writing error handling, follow this pattern (from services/payment.ts:142):

```typescript
// GOOD: Specific error types with context
try {
  await processPayment(order);
} catch (error) {
  if (error instanceof PaymentDeclinedError) {
    logger.warn("Payment declined", {
      orderId: order.id,
      reason: error.reason,
    });
    return {
      success: false,
      retryable: true,
      userMessage: error.userFacingMessage,
    };
  }
  throw error; // Unknown errors are bugs - fail loudly
}
```

NOT this pattern (from services/legacy/checkout.ts - do not copy):

```typescript
// BAD: Generic catch, swallowed errors
try {
  await processPayment(order);
} catch (e) {
  console.log("payment failed");
  return false;
}
```

---

The example-based versions give AI a concrete reference. When it encounters similar situations, it can pattern-match against the good example rather than interpreting vague rules.

Strategy 3: Memory Systems

Memory systems capture preferences and knowledge as they emerge during conversations, then persist them for future sessions.

The OpenAI Memory Lifecycle:

inject -> reason -> distill -> consolidate

1. Inject: At session start, render saved memories as context (YAML frontmatter + Markdown)
2. Reason: Agent uses memories for decisions throughout the session
3. Distill: During conversation, capture new durable preferences
4. Consolidate: After session, merge new memories into persistent storage

This lifecycle means knowledge accumulates over time. You don't have to pre-specify everything upfront. The system learns your preferences as you work.

Practical implementation:

Most AI tools don't have built-in memory persistence (yet), but you can implement the pattern manually with a memories file:

## Memory File: .claude/memories.md

### Established Preferences

- Client prefers bullet points over paragraphs in executive summaries (captured 2025-01-15)
- Always include page numbers in document references (captured 2025-01-18)
- Dislikes passive voice—prefers direct statements (captured 2025-01-20)

### Domain-Specific

- [Legal] Use "shall" not "will" in contract obligations
- [Marketing] This client prefers data-first messaging
- [Research] Cite primary sources over review articles when possible
- [Software] Prefers explicit type annotations over inference

### Session Notes

[Add notes here during work sessions, consolidate weekly]

Then in your instructions:

## Memory

Read memories.md at session start. It contains my established preferences.
If you learn something new about my preferences during this session,
suggest adding it to the memories file before we finish.

Memory Scoping: Global vs Session

Not all knowledge should persist. The key question: Should this affect future sessions?

Type	Persistence	Examples
Global Memory	Across all sessions	"Client prefers formal tone"
		"Always cite primary sources"
		"Use Oxford comma in all documents"
		"This firm uses APA citation style"
Session Memory	This session only	"Current task is the Johnson contract review"
		"We decided to recommend Option A, not Option B"
		"The issue is in Section 4.2 of the agreement"
		"Today's deadline is the grant proposal"

Global memory shapes how AI works on your projects generally. Session memory shapes what it's working on right now.

The danger of over-globalizing: if you persist too much, your memories become noisy. "We're reviewing the Johnson contract" isn't a preference—it's current context that will be irrelevant tomorrow.

The danger of under-globalizing: if you don't persist enough, you re-explain the same preferences every session. "I already told you this client prefers bullet points" shouldn't happen.

Strategies for Getting Understanding OUT

The second direction of the Two-Way Problem: how do you extract understanding from what the AI generates?

This direction gets less attention, but it's equally important. When AI produces a complex deliverable—a contract, a campaign strategy, a research analysis, or code—you need to understand it well enough to defend it, modify it, and explain it to others.

Strategy 1: Require Explanations

Don't accept deliverables without reasoning.

Weak approach (any domain):

Draft the indemnification clause for the vendor agreement.

or

Create the Q4 campaign strategy for the product launch.

AI produces output. You read it. Maybe you understand the reasoning, maybe you don't. You're reverse-engineering intent from the deliverable.

Strong approach (Legal example):

Draft the indemnification clause for the vendor agreement.
Before drafting, explain:
1. What liability allocation approach you're recommending and why
2. What carve-outs you're including and the reasoning
3. How this compares to our standard template
4. What risks remain even with this language

Then draft the clause.

Strong approach (Marketing example):

Create the Q4 campaign strategy for the product launch.
Before writing, explain:
1. Why you're recommending this channel mix
2. What audience segments you're prioritizing and why
3. How this differs from last quarter's approach
4. What assumptions you're making about budget allocation

Then create the strategy.

Strong approach (Software example):

Implement the caching layer for the product catalog.
Before writing code, explain:
1. What caching strategy you're using and why
2. What the cache invalidation approach is
3. What happens on cache miss
4. What the failure modes are and how they're handled

Then implement it.

Now you understand the intent before you see the deliverable. The output becomes verification of the explanation, not a puzzle to decode.

Strategy 2: Structured Output

Ask for outputs that organize understanding, not just deliverables.

For any complex work product, request structured documentation:

When you complete this work, provide:

## Summary
- What was created (1-2 sentences)
- Key decisions and reasoning (bullet points)

## Components/Sections
- [Component]: [what it does and why it's structured this way]

## Review Notes
- How to verify this is correct
- Edge cases or exceptions to watch for

## Future Considerations
- What someone modifying this later should know
- Potential issues or limitations

Domain-specific variations:

Legal:

## Contract Summary
- Purpose and key terms
- Deviations from standard template and why

## Risk Analysis
- Remaining exposure areas
- Mitigation recommendations

## Client Communication
- How to explain this to the client
- Questions they're likely to ask

Marketing:

## Campaign Summary
- Core message and target audience
- Channel strategy rationale

## Success Metrics
- How to measure effectiveness
- Benchmarks for comparison

## Stakeholder Notes
- How to present this to leadership
- Likely objections and responses

This structure forces AI to articulate the knowledge that would otherwise stay implicit. You're not just getting a deliverable—you're getting a knowledge transfer document.

Strategy 3: Progressive Review

Don't try to understand everything at once.

Weak approach: AI generates a complete deliverable. You review a 20-page document or 500 lines of code, trying to hold the whole thing in your head.

Strong approach: Break the work into chunks that build understanding progressively.

Legal example:

Let's draft the service agreement step by step.

Step 1: Show me the scope of services section and explain the key choices.
[review and discuss]

Step 2: Draft the compensation and payment terms.
[review and discuss]

Step 3: Draft the liability and indemnification sections.
[review and discuss]

Step 4: Add the termination and dispute resolution clauses.
[review and discuss]

Research example:

Let's develop the methodology section step by step.

Step 1: Outline the research design and explain why this approach fits the question.
[review and discuss]

Step 2: Detail the participant selection and sampling strategy.
[review and discuss]

Step 3: Describe the data collection procedures.
[review and discuss]

Step 4: Explain the analysis approach and how findings will be validated.
[review and discuss]

Each step builds on the previous one. By the time you reach the final deliverable, you've accumulated understanding piece by piece instead of trying to absorb it all at once.

Strategy 4: The Rubber Duck Test

After AI creates something significant, explain it back:

I want to make sure I understand what you created.
Let me explain it back to you, and correct me if I'm wrong:

[your explanation]

Did I get that right? What did I miss or misunderstand?

This reveals gaps in your understanding. If you can't explain it, you don't understand it. And if you don't understand it, you shouldn't use it—whether it's a contract clause you'll need to defend, a campaign strategy you'll need to present, or code you'll need to maintain.

Lab: Tacit Knowledge Extraction

Objective: Transform 10 minutes of verbal explanation into effective AI context.

This lab addresses the first direction of the Two-Way Problem: getting what's in your head into a format the AI can use.

Choose Your Domain Context:

This lab works for any professional domain. Select the context closest to your work:

Domain	Your "Project"	The "New Person"
Legal	A client relationship or practice area	A new associate joining the team
Marketing	A client account or campaign type	A new account manager
Research	A study or research program	A new graduate student or collaborator
Business/Consulting	A client engagement or business process	A new analyst or consultant
Software	A codebase or system	A new developer joining the team

What you'll need:

• A project/client/engagement you know well (ideally one with undocumented history)
• A way to record yourself talking (phone voice memo, laptop mic, etc.)
• 60-90 minutes of focused time

Protocol:

Step 1: Record the Explanation (10 minutes)

Imagine a competent new colleague is joining tomorrow. They can read documents and understand standard procedures—but they don't know the history, the relationships, or the unwritten rules.

Record yourself explaining your project/client/engagement to them.

For Legal:

• Why this client's agreements are structured the way they are
• Which issues they're sensitive about and why
• Historical disputes or near-misses that shaped current practice
• What a new associate needs to know to not upset this relationship

For Marketing:

• Why this client's campaigns use certain approaches
• What creative directions have failed before and why
• Internal politics about brand voice or channel preferences
• What a new account manager needs to know to not lose this client

For Research:

• Why you chose this methodology over alternatives
• Which reviewers or funders have specific expectations
• Previous studies that shaped current approach
• What a new collaborator needs to know to not compromise the work

For Business/Consulting:

• Why this client's processes work the way they do
• Which stakeholders have real power versus formal authority
• Historical initiatives that failed and the lessons learned
• What a new consultant needs to know to be effective

For Software:

• Why the system is architected the way it is
• Where the technical debt and danger zones are
• Historical incidents that shaped current design
• What a new developer needs to know to not break things

Don't script it. Talk naturally, as you would to a real colleague.

Step 2: Transcribe (10 minutes)

Transcribe your recording. You can use:

• Claude: "Transcribe this audio recording" (if you have audio upload capability)
• A transcription service (Whisper, Otter.ai, etc.)
• Manual transcription (tedious but ensures you engage with the content)

Step 3: Extract Non-Documented Knowledge (20 minutes)

Read through your transcription and highlight everything that ISN'T in your existing documentation.

Create a document with these sections:

## Tacit Knowledge Extraction: [Project/Client/Engagement Name]

### Historical Context (Why Things Are The Way They Are)
- [Knowledge item 1]
- [Knowledge item 2]

### Unwritten Rules (What Everyone Knows But Nobody Wrote Down)
- [Rule 1]
- [Rule 2]

### Danger Zones (Where New People Get Burned)
- [Danger 1]
- [Danger 2]

### Key Relationships (Who Knows What)
- [Person/team] owns [area] - ask them about [topic]
- [Person/team] has context on [historical decision]

### Political Landscape (How Decisions Actually Get Made)
- [Insight 1]
- [Insight 2]

Step 4: Categorize for AI Consumption (15 minutes)

Classify each item:

Knowledge Item	Should Go In...	Format
Legal: "Client requires gross negligence carve-outs"	Client context doc for AI	Structured document
Marketing: "Never use 'synergy' with this client"	Style constraints	Rule in instructions
Research: "Dr. Smith prefers Glaser over Strauss approach"	Not for AI (human context)	Keep in human docs
Business: "This client prefers bullet points"	Memory file	Global preference
Software: "Auth service has circuit breakers"	Architecture doc for AI	Structured document

Some tacit knowledge is for the AI. Some is for humans only. Some belongs in your instructions; some belongs in separate context files.

Step 5: Encode as AI-Consumable Artifacts (30 minutes)

Create the actual artifacts:

1. Update your AI instructions (CLAUDE.md or equivalent) with critical constraints from your extraction
2. Create context docs for AI consumption (see Strategy 1 format)
3. Start a memories file with preferences that emerged
4. Create a skill if the knowledge is complex enough (see Chapter 3)

Step 6: Test (15 minutes)

Start a fresh AI session and ask it to make a decision that requires the tacit knowledge you just encoded.

Test examples by domain:

• Legal: Ask AI to draft a clause for this client. Does it apply the right carve-outs?
• Marketing: Ask AI to write copy for this brand. Does it avoid the forbidden words?
• Research: Ask AI to outline a methodology. Does it follow field-specific conventions?
• Business: Ask AI to recommend a process change. Does it account for political sensitivities?
• Software: Ask AI to refactor something sensitive. Does it flag the constraint?

Does the AI behave as an informed colleague would?

Expected Finding: You'll discover that verbal explanations contain far more tacit knowledge than you realized. Much of it is genuinely valuable and was at risk of being lost.

Deliverable: A tacit knowledge document capturing what experienced professionals carry in their heads, encoded into AI-consumable formats (instructions, context docs, memories file, or skills).

The Connection to Context Engineering

This lesson addresses the human side of context engineering. Previous lessons taught you about attention budgets, position sensitivity, and signal-to-noise ratios. This lesson teaches you about the content itself—what knowledge to put in context and how to get knowledge back out.

Without tacit knowledge transfer, your Digital FTE is a generic chatbot. With it, your Digital FTE becomes a domain expert worth paying for.

The Two-Way Problem sits at the center of effective AI collaboration:

Lesson	Focus	The Two-Way Problem Connection
L1: Manufacturing	Why context determines quality	Tacit knowledge IS the quality differentiator
L2: Attention Budget	How much context fits	Tacit knowledge must fit the budget
L3: Position	Where context gets attention	Critical tacit knowledge needs Zone 1/3 placement
L4: Signal vs Noise	What context is useful	Tacit knowledge is high-signal by definition
L5: Tacit Knowledge	What context to encode	How to identify and transfer tacit knowledge
L6: Lifecycle	When to refresh context	When tacit knowledge becomes stale

Without tacit knowledge, your context is shallow—technically correct but missing the wisdom that makes work effective. Without strategies for extraction, you're using deliverables you don't fully understand.

Try With AI

Prompt 1: Tacit Knowledge Discovery

I want to identify tacit knowledge about my work that I haven't documented.

Interview me with these questions, one at a time. After I answer each one,
ask a follow-up to dig deeper.

1. What would go wrong if a new colleague started working on this without asking anyone first?
2. What's something that looks straightforward but is actually sensitive or risky?
3. What historical event or past experience shaped how things are done today?
4. What unwritten convention exists that you'd be frustrated if someone violated?
5. What do you know about this work that you'd struggle to find in any documentation?

After the interview, summarize the tacit knowledge we uncovered and suggest
which pieces should go in AI instructions, context documents, or a memories file.

What you're learning: Structured extraction of tacit knowledge through guided questions. The AI becomes an interviewer, helping you surface knowledge you carry but might not think to document. This is the first step in the knowledge-IN direction.

Prompt 2: Understanding Extraction

I'm about to review work you generated. Before I look at it, I want to make sure
I'll actually understand it, not just accept it.

For the next deliverable you create, provide:

1. INTENT: What problem this solves (1-2 sentences)
2. APPROACH: Why you chose this approach over alternatives
3. DECISIONS: Key choices and their tradeoffs
4. CONCERNS: Potential issues I should watch for
5. FUTURE: What someone modifying this later should know

Then create the deliverable.

I'll explain it back to you afterward to verify I understood.

What you're learning: Structuring the knowledge-OUT direction. Instead of passively receiving deliverables, you're requiring the AI to transfer understanding along with output. This prevents the "I'm using work I don't understand" failure mode.

Prompt 3: Memory Scoping Exercise

I have these pieces of knowledge from recent work sessions. Help me classify
each one as either GLOBAL (should persist across all sessions) or SESSION
(relevant only to current work).

For each item, explain your reasoning:

1. "This client prefers formal tone over conversational"
2. "The current task is reviewing the Johnson contract"
3. "We decided to recommend Option A instead of Option B"
4. "Always include page numbers in document references"
5. "The proposal we're writing is for the Q3 budget cycle"
6. "I prefer bullet points over long paragraphs in summaries"
7. "The deadline for this deliverable is Friday"
8. "Never use passive voice in executive communications"

After classifying, explain the general principle: How do you decide what's
global vs session-scoped?

What you're learning: The skill of memory scoping. Not all knowledge should persist—over-globalizing creates noise; under-globalizing causes repetition. This prompt helps you develop intuition for the distinction and apply it to real knowledge items.