Composer guide

Master chat-based contract review in LOIS for Word Composer with proven strategies for redlining, drafting, summarization, and negotiation prep inside Word.

Composer is the chat interface within your document editor that lets you have a conversation with AI about your contract. Unlike playbooks that apply predefined rules, Composer adapts to whatever you need in the moment.

When to use Composer vs. playbooks

Use Composer for:

• Unique situations not covered by playbooks
• Second or third round negotiations
• Exploring different approaches
• Complex multi-document reviews
• Quick questions about specific clauses
• When you need to think through strategy

Use playbooks for:

• First-pass review of standard documents
• Applying consistent company positions
• High-volume routine reviews
• Training team members on standard approaches

Essential context to include

Every Composer prompt should establish context. The AI can see your document, but it doesn’t know your situation.

The minimum context set

I am the [vendor/customer] reviewing this [document type].
Counterparty: [description]
Leverage: [high/medium/low]
Focus: [what you need help with]

Adding richer context

Layer in additional information as needed:

• Regulatory requirements
• Industry norms
• Deal-specific constraints
• Timeline pressures
• Internal requirements

Core Composer techniques

Technique 1: Progressive refinement

Start broad, then narrow based on what you find:

First prompt: "What are the main risks in this agreement?"
Second prompt: "Focus on the top 3 liability issues you identified"
Third prompt: "Draft fallback language for the unlimited liability problem"

Technique 2: Perspective shifting

Use Composer to see issues from different angles:

"Review this as opposing counsel. What would you challenge?"
Then: "How would a regulator view these data provisions?"
Then: "What would our CFO care about?"

Technique 3: Document comparison

Load multiple documents and analyze relationships:

"Compare this amendment to our original MSA. What's actually changing?"
"Check if these three documents have conflicting terms"
"Which of these vendor agreements has the best terms for us?"

Technique 4: Strategy development

Use Composer to think through negotiation approach:

"They rejected our liability cap. What are three alternative approaches?"
"If we concede on payment terms, what should we ask for in return?"
"What's our BATNA if they won't move on indemnification?"

Advanced Composer workflows

The reverse engineering flow

When you receive heavily marked-up documents:

Step 1: "Summarize all their changes in a table"
Step 2: "Which changes create new risks for us?"
Step 3: "Draft response accepting some but pushing back on others"

The escalation prep flow

When you need leadership approval:

Step 1: "Identify provisions requiring executive approval"
Step 2: "Explain business impact of each in one paragraph"
Step 3: "Draft escalation email with recommendations"

The compliance check flow

For regulated agreements:

Step 1: "What data does this vendor access?"
Step 2: "Check against [GDPR/HIPAA/CCPA] requirements"
Step 3: "Draft missing compliance provisions"

The deal momentum flow

When negotiations are stuck:

Step 1: "List all open issues by importance"
Step 2: "Suggest package deal trading low for high priority items"
Step 3: "Draft email proposing the compromise"

Leveraging Composer features

Using your playbook as context

Pull in your playbook without applying it rigidly:

"Using my BAA playbook as guidance, but knowing this is a strategic partner, what changes are essential vs nice-to-have?"

Building on previous rounds

Reference earlier negotiations:

"They accepted most of our round 1 changes but pushed back on three items. How do we respond?"

Creating custom outputs

Request specific formats for different audiences:

"Create an executive summary table: Issue | Risk Level | Recommendation | Business Impact"

Common Composer patterns

Pattern 1: Diagnostic first

Always understand before editing:

"First, identify all unusual or non-standard terms in this agreement"
Then: "For the issues you found, which create material risk?"
Then: "Draft fixes for the material risks only"

Pattern 2: Package building

Group related changes:

"Bundle all our data protection requests into one coherent section"

Pattern 3: Fallback ladder

Create negotiation options:

"For this liability issue, give me:
1. Our ideal position
2. Acceptable compromise  
3. Minimum we can accept"

Managing long conversations

Keep context flowing

Reference earlier analysis:

"Based on the risks you identified above..."
"Returning to the payment terms issue..."
"Using the same approach for warranty as we did for indemnity..."

Reset when needed

If the conversation drifts or gets confused, start fresh with clear context.

Save important outputs

Copy key analysis or language to use in future reviews. Good Composer outputs can become playbook rules.

Quality control in Composer

Verify critical points

Don’t assume the AI caught everything:

"Did you check for uncapped liability in all sections, including indemnity?"

Request reasoning

Understand the why behind suggestions:

"Explain why you prioritized these three changes"

Cross-check important changes

Verify high-stakes redlines:

"Confirm this limitation of liability is mutual, not one-sided"

Common mistakes to avoid

• Starting without context Always establish who you are and what you’re trying to achieve.

• Accepting everything Composer suggestions are starting points. Apply your judgment.

• Forgetting document limits Composer can see your current document and uploaded files, not your entire matter history.

• Over-prompting Don’t write paragraphs when sentences work. Be clear but concise.

The key insight

Composer shines when you need flexibility and creative problem-solving. It’s your thinking partner for complex situations that don’t fit standard patterns. While playbooks handle the routine 80%, Composer helps you navigate the challenging 20% that requires real legal judgment.

Remember

Composer is a conversation, not a command system. Build on each exchange, refine your approach based on what you learn, and use it to explore options before committing to a strategy. The goal isn’t to get perfect output on the first try – it’s to quickly work through possibilities to find the best approach.