Prompt Engineering Best Practices — AnyCompany Insurance Workshop

🎯 The 4 Pillars of Effective Prompts

80% of prompt quality comes from 4 fundamentals. Master these and every prompt you write — whether it's a claims summary, underwriting memo, or compliance check — will be dramatically better.

🎯

1. Clarity

Say exactly what you mean. If a colleague would ask "what do you mean?" — your prompt needs work.

📚

2. Context

Give the AI the background it needs: domain, data, situation, constraints. Without context, it guesses.

👤

3. Role Assignment

Tell the AI who to be. A "claims adjudicator" focuses on different signals than a "customer service agent."

📋

4. Output Framing

Define what "done" looks like — format, length, structure, style. No framing = unpredictable output.

📚 4 Types of Context

Context is the most impactful pillar for insurance. Skip any type and the output suffers in a specific way:

Type	What it tells the AI	If you skip it...	Insurance example
Domain	Industry, market, business area	Generic, non-specific answers	"In the context of Singapore life insurance underwriting..."
Data	Specific numbers, records, documents	AI hallucinates plausible numbers	"Here is the policyholder's claim history and medical report: [data]"
Situational	Why you need this now — the trigger	Wrong tone, urgency, framing	"Preparing for MAS regulatory submission" / "Flagged by fraud detection"
Constraints	Rules, limits, requirements	Ignores your standards	"All amounts in SGD" / "Follow MAS Notice 127 guidelines"

👀 See the Difference

❌ Without 4 Pillars

Prompt: "Review this claim"

The claim seems to be legitimate. The policyholder has been with us for a while and the medical documentation looks reasonable. There are some inconsistencies but that's fairly normal. Overall I would recommend processing the claim.

⚠️ Vague, no data cited, no structure, no decision rating, not actionable

✅ With 4 Pillars

Prompt: Role + Context + Structure + Constraints

DECISION: 🟡 REFER TO SENIOR ADJUDICATOR
Claim Analysis: Critical illness claim for $200K. Diagnosis date 14 months post-inception — within 24-month contestability window.
Red Flag: Pre-existing condition not disclosed on application. GP records show consultation 3 months before policy start.
Action: 1) Request full medical history from attending physician (Claims Ops, 5 days) 2) Refer to Special Investigations Unit (SIU, immediate)

✓ Structured, data-cited, specific actions with owners and timelines

💡

Same data, dramatically different quality. The difference is entirely in the prompt — not the AI model.

🧠 Chain-of-Thought Reasoning

Insurance decisions require multi-step logic. CoT makes reasoning visible and auditable — the AI shows its work, which is critical for regulatory compliance and dispute resolution.

💬

Zero-Shot CoT

Just add "Think step by step." No examples needed. Best for quick calculations and simple logic.

📝

Few-Shot CoT

Provide one example with reasoning. The AI follows the exact same pattern. Best for consistent processes.

🔭

Step-Back

"First identify key factors, then analyze." Forces prioritization before writing. Best for complex analysis.

🗳️

Self-Consistency

"Solve 3 ways, report majority." Multiple approaches catch what a single analysis misses. Best for high-stakes.

👀 Zero-Shot CoT: Before & After

Question: "Should we approve this $500K term life application?"

❌ Without CoT

Yes, the application looks acceptable. The applicant has a reasonable income and no major health issues reported. I would recommend approval at standard rates.

⚠️ No math. No reasoning. Not auditable. Could miss critical risk factors.

✅ With "Think step by step"

Annual income: $180K SGD
− Sum assured requested: $500K
= Income multiple: 2.8x (within 10x guideline ✅)
Age: 42, non-smoker, BMI 24.2
= Mortality class: Preferred
Existing coverage: $200K (other insurer)
= Total exposure: $700K = 3.9x income
✅ Within financial underwriting limits — APPROVE at Preferred rates

✓ Every step visible. Math auditable. Conclusion backed by evidence.

🗳️ Self-Consistency: 3 Approaches, 1 Answer

