Use cases

Four concrete jobs an agent + human can run together.

Each vignette below is structured the same way: an agent does the operational work over the CLIs, and a human approves the gates that need a deliberate gesture (a signature, an escalation override, a final-position acceptance). The shell snippets show what the agent invokes; the bolded steps show where the human steps in.

1. Vendor onboarding NDA at scale

You're an ops lead at a 60-person company onboarding 10–20 vendors a quarter. Each one needs an NDA before any technical conversation starts. Today: legal sees every one, slows to a week per vendor.

With the CLI suite, you push a single house template through draft with the vendor's details, run review to confirm it matches policy, hand it to sign-cli, done in 90 seconds. Legal only gets pinged when review escalates a finding.

# In a CSV with vendor name, address, contact email
while IFS=, read -r name addr email; do
  draft templates/mutual-nda.docx \
    --party-a "Acme Inc." --party-a-address "123 Main St" \
    --party-b "$name" --party-b-address "$addr" \
    --purpose "vendor evaluation" \
    --output "out/$name.docx"

  nda-review-cli review --file "out/$name.docx" --why --silent

  docx2pdf "out/$name.docx" "out/$name.pdf"

  sign request create --document "out/$name.pdf" \
    --signer "name:Alice Founder,email:alice@acme.com,order:1" \
    --signer "name:$name,email:$email,order:2" \
    --provider signwell
done < vendors.csv

If review later flags a counterparty redline that's outside your stance, the negotiation flow takes over — same files, no portal switch.

2. M&A diligence — bulk NDAs across deal partners

During diligence you need NDAs with bankers, accountants, advisors, target-company employees, sometimes 30+ counterparties in a week. Each one wants their own boilerplate; nobody has time to one-shot-redline that many.

Run review --learn-profile on each incoming counterparty so the CLI builds a stance fingerprint per firm. Repeat parties (same banker, different deals) get a consistent stance automatically. When a counterparty's amendments cross your non-negotiable redlines, you escalate to counsel; otherwise the auto-counter does its work.

for f in incoming/*.docx; do
  nda-review-cli review --file "$f" --why \
    --counterparty "$(basename "$f" .docx | tr '_' ' ')" \
    --learn-profile \
    --out-md "review/$(basename "$f" .docx).md"
done

# Aggregate the per-vendor reviews into one file
cat review/*.md > review/summary.md

Every review writes a hash-chained record — useful when post-close discovery asks who saw what when.

3. Employment paperwork — confidentiality + IP assignment

Onboarding an engineer needs an NDA, an IP assignment, and often a non-compete (where enforceable). Today: HR sends three docs, each via a different e-sign tool, audit trails scattered across vendor dashboards.

Bundle the three docs into a single request with sign request create (repeat --document). The receipt for the whole onboarding lives as one hash-chained file on disk; if the new hire later files a dispute, you can hand the verified bundle to opposing counsel without asking three separate SaaS vendors for export.

# One request, three documents, one signer — a single hash-chained flow
sign request create \
  --document nda.pdf --document ip-assignment.pdf --document noncompete.pdf \
  --signer "name:Alice,email:alice@acme.com,order:1" \
  --provider signwell

# Later — verify the signed PDF offline, even years from now
sign pdf inspect --pdf nda.signed.pdf

4. Pre-signature drift gating — the "did the PDF still match what we agreed?" check

A negotiation finishes. Counsel converges on text, both sides sign off in nda-review-cli. The agreed text gets rendered to PDF, packed up, routed through a docusign-style flow, and a week later lands back in your inbox as a "ready-to-sign" attachment. Sometime in that round trip — paralegal cleanup, a template auto-fill, an opposing-counsel "minor correction" — the term changed from two years to three. Today: you notice (or don't) at signing time.

Run compare-cli as the gate immediately before sign-cli. It pulls the agreed text from negotiation.json, classifies every difference in the candidate PDF as cosmetic / typographic / substantive, and exits non-zero if anything material has shifted. --require-signoffs double-locks the gate to also require both parties' sign-off metadata to be populated.

# Single CI step or shell guard before sign-cli
compare --from-negotiation output/negotiation.json output/ready-to-sign.pdf \
  --require-signoffs --check \
  || {
    case $? in
      2) echo "✗ substantive drift — escalate to counsel" ;;
      3) echo "⚠ cosmetic-only drift — review and waive if intentional" ;;
      4) echo "⚠ clauses moved, content identical — review" ;;
      *) echo "✗ I/O or precondition error" ;;
    esac
    exit $?
  }

# Only on exit 0 do we proceed to sign
sign request create --document output/ready-to-sign.pdf \
  --signer "name:Alice Founder,email:alice@acme.com,order:1" \
  --signer "name:Bob Counsel,email:bob@beta.com,order:2"

The agent runs this in seconds; the human is only paged when exit-class is substantive. For richer review, compare --sarif produces a SARIF v2.1.0 document that lands in the GitHub PR review UI as inline annotations on the contract file.

What these have in common

• Composable. Each step is a CLI invocation. You can wire them together with shell scripts, GitHub Actions, n8n, anything.
• Local artifacts. Every output lives on disk in a standard format. No "log into the dashboard to download."
• Agent-friendly. Same primitives over MCP — your operations agent can run the same flow.
• Cheap. The CLIs are free; you only pay your e-sign provider per envelope.

Use cases the CLIs are not ideal for

• Cross-team discussion threads. If finance, legal, and sales all need to comment in one place, you want a SaaS suite. The CLI workflow assumes one operator per document.
• Procurement orchestration. Vendors like Coupa or Ironclad plug into a procurement tool's RFP flow. Replicating that with the CLIs is doable but custom.
• Documents you don't actually want auditable. If you'd rather logs be vendor-controlled and disposable, this isn't the right shape.