Posts


# Product Context for AI Agents: The Missing Layer in AI Coding

Your AI coding agent just built a feature in 20 minutes that would have taken you 2 days. It's clean. It's well-tested. It handles edge cases.

It's also completely wrong for your product.

> **Product context** is the accumulated knowledge about validated assumptions, customer understanding, strategic constraints, risk awareness, and feature connections that an AI coding agent needs to make good decisions — not just execute instructions. Without product context, the agent builds exactly what you asked for. With it, the agent can question requirements, suggest validation, and avoid building features that conflict with your product strategy.

**The problem isn't the code. The problem is context.**

## The Context Gap in AI Coding

When you prompt Cursor, Claude, or any AI coding agent, you give it:
- What to build (the feature)
- How to build it (maybe some technical constraints)
- Where to put it (the file/folder)

What you don't give it:
- **Why** this feature matters to users
- **Who** the target customer actually is
- **What assumptions** you're making (validated or not)
- **Which constraints** come from business reality vs. preference
- **How** this feature connects to your product strategy

The AI builds exactly what you asked for. But you asked for the wrong thing.

## Real Examples of Context-Blind Building

### Example 1: The Onboarding Flow

**What you prompted:** "Add a 5-step onboarding wizard with profile setup, preferences, team invites, integrations, and a tutorial."

**What you should have known:** Your user research shows 60% of users abandon onboarding after step 2. They want value fast, not configuration.

**What context-aware building looks like:** "Our users abandon multi-step flows. Build a single-screen onboarding that gets them to first value in under 60 seconds. Defer everything else."

### Example 2: The Admin Dashboard

**What you prompted:** "Build an admin dashboard with user management, analytics, and settings."

**What you should have known:** Your ICP is a 2-person startup. They don't need admin dashboards—they need to ship faster.

**What context-aware building looks like:** "Skip the admin dashboard. Build inline editing and simple user controls. Our users are founders who'd rather code than configure."

### Example 3: The Premium Feature

**What you prompted:** "Add a premium tier with advanced analytics and team collaboration."

**What you should have known:** You haven't validated that anyone would pay for advanced analytics. Your assumption is untested.

**What context-aware building looks like:** "Add a 'Coming Soon: Advanced Analytics' button that captures email interest. We're testing demand before building."

## What Is Product Context?

Product context is the accumulated knowledge about:

### 1. Validated Assumptions
What you've actually tested vs. what you're guessing.
- "Users will pay $10/month" → Tested with 50 users, 12% conversion
- "Users want team features" → Untested assumption

### 2. Customer Understanding
Who your users are, what they care about, what they'll reject.
- Target: Solo founders, not enterprise teams
- Pain: Building wrong things, not building slow
- Objection: "Another tool in my stack"

### 3. Strategic Constraints
Business realities that limit what you should build.
- "We can't afford $0.50/API call at scale"
- "SOC 2 compliance required for enterprise deals"
- "Must work offline for field sales use case"

### 4. Risk Awareness
What could go wrong and what you're monitoring.
- "If churn exceeds 8%, the business model breaks"
- "Competitor X shipping similar feature in Q1"

### 5. Feature Connections
How features relate to each other and to business outcomes.
- "Onboarding completion correlates with 60-day retention"
- "Users who try personas convert 3x higher"

## The Product Context Graph

At [Cutline](/), we think of product context as a **graph**, not a document.

Nodes include:
- Features (built and planned)
- Assumptions (validated, invalidated, untested)
- Personas (with goals, frustrations, objections)
- Risks (with likelihood, impact, mitigations)
- Experiments (with results and learnings)

Edges connect them:
- "Feature X validates Assumption Y"
- "Persona A's objection blocks Feature B"
- "Risk C is mitigated by Experiment D"

When your AI agent has access to this graph, it can make informed decisions:
- "Should I build this complex feature?" → Check if the underlying assumption is validated
- "How should I handle this edge case?" → Check what the target persona would expect
- "Is this technical approach okay?" → Check if it conflicts with strategic constraints

## How to Give AI Agents Product Context

### Level 1: Manual Context Injection
Add context to every prompt manually.

```
Build a pricing page. Context:
- Target user: solo founders, price-sensitive
- Validated: users will pay, but only if monthly option exists
- Constraint: must show annual discount prominently (our LTV depends on it)
- Risk: competitor is cheaper, so emphasize value not price
```

