Docusign Iris is the AI engine behind Intelligent Agreement Management (IAM) that reads agreements by classifying each document, selecting the right model for the job, and extracting structured provisions - parties, dates, financial terms, renewal and termination language, governing law, and custom fields you train - into a queryable schema exposed through the Navigator API. It does this with a flexible model infrastructure that swaps in the latest LLMs tailored for agreements rather than relying on a single fixed model.

That last detail is what makes Iris different from a generic GPT-on-contracts script: Docusign treats model choice as an internal routing decision, picks language-aware models per region, and lands the output in a normalized provision schema your downstream systems can consume. This deep dive walks the full pipeline, the API shape, and where the accuracy ceilings actually are.

What is Docusign Iris AI?

Iris is the AI engine powering AI features across the Docusign IAM platform - eSignature, Workflow Builder, Navigator, and AI-Assisted Review. According to Docusign, the name was chosen for the flower that symbolizes wisdom and trust, and the engine "selects the right agreement AI models for specific use cases." In practice that means Iris is not one model. It is an orchestration layer that:

• Classifies an incoming document into an agreement type (MSA, NDA, SOW, Order Form, Addendum, and so on).
• Routes the document to extraction models tuned for that type and language.
• Returns normalized provisions in a JSON schema you can read via API or use to drive Workflow Builder.
• Feeds the same extracted data into the assistant, agents, AI-Assisted Review, and dashboards.

The practical implication for builders: you do not pick the model. You shape the inputs (document type, custom extraction templates, language) and consume the outputs.

How does Iris turn a PDF into structured data?

The pipeline has four phases.

1. Ingestion and classification. When an agreement lands in Navigator - either through Docusign eSignature, a bulk upload, or the Navigator API ingestion endpoint - Iris first classifies it. Docusign exposes pre-defined types covering common business agreements; the bulk ingestion guide shows agreements arriving with a type field like "Addendum agreement" set by the classifier before any field-level extraction runs.

2. Provision extraction. Once the type is known, the matching extractor pulls structured provisions. The shape is consistent across documents of the same type, which is what makes the output usable in a database rather than just human-readable.

3. Custom extractions. You can extend the schema with your own fields - discount codes, MFN clauses, data-processing terms, anything specific to your portfolio. Docusign's custom extractions guidance describes the training loop: upload a few example contracts, highlight where the language appears, and Iris will recognize the same field on future agreements. This is few-shot in spirit - you teach by example rather than writing regex or rules.

4. Verification. Extractions are surfaced for human review before they are trusted downstream. Docusign documents a Data Review experience specifically for verifying AI-assisted data extractions, which matters because no production team should treat first-pass AI extraction as ground truth.

What provisions does Iris actually extract?

From the Navigator bulk ingestion documentation, a typical extracted agreement looks like this:

The extracted set covers the fields a contract ops team would otherwise pull manually into a spreadsheet:

• Identity: parties and their names as written in the document.
• Dates: effective date, expiration, renewal date, notice period.
• Financial terms: total value, payment terms, currency.
• Lifecycle clauses: renewal type, termination conditions, assignment, exclusivity.
• Jurisdiction: governing law and venue.
• Custom provisions: anything you trained.

Docusign's Agentforce grounding guide shows downstream code reading provisions.expiration_date directly to flag soon-to-expire agreements - which is the canonical use case: turn the unstructured PDF into a field a workflow can branch on.

What does the model architecture actually look like?

Docusign has been deliberately public about one thing: Iris is not married to a single model vendor. The official engineering description is a "flexible model infrastructure" that supports "the latest LLMs - tailored specifically for agreements." In the multilingual context, Docusign describes Iris as using "hybrid AI models, secure infrastructure, and built-in governance" to perform reliably across regions and languages, and the AI globalization post confirms multilingual models are deployed globally with region-specific data residency for extracted data.

Read that carefully: it is hybrid (some proprietary, some third-party), versioned behind an internal abstraction, and chosen per task. A clause classifier on an English MSA is almost certainly not the same model as a custom extraction running on a Japanese-language addendum. You do not see the swap - you see the output schema staying stable.

The partnership signals reinforce this. Docusign announced a partnership with Anthropic on February 24, 2026 to bring IAM into Claude Cowork, and a separate Harvey partnership linking Harvey's legal reasoning to Iris. Both are about agentic workflows reading from and writing back to Iris-extracted data - not replacing the extractor.

How accurate is Iris, and where does it break?

Docusign does not publish a public per-field accuracy benchmark, and we have not seen one we trust. In production work, the failure modes cluster predictably:

• Party name normalization. The parties.name_in_agreement field returns the literal string in the contract ("ACME, INC."), which often does not match a CRM record ("Acme Corp"). Downstream joins need fuzzy matching. Docusign's own Agentforce guide calls this out explicitly as a name-matching constraint.
• Date ambiguity. Effective dates sometimes appear in preambles, sometimes only in signature blocks, and occasionally only by reference ("the date of last signature"). Iris handles the common forms well; reference-only dates are where review queues earn their keep.
• Renewal logic. Auto-renew clauses with conditional carve-outs ("unless either party gives 90 days' notice OR an event of default occurs") get flattened into a single renewal_type. The structured field is correct at the headline level and lossy at the clause level.
• Custom extractions on long-tail clauses. Few-shot custom extractions are strong on language that looks like the examples you trained on. Variants that paraphrase heavily need more examples or human escalation.

The right operating assumption: Iris is materially better than manual entry, and it is still wrong often enough that mission-critical fields belong in a review workflow before they fire downstream automation. For more on building review into IAM, see our writeup on why IAM implementations struggle - extraction confidence is one of the recurring failure modes.

How do you read Iris-extracted data programmatically?

The entry point is the Agreement Manager (Navigator) API. The two endpoints you will use 90% of the time:

The list endpoint paginates across the account's agreements; the get endpoint returns the full provision payload shown earlier. From there, the common production patterns are:

• Periodic reconciliation. Poll the list endpoint nightly, diff against your CRM, and write changes back.
• Event-driven sync. Trigger downstream work when an agreement is signed and Iris finishes extraction. This is where a webhook relay matters - Docusign Connect will fire envelope events, but most teams need to land that event reliably in HubSpot, Salesforce, or a queue. For the production-grade version of that pattern, see Baton, our webhook relay between source platforms and Docusign Workflow Builder.
• Agent-driven retrieval. Expose the Navigator API to Claude or another agent so it can answer questions like "which agreements expire in the next 60 days with auto-renew enabled?" If you are wiring agents to Docusign, our MCP integration guide covers the recommended shape.

What about the new Iris assistant and agents?

At its Momentum conference, Docusign introduced Iris-powered AI agents and an assistant that review contracts, flag risks, track obligations, and trigger actions using natural language. The March 2026 release notes describe AI-Assisted Review being reshaped into an Iris-powered assistant that can suggest redlines or insert new clauses even without an established playbook.

The technical point worth keeping in mind: agents and the assistant sit on top of the same extraction layer. When an Iris agent answers "what's the indemnity cap on the Acme MSA?", it is reading the same provisions the API exposes, then layering reasoning and citation on top. If the extraction is wrong, the agent is wrong - with more confidence. That is why investment in extraction quality (custom fields, training examples, the review queue) compounds into agent quality.

For a longer comparison of the Iris stack versus custom-built Claude agents on the same agreement data, see our Iris vs custom Claude agents writeup.

FAQ

What models does Docusign Iris use? Docusign describes Iris as a flexible model infrastructure that uses the latest LLMs tailored for agreements, plus proprietary multilingual models for non-English contracts. The specific model on any single extraction is an internal routing decision and not exposed to customers.

Can Iris extract custom clauses my industry cares about? Yes. Custom extractions are trained by uploading a few example contracts and highlighting the target language, so Iris recognizes the same field on future agreements without writing regex or rules.

Does Iris support languages other than English? Yes. Docusign confirms multilingual AI models deployed globally with region-specific data residency for extracted data.

How do I get the extracted data into my CRM? Use the Navigator API for read access and Docusign Connect for events. For production reliability between Docusign and source platforms, route the webhook layer through a relay like Baton rather than wiring point-to-point.

Should I trust Iris extractions without review? No. Treat them as a strong first pass. Docusign ships a Data Review experience for exactly this reason - high-stakes fields (financial values, expiration dates, governing law) belong in a verification queue before downstream automation depends on them.

The take

Iris is the part of Docusign IAM that turns a PDF into a row in a database, and it is good enough at that job to be the spine of every downstream agent and workflow story Docusign is telling in 2026. The real engineering work is upstream and downstream of Iris: clean classification, well-chosen custom extractions, and a review queue for the fields you cannot afford to be wrong about.

If you are evaluating Iris for a real portfolio - especially historical contract migration or agent-grounded workflows - book a working session with the fluidlabs team. We have shipped this end-to-end and will tell you exactly which fields to trust and which to gate behind review.