For high-stakes decisions, analyze from 3 independent angles and take the majority vote:

Approach	Analysis	Conclusion
1. Medical	Hospitalization claim 3 days after policy inception. Diagnosis: acute appendicitis (sudden onset, not pre-existing).	🟢 LEGITIMATE
2. Financial	Claim amount $45K for 3-day stay at private hospital. Itemized bill matches typical appendectomy costs in Singapore.	🟢 LEGITIMATE
3. Behavioral	Policyholder upgraded plan from basic to comprehensive 2 weeks before admission. No prior claims in 5 years on basic plan.	🔴 SUSPICIOUS

Majority: 2/3 LEGITIMATE. Approach 3 alone would have flagged this for investigation. The majority vote provides balanced judgment — but the timing anomaly should still be noted in the file.

⚠️

Insurance rule: Any decision that could be audited by MAS or challenged in a dispute should use CoT — the reasoning trail IS your documentation.

👤 Role & Persona Prompting

Same data, dramatically different insights — just by changing who the AI "is." The AI was trained on millions of documents written by different professionals. When you assign a persona, you activate that specific knowledge cluster.

The Persona Formula

      You are [TITLE] at [COMPANY TYPE]

      with [X years] of experience in [SPECIALTY].

      You are known for [CHARACTERISTIC].

      When [SITUATION], you always [BEHAVIOR].

💡

The last two fields — CHARACTERISTIC and BEHAVIOR — matter most. "Conservative" vs "growth-focused" produces completely different recommendations from the same data.

👀 Same Claim, Different Eyes

Data: Critical illness claim for $300K. Policyholder diagnosed with Stage 2 cancer, 18 months after policy inception. Non-disclosure of family history on application.

🛡️ Claims Investigation Lead

RECOMMENDATION: DECLINE — Material Non-Disclosure

Family history of cancer (father, uncle) not disclosed on application. Within 24-month contestability period. Had applicant disclosed, underwriting would have required additional screening and likely applied exclusion or loading.

Action: Issue decline letter citing Section 25 Insurance Act. Offer ex-gratia refund of premiums paid. Prepare for potential FIDReC dispute.

💚 Customer Experience Director

RECOMMENDATION: PARTIAL APPROVAL — Fair Dealing Approach

Policyholder is a loyal customer (3 other policies, 8 years). Non-disclosure appears inadvertent — family history question was buried in page 12 of a 15-page form. MAS Fair Dealing Guidelines emphasize proportionate response.

Action: Approve at reduced sum ($200K, reflecting what would have been offered with disclosure). Retain customer relationship. Document reasoning for audit trail.

Both are valid. The investigator sees contractual breach. The CX director sees customer retention and fair dealing. Neither is wrong — they serve different business objectives.

🤝 Multi-Agent Framing

Get 3 perspectives in one prompt — no need to schedule 3 meetings:

Perspective	Focus	Key finding
🛡️ Chief Actuary	Loss ratios, reserves, pricing adequacy	"Approving borderline claims increases loss ratio by 2.3 points"
📊 Head of Distribution	Persistency, NPS, agent retention	"Claim disputes are #1 driver of policy lapses and agent attrition"
⚖️ Chief Compliance Officer	MAS guidelines, PDPA, fair dealing	"MAS Fair Dealing Outcome 5 requires claims to be paid fairly and promptly"

Synthesis: Approve claim with enhanced documentation. Update underwriting questionnaire to make family history more prominent. Monitor loss ratio impact quarterly. Report to Board Risk Committee if loss ratio exceeds 65%.

🔍

The synthesis is where the real insight lives. No single perspective dominates — the balanced recommendation is stronger than any individual view.

The Research Behind It

Multi-agent framing is a well-established prompt engineering technique with several names in the research literature:

