Your Agreements Are a Database You Can't Query — Hiral Shah, Docusign & Sean Sodha, NVIDIA

A company can negotiate pricing carefully and still struggle to recover what it agreed to buy. Hiral Shah, a senior director of product at Docusign, opens with this everyday problem: important business terms sit inside signed agreements in forms that other systems cannot readily use. With Sean Sodha, a product manager at NVIDIA, she explains how Docusign is turning that document collection into structured, queryable information.

The workload is substantial. Shah reports 1.9 million paying customers, a billion users and a million agreements processed each day. She also cites a study conducted with Deloitte estimating $2 trillion in negotiated agreement value that organizations do not capitalize on. Recovering the terms requires people to read documents, review them and move information through disconnected systems. The estimate describes unused negotiated value; it does not measure savings delivered by the extraction system.

Docusign’s intelligent agreement management platform, IAM, spans creation, negotiation, redlining, signing, storage and analysis. After signing, the challenge becomes answering questions from PDFs, images and repositories containing ten or twenty years of business history. The documents also have a hierarchy: one agreement can govern another. A useful answer may therefore require information from several related agreements.

Shah makes the problem concrete with a company asking how many total tokens it contracted for with Claude. The terms exist somewhere in the agreements, expressed in different forms. Finding the relevant words is only part of the work. The system must recover their meaning and organize them so the company can ask questions across its agreements.

Pricing tiers, SKUs, service-level agreements and rate cards often appear in tables. Shah says traditional extraction tools and generic vision language models failed on the tables Docusign tested. The failure is structural: reading a page line by line can retain the text while losing which values belong together.

A merged cell can apply across several rows or columns. Once a parser flattens the table into a sequence of words, that scope becomes harder to recover. The extractor needs to preserve the arrangement of the table as well as its contents, because the arrangement helps determine how the commercial terms apply.

When the structure disappears, legal, procurement and sales teams must reconstruct it from the original page. Shah describes people spending hours even locating basic terms. Docusign’s partnership with NVIDIA targets that particular source of manual work: table extraction that understands layout, so downstream users receive structured commercial data.

Sodha places extraction within Nemotron Retriever, NVIDIA’s work on embedding, re-ranking and document-extraction models. He separates two tasks: finding the right document in a petabyte-scale corpus, and finding the right information inside that document. Returning a handful of relevant documents still leaves the system with the job of reading their tables correctly. Docusign’s collaboration focuses on that second task.

Sodha expands on why tables are difficult: nested tables, merged cells, merged columns and merged rows create many possible layouts. NVIDIA’s surrounding approach includes publishing model weights, datasets, techniques and supporting blueprints. He names quantization, distillation and pruning among the techniques shared with developers. The model at the center of this integration is Nemotron Parse, which recovers document structure and is used here for table extraction.

What one model invocation returns

Sodha describes the parser as approximately 850–900 million parameters, much smaller than the multi-billion-parameter vision language models he contrasts it with. A single invocation consolidates work that might otherwise use separate models for tables and page elements. Its outputs preserve several distinct parts of the document:

• Text and semantic formatting: the content and its organization.
• Layout and reading order: where elements belong and the sequence in which they should be read.
• Table structure: the relationships needed to keep complex tables intact.

The model can be served through NVIDIA NIM or vLLM.

Sodha calls it an extractor because the task is to recover the supplied document’s content and structure. This describes its purpose. As he explains later, the model still produces its output one token at a time. A single document-processing invocation can therefore contain sequential token generation; consolidating the extraction tasks does not make decoding simultaneous.

NVIDIA aims to improve the accuracy-versus-performance Pareto curve: give enterprises a better combination of extraction quality and speed. Sodha introduces a table-extraction benchmark comparison against other open-source models. His spoken explanation does not provide numerical accuracy scores or enough comparison detail to reconstruct a ranking.

The Agreement Manager demonstration follows one order form through the product. Agreement Manager is a central repository of signed agreements, with options to upload a file from a computer or import it from elsewhere. Selecting the order form starts uploading and AI processing; a jobs engine handles the processing before Shah opens the file to inspect the results.

Inspect a term or take the data elsewhere

The walkthrough presents two useful ways to work with the extraction:

• Return to the source: key terms and commercial details appear as structured metadata, with highlights and navigation to the section containing each detail. A reader can inspect a term in its original context.
• Use structured pricing: NVIDIA’s parser breaks complex pricing tables into order details. Shah downloads the data as CSV for finance, procurement or further analysis, and describes API access as another way to carry it into other systems.