This works but doesn't scale. You'll forget context. You'll be inconsistent.

### Level 2: Context Documents
Maintain a product context doc and reference it.

Create a `PRODUCT_CONTEXT.md`:
```markdown
## Target User
Solo founders and indie hackers...

## Validated Assumptions
1. Users will pay $9.99/month (tested, 15% conversion)
2. Users want IDE integration (tested, 8/10 interviewees)

## Constraints
- COGS must stay under $0.03/request
- No features requiring real-time sync (infrastructure cost)
```

Tell your AI: "Read PRODUCT_CONTEXT.md before implementing any feature."

Better, but still manual. The doc gets stale. The AI doesn't truly "understand" it.

### Level 3: Context Integration via MCP
Use [Model Context Protocol](/docs/setup) to inject context automatically.

With Cutline's MCP integration:
- Your AI agent can query the product context graph
- It knows which assumptions are validated
- It can check constraints before suggesting approaches
- It can ask personas for feedback mid-implementation

```
Agent: "I'm about to build a team collaboration feature. 
        Let me check if this aligns with the product context..."

[Queries Cutline]

Agent: "I see that 'users want team features' is an untested 
        assumption with high uncertainty. Recommend validating 
        before building. Should I create a demand test instead?"
```

This is context-driven development.

## From Spec-Driven to Context-Driven

The evolution of AI-assisted development:

| Stage | What AI Gets | What AI Builds |
|-------|--------------|----------------|
| **Prompt-driven** | A description | Exactly what you said (often wrong) |
| **Spec-driven** | A detailed spec | What the spec says (still might be wrong) |
| **Context-driven** | Product context graph | The right thing for the product |

Spec-driven development (tools like Traycer, Devplan) is better than prompt-driven. You get consistency and completeness.

But specs don't tell you whether you *should* build something. They don't encode:
- "This assumption is untested"
- "This persona would hate this approach"
- "This conflicts with our pricing strategy"

Context-driven development adds the **why** layer.

## Getting Started with Product Context

### Step 1: Run a Pre-Mortem
Before building, identify your riskiest assumptions. [Cutline's pre-mortem](/pre-mortem) generates:
- Assumption stack (ranked by risk)
- Failure modes to watch for
- Experiments to validate assumptions

### Step 2: Build Your Persona Graph
Create [AI personas](/ai-persona-testing) that represent your target users. Interview them about features before building.

### Step 3: Connect to Your IDE
Set up [MCP integration](/docs/setup) so your AI coding agent can query product context in real-time.

### Step 4: Iterate Based on Evidence
As you validate or invalidate assumptions, update your context graph. Your AI agent gets smarter with your product.

## The Future of AI Coding

Right now, AI agents are powerful but context-blind. They'll build whatever you tell them, perfectly.

The next wave is context-aware AI agents that:
- Question whether a feature should be built
- Suggest validation before implementation
- Adapt their approach based on product constraints
- Learn from what works and what doesn't

**The code is easy. The context is hard.**

Products that figure out context-driven development will build the right things. Everyone else will build the wrong things faster.

---

## FAQ

**Q: What is product context for AI agents?**

Product context is the accumulated knowledge about validated assumptions, customer understanding, strategic constraints, risk awareness, and feature connections that an AI coding agent needs to make good decisions — not just execute instructions.

**Q: What is a product context graph?**

A product context graph is a connected structure where nodes represent features, assumptions, personas, risks, and experiments, and edges represent relationships like "Feature X validates Assumption Y" or "Persona A's objection blocks Feature B." AI agents traverse this graph to understand why they're building something.

**Q: What is context-driven development?**

Context-driven development is the evolution beyond spec-driven development. Where specs tell agents what to build, context-driven development gives agents the full product context so they can question requirements, make tradeoffs, and avoid building features that conflict with strategy.

**Q: How do you give AI coding agents product context?**

Three levels: (1) manual context in every prompt (doesn't scale), (2) context documents like PRODUCT_CONTEXT.md (goes stale), and (3) MCP integration that lets the agent query the context graph in real-time, checking validated assumptions and constraints before implementing.

---

*Ready to give your AI agents product context? [Start with a pre-mortem](/start) to build your context graph.*
