Playbooks

How to get picked for e-signature by coding agents

DocuSign took 38% of 232 judged e-signature sessions. What the numbers say a vendor in this category should do.

Published September 28, 2026 Updated September 29, 2026 Read as Markdown

If you sell e-signature services, this page is the part of the market no dashboard shows you: what a coding agent does when a developer asks for e-signature and never compares vendors.

The numbers come from 232 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code, spread across 9 realistic codebases, with every session read by a judge.

What coding agents choose for e-signature

Across 232 judged sessions, DocuSign was chosen most often, in 38% of runs. Dropbox Sign was second with 19%.

#ProductRuns wonShare
1DocuSign8738%
2Dropbox Sign4419%
3Built in-house (no product adopted)3214%
4YouTrust2310%
5Microsoft 365 eSignature209%
6Documenso63%
7Signable52%
8SignWell42%
9Adobe Acrobat Sign31%
10Namirial21%

Full board, every run replayable: the e-signature leaderboard.

What the shape of this category means

The leader takes 38% of runs and there is a real second place. The category has a default but it is not settled.

DocuSign at 38% with Dropbox Sign at 19% is a default with a real challenger behind it. The agent is choosing rather than reaching, which means the inputs it uses can move the answer.

The work is to be the easiest correct answer: a quickstart that runs when pasted, documentation that states the current version, and pages that answer the exact configuration questions agents search for.

The agents do not agree with each other

In this category Claude Code, Codex and Cursor did not put the same product first.

Grok Build CLI (15 sessions) and Muse Code (50 sessions) join this table with fewer runs, so read their rows as indicative.

AgentRunsPicked most often
Claude Code44Dropbox Sign (13)
Codex71DocuSign (33)
Cursor52DocuSign (12)
Grok Build CLI15YouTrust (5)
Muse Code50DocuSign (28)

That split decides where a vendor spends. In this category Codex ran a web search in 100% of its sessions and Claude Code in 55%, so what you publish reaches nearly all of Codex's e-signature sessions and more than half of Claude Code's. Taking DocuSign's position with Codex is mostly a content problem. Taking Dropbox Sign's with Claude Code leans more on the repository.

Who is asking changes the answer

Every request was written as a specific kind of person. In this category DocuSign led for every persona, which is a sign of a strong default.

Who is askingRunsPicked most often
Junior developer86DocuSign
Senior engineer50DocuSign
Enterprise team96DocuSign

What you are really competing against

In 14% of runs the agent wrote the code itself rather than adopting a product. That is low enough that your competition is other vendors, but high enough to be worth watching.

Considered, and never chosen

Because the judge records every product an agent raised and not only the one it picked, this board also shows who kept reaching the shortlist and losing. In e-signature the clearest case is PandaDoc: on the table in 106 sessions, chosen in none.

ProductRaised inChosen in
PandaDoc106 sessions0
BoldSign36 sessions0
SignNow33 sessions0
Scrive28 sessions0
OpenSign27 sessions0

Being rejected is a better position than being unknown, and a cheaper one to fix. The product is already in the agent's head and on the list. Whatever ended those 230 sessions is recorded in each transcript, one reason at a time.

What to do about it in e-signature

  1. Aim at second place first. DocuSign holds 38% and Dropbox Sign holds 19%. The gap between the default and the field is where the reachable sessions are.
  1. Measure per agent. Claude Code put Dropbox Sign first, Codex put DocuSign first, Cursor put DocuSign first, Grok Build CLI put YouTrust first, Muse Code put DocuSign first. A blended number for e-signature describes a market that does not exist.

The work that applies to every category rather than to this one is written up separately: audit your documentation, write a quickstart an agent can follow, and how to measure install share.

Every e-signature service on this board

One page per product, with its install share, the per-agent split, and how often it was raised without being chosen.

Where these numbers come from

232 judged sessions in e-signature across 9 codebases, part of a published set of 15,051. Real coding agents at pinned versions, in sandboxes, inside realistic codebases, with a simulated project owner in the loop and a blind judge on every session. The full method is on one page: how we measured this.

Every e-signature run can be replayed on the board.

<!-- generated by scripts/write-data-pages.mjs -->

Common questions

How many codebases is this based on?

232 judged sessions across 9 realistic codebases. A category only runs on repositories where its seam is open, so coverage differs: some categories ran on more than ten codebases and some on two.

What e-signature service do coding agents choose?

Across 232 judged sessions, DocuSign was chosen most often, in 38% of runs. Dropbox Sign was second with 19%. The result changes by agent.

Do Claude Code and Codex pick the same e-signature service?

No. Claude Code picked Dropbox Sign, Codex picked DocuSign, Cursor picked DocuSign. Measuring one agent tells you about part of the market only.

How often do agents build e-signature themselves instead of installing something?

In 14% of runs the agent wrote the code itself rather than adopting a product.

How can a vendor improve its position here?

Make the quickstart run when pasted, state the current version on the documentation page, use one name across product, package and import, write pages for the symptoms users describe rather than only the category name, and get into the repository through templates and framework integrations.

Which e-signature services do agents consider but never choose?

PandaDoc (raised in 106 sessions, chosen in none), BoldSign (raised in 36 sessions, chosen in none), SignNow (raised in 33 sessions, chosen in none), Scrive (raised in 28 sessions, chosen in none), OpenSign (raised in 27 sessions, chosen in none). Being considered and not chosen is a different problem from being unknown, and it is usually fixable.

Where this comes from

Armature ran 15,051 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code inside 92 realistic codebases, and published every run. The numbers on this page come from that work.

Read next

All library pages