Shah describes results appearing within seconds, then notes that the demonstration was shortened. It illustrates the upload-to-output flow without establishing a general latency guarantee. Docusign’s companion integration post describes Nemotron Parse table extraction in Agreement Manager as accepting beta customers, with general availability ahead. That is the availability stated in the post, rather than a determination of availability at the recording date or today.

API availability also needs that distinction. Shah describes API access in the walkthrough, while the companion post describes a public API for direct downstream integration as forthcoming. The demonstrated export flow and the planned public integration interface should therefore be understood separately; the descriptions do not establish general availability of a public API.

Customers’ repositories range from thousands to millions of agreements. Docusign uses a proprietary agreement data model to structure information both within each agreement and across an organization, with search above that model. This lets the extraction serve legal staff, procurement teams, salespeople and business leaders. Shah does not explain the schema or how the system resolves the governing relationships between agreements, so the parser’s table output provides only part of the explanation for organization-wide answers.

After trying different models for different purposes, Shah’s central decision is to choose a model for the job it needs to perform. She credits purpose-built models with helping Docusign bring capabilities to market faster. In this workload, using less context also reduced latency and delivery cost. Parameter count and context size are separate considerations, but both matter when planning extraction at a million agreements a day.

Shah reports that Nemotron was twenty times faster than the other open-source models Docusign tested, measured in tables extracted per second. That throughput gain matters for a large ingestion workload. It does not establish a twentyfold improvement in the entire agreement pipeline. She does not specify the comparison models, hardware, batch sizes or absolute throughput, so the result remains tied to Docusign’s reported evaluation.

The partnership’s next planned step moves from extracting information on a page to finding the relevant page in the first place. Sodha describes further retrieval work and discussions around NVIDIA Agent Toolkit, followed by more production-scale agents. These are proposed extensions of the collaboration, rather than features demonstrated in the order-form walkthrough.

The Q&A asks whether an agent could bypass optical character recognition, or OCR, and extract only the structure relevant to a question. Shah allows that dynamic processing can work for smaller, reactive use cases. When a query spans thousands of agreements, however, she wants the documents already processed and the relevant information already identified. Otherwise, document processing adds to the user’s wait for an answer.

Downstream operations provide another reason to extract terms ahead of time. Shah’s example is a procurement team putting a contract’s pricing table into Coupa to help payments match the agreed prices. That workflow needs structured terms available for continuing business use. An agent may assist, but answering questions one document at a time does not meet the whole requirement.

Repository throughput and immediate Q&A need different settings

Sodha explains the choice in terms of when the system spends compute:

• Large repository: process the collection upfront, including OCR, so later queries can use information already extracted. The ingestion workload emphasizes throughput across many documents.
• New upload for Q&A: process a newly submitted contract quickly enough to support an immediate interaction. The user’s wait makes latency more important.

Batch sizes, concurrency and processing techniques should change with those goals. The engineering decision includes the processing schedule as well as the model.

A follow-up question clarifies what Docusign retains: a hybrid pipeline with two processing routes. The table route combines layout understanding and extraction. OCR still handles other fields, metadata and clause text. The small parser consolidates work for tables, while other document-processing modules remain necessary. The flow below shows those routes and the later uses of extracted data, without specifying an internal routing or search algorithm.

Asked about quantization, Sodha says the model currently uses FP16, with paths toward FP8 and FP4 over the following months. These are numerical precision formats: the numbers refer to 16-, 8- and 4-bit representations. Moving toward lower precision is one proposed way to improve inference performance. He names Blackwell and NVFP4 as part of NVIDIA’s direction. Shah indicates that Docusign uses the discussed precision and some older models, but does not give a precise breakdown of its deployed configurations. No measured production result from the proposed lower-precision changes is reported.

The remaining performance levers

Sodha identifies several ways to improve the parser:

• Quantization: move toward lower-precision formats as part of the hardware and inference strategy.
• Multi-token generation: improve on the current one-token-at-a-time output process by generating multiple tokens at a time.
• Encoder-decoder optimization: further tune the VLM architecture’s encoding and decoding.

These are possibilities, rather than reported speedups. His priority is to establish that the extraction is accurate and adds value, then improve the performance side of the Pareto curve.

The final questions return to deployment and search. Sodha says he believes Docusign deploys directly through vLLM. Docusign’s companion post explicitly confirms that serving choice and says sensitive agreement data stays within Docusign’s environment. The post supplies that deployment detail, while Sodha’s answer itself remains tentative.

An attendee then asks about the retrieval mechanism behind the demonstration. Shah’s answer is narrower: the information comes from agreement data already extracted and stored. She does not specify an embedding index, graph-based retrieval method or search algorithm. The explanation ends with a useful separation of responsibilities: extraction makes the contract terms available as data, and the system’s question-answering features consume that stored information. How those features select the relevant data remains unspecified.