Technique	Source	Key idea
Solo Performance Prompting (SPP)	Wang et al., 2023	A single LLM simulates multiple personas that collaborate internally — "cognitive synergy through multi-persona self-collaboration"
Multi-Persona Thinking (MPT)	arXiv 2025	Dialectical reasoning from multiple perspectives to reduce bias and improve decision quality
Town Hall Debate Prompting	arXiv 2025	Splices a language model into multiple personas that debate one another to reach a conclusion
Self-Consistency	Wang et al., 2022	Generate multiple reasoning paths and aggregate — the broader technique family that multi-perspective builds on

💡

Why it works: LLMs are trained on millions of documents written by different professionals. When you assign a persona, you activate that specific knowledge cluster. Asking for 3 personas in one prompt triggers 3 distinct "knowledge activations" — producing genuinely different analyses, not just rephrased versions of the same answer.

🔗

Agentic AI connection: Here, you simulate multiple perspectives in a single prompt. In the agentic world, you'll see the automated version — the Parallelization pattern — where each perspective actually runs as a separate AI agent simultaneously, and a real aggregator combines the results. Same concept, automated at scale.

📋 Structured Outputs & RAG Grounding

Consistent format + grounded in YOUR data = production-safe outputs.

Why Structure Matters

❌ Unstructured = Conversation

Different every time. Hard to compare. Can't feed into systems. Requires human parsing.

✅ Structured = Form

Consistent format. Comparable across claims. Machine-parseable. Scannable by busy stakeholders.

How to Prompt for Structured Output

Tell the AI exactly what shape the output should take. The more specific your format instructions, the more consistent the results.

Technique	Prompt example	What you get
Named sections	"Use these sections: Summary, Risk Factors, Recommendation"	Same headings every time — scannable, comparable
Table format	"Present as a table: Metric \| Value \| Benchmark \| Status"	Aligned data, easy to paste into Excel
JSON output	"Return JSON: {decision, confidence, reasoning, actions[]}"	Machine-readable, feeds into dashboards or APIs
Numbered actions	"List 3 actions. Each: action, owner, deadline, priority (H/M/L)"	Actionable items with accountability
Rating + justification	"Give an APPROVE/REFER/DECLINE decision. Justify in exactly 2 sentences."	Consistent decision format across all reviews
Length control	"Executive summary: max 3 sentences. Detail: max 200 words."	Right depth for the audience

Full Example: Combining Techniques

OUTPUT FORMAT:

1. Decision — APPROVE/REFER/DECLINE with 2-sentence justification
2. Key Metrics Table:
   | Factor | Finding | Benchmark | Assessment |
3. Analysis — max 150 words, cite specific policy sections
4. Recommended Actions:
   - Numbered list, each with: action, owner, deadline
5. JSON Summary (for system integration):
   {"decision": "...", "confidence": 0-100, "top_risk": "..."}
    

💡

Pro tip: You can mix human-readable sections (1-4) with machine-readable JSON (5) in the same prompt. The AI handles both formats in one response. This is how production templates work — the human reads the narrative, the system reads the JSON.

The Best Default Format: Markdown (.md)

When you ask AI to produce a report, analysis, or any reusable document — ask for Markdown. It's the format that works best for both humans and AI.

Format	Human readable	AI readable	Token cost	Reusable
PDF	✅	❌ Can't parse	N/A	❌
Word (.docx)	✅	⚠️ Partial	N/A	❌
HTML	⚠️ Tags clutter	✅	High (~20 tokens/heading)	✅
Markdown ✓	✅	✅	Low (~8 tokens/heading)	✅

How to ask for it:

Save the output as "claims-review.md" with:
- ## headings for each section
- | tables | for data comparisons
- - bullet lists for action items
    

🔗

Why this matters for you: In the agentic AI world, every artifact you create — steering files (.kiro/steering/rules.md), skills (SKILL.md), agent configs — is Markdown. It's the interface layer between you and AI: structured enough for machines, readable enough for humans, and 60% fewer tokens than HTML.

The Research Behind Markdown for AI

This isn't just a convention — research and industry practice back it up:

Finding	Impact	Source
Markdown vs HTML token usage	60% fewer tokens for same content structure	Token comparison (heading: ~8 vs ~20 tokens)
Markdown vs JSON for LLM comprehension	16% average token savings with equal or better accuracy	Format performance benchmarks
Table extraction accuracy	Markdown 60.7% vs HTML 53.6%	ReleasePad, 2025
RAG retrieval with clean Markdown	Up to 35% better retrieval accuracy, 20-30% fewer tokens	AnythingMD
llms.txt web standard (Sept 2024)	Websites now serve Markdown specifically for AI agents	Jeremy Howard, Answer.AI
LLM Markdown awareness research	LLMs are expected to produce structured Markdown for readability	arXiv:2501.15000, 2025

💡

The industry is converging on Markdown as the standard interface between humans and AI. LLMs are trained on it, tools expect it, and it costs less. The llms.txt standard (proposed by Jeremy Howard of fast.ai in September 2024) is like robots.txt but for AI — websites now serve Markdown files at their root specifically for AI agents to read. When you write a steering file, a SKILL.md, or ask for a report — Markdown is the right default.

🔧 Advanced: XML Tags for Claude (Optional)

This section is for technical team members (Cloud COE, Platforms). Most business users can skip this — the plain-text techniques above are all you need for daily use.

When building prompt templates at the code level (Bedrock API, application backends), developers often wrap prompt sections in XML tags. This is how Anthropic recommends structuring complex API calls — the tags create unambiguous boundaries between instructions, data, and constraints.

// Typically constructed in application code, not typed by hand:

<role>Senior Claims Adjudicator, 12 years in life insurance</role>

