GitLaw How-To guides
Negotiate and redline a contract with the other side
To negotiate a contract in GitLaw, share your draft with the counterparty by email from the document's share panel. They redline their own copy and submit their edits back as a change request, which appears as track changes on your document. Ask the Agent to analyse their edits and suggest responses, accept or reject each change, and repeat until both sides converge.
Before you start: your contract in GitLaw, and the counterparty's email address.
How do I run a negotiation in GitLaw?
GitLaw supports the complete negotiation lifecycle: draft, share, redline, counter-redline and converge, with each side's context kept entirely separate. Track changes work exactly as they do in Microsoft Word, so you can exchange DOCX files with counterparties who do not use GitLaw without losing any markup.
- Prepare your draft. Open or upload your contract. Before sending, you can ask the Agent to check it against your playbook, flag one-sided clauses and tighten the language. See Review a document using Agent. If you want your edits recorded as redlines rather than direct changes, turn on Track Changes in the editor toolbar; all subsequent edits, including those generated by the Agent, appear as track changes attributed to you.
- Share the draft with the counterparty. Invite the other side by email from the document's share panel. Counterparties receive Viewer access by default: they can read the document and create their own working copy but cannot edit your original. See Share a document or invite a counterparty.
- The counterparty redlines their copy. The other side works in their own copy. Their Agent only has access to their own context and playbooks: your internal notes, negotiation tactics and playbook details are never shared. When ready, they submit their edits back to you as a change request, similar to a pull request in version control. GitLaw computes the diff and presents their changes as track changes on your base document.
- Review the counterparty's redlines. Open the incoming change request to see the other side's edits highlighted inline: insertions in colour, deletions as strikethrough. Ask the Agent to analyse the changes, for example "Summarise what the other side changed and flag any high-risk edits", "Compare their edits against my playbook and suggest responses", or "Draft a reply email that accepts the liability cap and counters the indemnity clause". The Agent can suggest counter-redlines, which appear as additional track changes for you to review before accepting. See Accept or reject tracked changes.
- Set your negotiation posture (optional). Before asking the Agent to propose counter-redlines, tell it in chat how you want to negotiate, for example a collaborative approach or a firm line. This influences the tone and assertiveness of its suggestions without changing your underlying playbook. See Use playbooks and negotiation posture.
- Return your counter-redlines. As the owner of the original document, you do not send a change request back; you make your edits directly in the document. Accept the changes you agree with, reject the ones you do not, add your own changes with Track Changes on if you want them recorded, and leave comments where useful. The counterparty then raises their next round of change requests against the updated document. Each round creates a new version with a full diff and audit trail.
- Converge and finalise. Once both sides accept all outstanding track changes, ask the Agent to run a final check: cross-references and defined terms are consistent, and signature blocks and exhibit attachments are complete. Export a clean DOCX (all changes accepted) or PDF for execution; the DOCX opens in Word with no residual redline markup.
What can each sharing role do?
| Role | Can do |
|---|---|
| Viewer (counterparty default) | Read, copy the document, submit a change request |
| Editor | Edit, accept/reject changes, reshare |
| Owner | Full control, including deletion and participant management |
For a detailed explanation of roles, see File sharing permissions in personal and organisation accounts.
Key points to remember
- Word compatibility. GitLaw track changes round-trip through DOCX. Redlines you produce in GitLaw open correctly in Microsoft Word, and DOCX files with existing redlines import into GitLaw preserving all markup and author attribution.
- Data isolation. Each party's Agent works only with that party's own context, playbooks and history. The only information that crosses the boundary is the document itself and its track changes.
- Human in control. All Agent-suggested redlines appear as track changes pending your explicit accept or reject; nothing is applied to the document automatically.
- Audit trail. Every share action, role change and negotiation round is logged with actor, timestamp and scope.
Frequently asked questions
Can my counterparty see my playbook or notes?
No. Each party's Agent works only with that party's own context, playbooks and history. Only the document and its track changes cross the boundary.
Does the counterparty need GitLaw to negotiate with me?
No. Track changes round-trip through DOCX, so you can exchange Word files with counterparties who do not use GitLaw without losing any markup.
Can the Agent apply redlines without my approval?
No. All Agent-suggested redlines appear as track changes pending your explicit accept or reject.
Related articles
- Accept or reject tracked changes
- Use playbooks and negotiation posture
- Share a document or invite a counterparty
- File sharing permissions in personal and organisation accounts
Reviewed by the GitLaw team. Last updated 29 July 2026.