Context
Background information the Agent needs to understand your specific situation.
Why This Matters
Context prevents:
- Irrelevant analysis - Agent analyzes the right metrics for your business
- Missed nuances - Agent understands your unique business challenges
- Misleading comparisons - Agent knows your competitive context
- Wasted time - Agent doesn't calculate metrics that don't apply to you
Context answers: "What should the Agent know about MY specific business?"
What Context Should Include
- Business Model & Structure
- How do you make money? (subscription, transaction, licensing, etc.)
- What are your main products/services?
- Who are your customer segments?
- Are you B2B, B2C, or B2B2C?
- Data Schema
- Key table names (not just generic "orders" but "orders", "subscriptions", "events")
- How data flows through your system
- Time lag in data availability (is today's data real-time or delayed 24 hours?)
- Data collection method (automatic, manual, third-party)?
- Business Metrics
- What KPIs matter most?
- How do you define key metrics? (e.g., "active user" = logged in last 30 days?)
- What are your targets/goals?
- What's your business baseline? (e.g., "historical churn is 4.5%")
- Special Context
- Regulatory requirements (HIPAA, GDPR, PCI-DSS, etc.)
- Seasonality (e.g., retail peaks Q4)
- Known events affecting data (new product launch, price change, competitor entry)
- Data quality issues to be aware of
Real Examples: Context in Different Domains
E-Commerce Retailer Context:
Context: Multi-Channel Retail OperationBusiness
Model: Direct online sales + wholesale partnerships
Products: Electronics, apparel, home goods (50K+ SKUs)
Customers: Consumer retail, distributed across North America
Data Structure:
- orders_fact: Transaction-level data (50M+ rows/year)
- inventory_master: Current stock levels by location (125 stores + 3 DCs + ecommerce)
- customers: De-identified customer profiles
- Seasonality: Q4 is 40% of annual revenue; heavy promotion periodsKey
Metrics:
- Revenue (by category, channel, location)
- Conversion rate
- Average order value
- Customer lifetime value
- Inventory turns
Known Context:
- 2-week supply chain lag (ordered today, arrives in 14 days)
- Returns are 8-12% (high for apparel, low for electronics)
- Q4 promotions run Nov 15
- Dec 24
- Supplier X had 6-week delivery during COVID; now normal
SaaS Company Context:
Context: B2B SaaS - Project Management Software
Business Model: Monthly and annual subscriptions
Segments: SMB ($99-499/mo), Mid-market ($500-5K/mo), Enterprise (custom)
Customers: Project teams, distributed across 50+ countries
Data Structure:
- subscriptions: Current and historical contracts (anonymized customer_id)
- events: Feature usage, daily tracking
- support_tickets: Customer issues, questions
- Time lag: Churn data has 30-60 day reporting lagKey
Metrics:
- MRR/ARR (monthly/annual recurring revenue)
- Churn rate (monthly and annual)
- Net Revenue Retention (NRR)
- key SaaS metric
- Expansion revenue (upsells, feature upgrades)
- CAC (customer acquisition cost)
- LTV (lifetime value, 24-month prediction)
Known Context:
- January churn is always 1.5x higher than average (budget cuts)
- Features get adopted slowly (6-12 month curve to full adoption)
- Support tickets correlate with future churn (r=0.68)
- Enterprise customers rarely churn; SMB churn is volatile
Hospital/Healthcare Context:
Context: 5-Hospital Health System
Business Model: Patient care (insurance + out-of-pocket revenue)
Departments: ICU, Emergency, Surgery, Behavioral Health, Maternity
Patients: Regional population, diverse acuity levels
Data Structure:
- patient_encounters (admission, ED visit, outpatient)
- All data de-identified, HIPAA encrypted
- Clinical outcomes: mortality, readmission (30-day), infections, complications
- Reporting lag: Quality metrics available 2-4 weeks post-discharge
Key Metrics:
- Mortality rate (in-hospital and 30-day)
- Readmission rate (30-day, 60-day)
- Hospital-acquired infection rate (per 1,000 patient days)
- Length of stay (by diagnosis, department)
- Case Mix Index (patient acuity)
- Patient safety incidents
Known Context:
- ICU patients have 30-40% higher mortality; must risk-adjust
- Winter increases hospital volume by 15-20%
- New electronic health record implemented 6 months ago (may affect data)
- Safety reporting has improved engagement last 3 months
Context Template
Context: [BUSINESS TYPE]
Business Model: [How you make money]
Segments: [Customer/product segments]
Data Structure:
- [Key table 1]: [Description and row count if large]
- [Key table 2]: [Description and row count if large]
- Time lag: [How current is the data?]
- Data quality notes: [Any known issues?]
Key Metrics:
- [Metric 1]: [Definition]
- [Metric 2]: [Definition]
- [Metric 3]: [Definition]
Known Context:
- [Important business context 1]
- [Important business context 2]
- [Seasonality, events, or recent changes]
Output Format
How the Agent should structure its response. Format determines how stakeholders consume the insights.
Why This Matters
Output format influences:
- Usability - Can the stakeholder quickly extract what they need?
- Decision-making - Does the format support the decision being made?
- Consistency - Do all Agent outputs follow the same structure?
- Appropriate depth - Is the level of detail right for the audience?
Wrong format makes good insights unusable. Right format makes insights actionable.
Format Principles
- Executive Summary First
- Executives want the headline first
- Then supporting detail
- Bad: "Revenue was $4.2M with 23% increase driven by..."
- Good: "Revenue increased 23% to $4.2M, driven by Category A (+40%) partially offset by Category B (-8%)"
- Concrete > Abstract
- Bad: "Sales performance improved"
- Good: "Sales increased from $1.2M to $1.5M (25% growth)"
- Context > Standalone
- Bad: "$1.5M revenue"
- Good: "$1.5M revenue (vs. $1.2M last month, vs. $1.1M target)"
- Actionable > Descriptive
- Bad: "Customer churn increased"
- Good: "Customer churn increased 2% to 7.2%; highest in SMB segment (8.1% vs. 3% enterprise)"
Real Format Examples
Bad Format (Too much detail, no hierarchy)
Output:We analyzed 5,000 customer records. First we queried the database. The average order value was $145. The median was $120. The standard deviation was $95. 73% of customers placed 1 order, 18% placed 2-5 orders, 9% placed 6+ orders. The top 20% of customers by spend accounted for 73% of revenue. Revenue was $725K. Etc.
Problems:
- No executive summary
- Doesn't distinguish what's important from what's details
- No context or comparisons
- Not organized for decision-making
Good Format (Hierarchy, context, actionable)
EXECUTIVE SUMMARY
Top 20% of customers drive 73% of revenue (highly concentrated).
Focus: Retention of high-value customers and acquisition of similar profiles.
KEY METRICS
- Total revenue: $725K (vs. $680K last period, 6.6% growth)
- Customers: 5,000 (new customers: 320 this period)
- Average order value: $145 (vs. $138 last period)
- Repeat purchase rate: 27% (27% of customers placed 2+ orders)
CUSTOMER SEGMENTATION
- High-value (top 20%): $145K revenue, 73% of total, $1,850 avg LTV
- Mid-value (60%): $420K revenue, 24% of total, $350 avg LTV
- Low-value (20%): $160K revenue, 3% of total, $80 avg LTV
INSIGHTS & ACTIONS
1. Retention focus: Top 20% at-risk churn would cost $100K+ annualized
→ Recommend VIP program, quarterly check-ins
2. Acquisition: New customers look like mid-value segment (repeat rate 18%)
→ Recommend targeting for expansion after 90 days
3. Opportunity: Low-value segment (80% of customer count) drives only 3% revenue
→ Either improve their LTV or reduce acquisition spend on this segment
This is much more useful.
Domain-Specific Format Examples
For Customer Churn Analyst:
CHURN SUMMARY
[Overall churn rate, trend, biggest concern]
CHURN METRICS
- Gross churn: [X]% ([N] customers)
- Revenue churn: [X]% ($[Y]M)
- Churn rate by segment: [List top 3 highest-churn segments]
RISK ANALYSIS
- High-risk cohort: [Cohort description]
- Predicted churn (next 30 days): [N] customers, $[X]M revenue at risk
- Early warning signals: [Usage decline, support tickets, etc.]
ROOT CAUSE BY SEGMENT
- Segment A: [Primary reason], [supporting evidence]
- Segment B: [Primary reason], [supporting evidence]
RETENTION RECOMMENDATIONSFor each high-risk segment:
- [Specific action]
- [Expected impact]
- [Timeline/resource required]
METHODOLOGY
- Churn definition: [What counts as churn]
- Time period: [Dates analyzed]
- Sample size: [N customers]
For Operations/Efficiency Analyst:
EFFICIENCY SUMMARY
[Current vs. target, gap, impact]
CURRENT PERFORMANCE
- Key metric: [Current value] vs. [Target value]
- Variance: [$X] or [%]
- Annual impact: $[X]K
BOTTLENECK ANALYSIS
- Primary constraint: [Step in process]
- Impact: [% of process, dollar impact]
- Root cause: [Why it's slow]
IMPROVEMENT OPPORTUNITIES
1. [Quick win]: Impact $[X], Timeline [weeks], Complexity [low/medium/high]
2. [Medium term]: Impact $[X], Timeline [weeks], Complexity [low/medium/high]
RECOMMENDED PILOT
- Scope: [What specifically to improve]
- Success metrics: [How to measure]
- Timeline: [Duration]
- Expected ROI: [% or dollars]
DATA
- Process steps analyzed: [List]
- Volume: [Transactions/units]
- Time period: [Dates]
Format Design Principles
- Lead with Summary
- First line: The key insight
- Next section: Supporting metrics
- Then: Details and deep dives
- Use Visual Hierarchy
- Emojis/icons for different sections
- Headers in all caps
- Consistent indentation
- Bold for key numbers
- Make Numbers Concrete
- "$1.5M" not "revenue increased"
- "7.2% churn" not "higher than before"
- "vs. $1.2M target" adds context
- Include Context
- Comparisons (vs. last month, vs. target, vs. baseline)
- Confidence intervals for risky claims
- Sample sizes for analysis
- Time periods clearly stated
Complete Example: E-Commerce Analytics Agent
Here's a fully configured Agent backstory for an e-commerce database:
<OBJECTIVE_AND_PERSONA>
You are a Senior E-Commerce Data Analyst with deep expertise in retail analytics. Your mission is to uncover growth opportunities and operational efficiencies by analyzing customer behavior, product performance, and revenue trends. You think critically about data quality and always validate findings before presenting them.
</OBJECTIVE_AND_PERSONA>
<INSTRUCTIONS>
1. UNDERSTANDING THE QUESTION
- Clarify what business question is being asked
- Identify relevant time periods and segments
- Ask about constraints (budget, urgency, audience)
2. DATA EXPLORATION
- Check which tables contain relevant data
- Verify data recency and quality
- Identify potential data issues upfront
3. ANALYSIS EXECUTION
- Write efficient SQL queries with indexes in mind
- Cross-validate using multiple query approaches
- Calculate base metrics before deeper analysis
4. INSIGHT EXTRACTION
- Identify trends, patterns, and anomalies
- Quantify impact (revenue, margin, growth)
- Flag surprising or counterintuitive findings
5. RESULT PRESENTATION
- Lead with the key insight
- Support with specific metrics
- Provide actionable recommendations
</INSTRUCTIONS>
<CONSTRAINTS>
MUST DO:
- Always include the SQL query used
- Reference specific time periods and filters
- Explain any data transformations
- Flag outliers and data quality issues
- Compare metrics to relevant baselines
- Estimate statistical significance
MUST NOT:
- Make claims without quantitative support
- Assume causation from correlation
- Query customer PII without authorization
- Generate synthetic data
- Present unvalidated findings
- Ignore performance implications
</CONSTRAINTS>
<CONTEXT>
Database: ecommerce_prod
Key tables:
- orders (transaction-level data, 50M+ rows)
- customers (customer profiles, anonymized PII)
- products (catalog, 100K+ SKUs)
- inventory (stock levels)
- payments (transaction records)
Key metrics:
- GMV: Gross Merchandise Value
- CAC: Customer Acquisition Cost
- LTV: Customer Lifetime Value
- Conversion Rate: Sessions → Purchases
- AOV: Average Order Value
</CONTEXT>
<RECAP>
You are an e-commerce data analyst who uncovers growth opportunities through rigorous analysis. Always show your SQL, explain your methodology, and validate findings. Present insights in the structured format (Key Finding → Metrics → Analysis → Actions). Never make claims without data support.
</RECAP>
Implementation Best Practices
-
Start Simple, Iterate
- Begin with core components (Objective, Persona, Instructions)
- Add optional components as needed
- Test different framings and measure quality
-
Domain-Specific Customization
- Adjust persona for your industry (Finance, Healthcare, Retail, etc.)
- Include industry-specific metrics and constraints
- Tailor examples to your actual data patterns
-
Data Governance Integration
- Embed access controls in constraints
- Specify PII handling requirements
- Include compliance requirements (GDPR, HIPAA, etc.)
-
Performance Optimization
- Add system instructions about query efficiency
- Specify acceptable query execution times
- Include caching guidelines
-
Quality Assurance
- Test with sample questions before deployment
- Iterate on output format based on user feedback
- Monitor query performance and accuracy
-
Version Control
- Document changes to backstory over time
- A/B test different versions
- Keep track of what works for your use case
Common Pitfalls to Avoid
| Pitfall | Fix |
|---|---|
| Vague objectives | Be specific: "Identify revenue leaks" not "analyze data" |
| Missing context | Include schema, key tables, business metrics |
| No constraints | Define what the Agent cannot do (PII, sensitive data, etc.) |
| Generic examples | Use real examples from your actual data |
| Unclear format | Provide exact structure with placeholders |
| Ignoring performance | Add system instructions about query efficiency |
| No validation | Include validation steps in instruction |