<data>
Policyholder: John Tan (Policy #LI-2024-88421)
Claim type: Critical Illness
Sum assured: $300,000 SGD
Diagnosis: Stage 2 colorectal cancer
Policy inception: 18 months ago
</data>

<task>Assess claim validity. Produce an APPROVE/REFER/DECLINE decision.</task>

<constraints>
- ONLY use data in <data> tags
- Max 300 words
- Cite relevant policy sections
</constraints>
    

Pattern	Tags	When to use
Claims analysis	`<data>` `<task>` `<format>`	Analyzing claims, medical reports, loss assessments
Policy Q&A	`<document>` `<question>` `<rules>`	Policy lookups, coverage checks, exclusion queries
Multi-step	`<context>` `<step1>` `<step2>`	Complex workflows, underwriting assessments
Review	`<draft>` `<criteria>` `<instructions>`	Reviewing reports, correspondence, regulatory submissions

🔍

Where XML tags live in practice: In production systems, the developer builds the prompt template with XML tags programmatically. The end user fills in a form or pastes data — the application wraps it in <data>...</data> tags behind the scenes before sending to the Bedrock API. You design the content; your tech team handles the XML structure. For daily use in Claude or Kiro, plain-text headers (### ROLE, ### CONTEXT) work just as well.

🔒 RAG Grounding: Only YOUR Data

Without grounding rules, the AI mixes its training data with your documents — you can't trace which claims come from where. In an audit or MAS inspection, that's a disaster.

CRITICAL GROUNDING RULES:
Base your answer ONLY on the provided documents
After each claim, cite: [Doc Name, Section]
If not in documents: "Not available in provided documents"
Do NOT use outside knowledge
    

❌ Without RAG Grounding

Q: "What happens if a policyholder misses 3 premium payments?"

The policy typically enters a grace period and then lapses. The policyholder usually has 30 days to pay before the policy is terminated. They may be able to reinstate within 2 years with evidence of insurability.

⚠️ Sounds plausible but NONE of this may match your actual policy wording. "Typically" and "usually" = hallucination.

✅ With RAG Grounding

Q: Same question + policy document attached + grounding rules

Per AnyCompany Life Policy Terms v4.1:
• After 1 missed payment → 31-day grace period [Section 12.1]
• After grace period → Automatic Premium Loan if cash value sufficient [Section 12.3]
• If no cash value → Policy lapses [Section 12.4]
• Reinstatement: within 24 months, subject to health declaration [Section 13.1]
• [INSUFFICIENT DATA: No information on premium waiver rider in provided document]

✓ Every claim cites a section. Admits what it doesn't know. No hallucination.

🔧 Interactive Prompt Builder

Toggle techniques on/off to see how the prompt AND the AI's response change. Watch quality improve as you add each technique.

👤 Role 📚 Context 📋 Structure 🔒 Grounding 🧠 CoT 🏷️ XML Tags

📝 Your Prompt 0 words

Loading...

🤖 AI Response

Loading...

💡 What changed: Toggle techniques above to see how the AI response improves.

📊 Quality Score

Completeness

2/5

Data Grounding

1/5

Actionability

1/5

Consistency

2/5

6/20

Needs work — toggle more techniques

🔍 Issues in AI Response

⚠️ 7 Prompt Mistakes Everyone Makes

Recognize these patterns? Fix them with one-line additions to your prompt.

Mistake	Why it hurts	Quick fix
🍳 The Kitchen Sink	Cramming 5 tasks into 1 prompt	One task per prompt, chain results
📄 The Blank Canvas	No examples = AI guesses your format	Show 1-2 examples of desired output
🙈 The Trust Fall	No grounding = confident hallucinations	"ONLY from provided data"
🔍 The Vague Ask	"Analyze this" — analyze what, how, for whom?	Specify audience, format, length
⏱️ The One-Shot Wonder	Expecting perfection on first try	Plan for 2-3 refinement turns
📋 The Copy-Paste Trap	Same prompt for different models	Tune syntax per model family
⚙️ The Set-and-Forget	Never re-testing after model updates	Monthly prompt health checks

🔄 The 3-Round Improvement Workflow

Every production-quality prompt goes through this cycle:

Round	What you do	Result
1. Baseline	Write prompt using 4 pillars. Run 3 times.	See what AI gets right and wrong (~60% quality)
2. Fix failures	Add negative constraints + example of good output. Run 3 more.	Consistency jumps to ~85%
3. Polish	Add self-review step. Tighten format. Test edge cases.	Production-ready at ~95%

💡

Total time: 15-20 minutes to go from first draft to production template. That template then saves hours every week — imagine every claims summary, underwriting memo, or compliance check following the same quality standard automatically.

🚫 Tell the AI What NOT to Do

Negative constraints prevent common failure modes:

Problem	Add this constraint
AI adds unsolicited opinions	"Do not include personal opinions or speculation"
AI uses data not in your input	"Do not reference any data outside the provided documents"
AI writes too much	"Do not exceed 300 words"
AI hedges everything	"Do not use phrases like 'it depends' or 'generally speaking'"
AI explains obvious things	"Do not explain what life insurance is or how premiums work"
AI invents numbers	"If a metric is not in the data, write [DATA NOT AVAILABLE]"

🔍

Source: Claude's prompting best practices recommend telling Claude what to do instead of what not to do for general instructions, but negative constraints are highly effective for preventing specific failure modes — especially in insurance where hallucinated policy terms or fabricated claim amounts are dangerous. Claude Prompting Best Practices →

🧠 The #1 Misconception: "AI Remembers Me"

It doesn't. Each session is completely isolated. The AI has zero memory of previous conversations.

❌ What people think

"It remembers our conversation from last week"
"I should keep this tab open so it doesn't forget"
"My old sessions are giving it context"

✅ How it actually works

Each session starts with zero memory
Old tabs have no effect on new sessions
Closing old sessions is safe — cosmetic, not functional

What persists	What doesn't
✅ Files in your workspace (reports, templates, code)	❌ Chat conversation history
✅ Steering files (.kiro/steering/) — loaded every session	❌ What you said 3 sessions ago
✅ Skills (.kiro/skills/) — activated by keywords	❌ Old tabs or closed sessions
✅ Custom agents (.kiro/agents/) — invoked by name	❌ Your "relationship" with the AI

💡

The mental model: chat is ephemeral, files are permanent. Save important outputs as files. Reference files (not old chats) when you need context in a new session. Steering files and skills ARE the AI's persistent memory — they're loaded automatically into every new session.