Iris AI vs custom Claude agents on Docusign

04 Jun 2026

9 min

AI Agents

Docusign IAM

MCP

Agreement Mgr

Every Docusign IAM customer eventually asks the same question: do we use the AI that ships in the box, or do we wire Claude into our Docusign tenant ourselves? Docusign markets Iris as the answer for agreement intelligence. Anthropic and Docusign have, separately, shipped an MCP connector that lets you point a custom Claude agent at the same APIs.

These are not the same product. They solve overlapping problems with very different operating models. Here is how we think about the trade after building both for clients.

What Iris AI actually is (and isn't)

Iris is the AI engine that powers the smart features inside Docusign IAM. Per Docusign, Iris is part of the IAM platform and AI features are included in select IAM, CLM, and eSignature plans. It is not a separate SKU you buy or call from outside Docusign. You get it when you buy IAM Standard, Professional, Enterprise, or for Sales, subject to plan allowances (Docusign IAM plan allowances document the Agreement Manager agreement caps per user per year).

Concretely, Iris does four things well today:

Structured extraction. It reads incoming agreements and pulls provisions like parties, effective and termination dates, financial terms, renewal conditions, and governing law into typed fields on the Agreement Manager record. You can configure custom extraction fields per agreement type in Agreement Manager's AI Extraction settings.
Search and Q&A over your repository. Agreement Manager indexes both full text and the Iris-extracted provisions, so you can ask "show me MSAs governed by California law expiring in Q2" and get back hits without writing SQL.
Summarization and review. Iris generates pre-signature summaries and risk callouts inside the signing experience.
Obligation tracking. Iris can track renewal, payment, and termination terms automatically and fire notifications.

What Iris is not: a general reasoning engine you can point at your own data. It runs inside Docusign, on Docusign-stored agreements, with the field schema Docusign exposes. You configure it; you do not program it.

For a deeper walkthrough of the Iris feature surface, see our Agreement Manager + Iris guide.

What a custom Claude + MCP agent can reach that Iris can't

A custom agent built with Claude and the Docusign MCP server (beta) inverts the model. Instead of Docusign's AI doing fixed jobs on Docusign data, you write the agent and let it reach into Docusign as one tool among many.

The MCP server, now in beta, wraps the IAM APIs as MCP tools: an agent can search envelopes, check status, retrieve agreement metadata from Agreement Manager, and trigger Workflow Builder runs. Our MCP integration guide covers the setup and current limitations (notably, Agreement Manager API operations are read-only at the time of writing).

What you gain over Iris:

Multi-system reasoning. Claude can fetch the agreement from Docusign, the related opportunity from Salesforce, the customer's support tickets from Zendesk, and synthesize a single answer. Iris cannot leave Docusign.
Custom logic. You decide what "high risk" means. You decide what counts as an unusual indemnity. You decide which clauses get flagged to legal and which auto-route. Iris's reasoning is a black box you tune through configuration, not code.
Drafting and negotiation assistance grounded in your own corpus. Plug Claude into your playbook documents, fallback positions, and prior redlines and you get draft suggestions that follow your house style. Iris's drafting features are general-purpose.
Custom UX. Slack bot, internal tool, voice agent, whatever your users live in. Iris lives in the Docusign UI.

Side-by-side: where each one wins

Capability	Iris (in IAM)	Claude + MCP custom agent
Provision extraction (standard fields)	Native, batch + on-ingest	Possible but you reinvent it
Custom extraction fields	Configurable in Agreement Manager	Fully programmable
Search across all your agreements	Native, indexed	Possible via Agreement Manager API, slower
Cross-system reasoning (CRM + Docusign + ticketing)	Not possible	Core strength
Pre-signature summary inside the signer flow	Native	Not where Claude lives
Custom risk policy / playbook enforcement	Limited to configured fields	Programmable
Triggering downstream workflows	Via Workflow Builder, configured	Via MCP, programmatic
Time to first value	Hours	Weeks

The shape of the trade: Iris wins on anything that is "do this standard agreement job, on agreements already in Docusign, inside Docusign's UI." A custom agent wins on anything that is "reason across systems, apply our specific policy, and surface the answer wherever our users actually work."

Governance and audit trail

This is where the comparison gets less obvious and more important.

Iris runs inside Docusign's compliance perimeter. The data never leaves the tenant for inference, the AI Data Controls are managed by Docusign admins, and every extraction is attached to the agreement record with provenance. For regulated industries, this is the easy answer.

A custom Claude agent involves data leaving Docusign's perimeter and entering Anthropic's. That is fine for most enterprises (Anthropic offers enterprise contracts and zero-retention options), but it is a compliance review, not a config flag. You also have to build:

Per-user auth so the agent acts as the human, not as a service account that can see everything
Audit logging of every prompt and tool call, persisted somewhere your auditors can reach
A retention story for prompts and responses
Approval gates before destructive actions like sending an envelope or moving a Workflow Builder run forward

If you are tempted to skip those, use Iris.

Cost: bundled vs per-token

Iris is bundled. The cost surface is your IAM plan allowances: agreements processed per user per year and automation sends per user per year, both documented on the IAM plan allowances page. You do not pay per extraction or per summary.

A custom Claude agent is metered the other way. Every conversation costs tokens. A 30-page MSA pulled into context for a single review is real money at Anthropic's rates, and a chatty agent that re-reads the same agreement on every turn will surprise you on the invoice. Cost engineering for production agents is its own discipline: caching, retrieval-augmented patterns, smaller models for routing, and aggressive context trimming.

The honest version: for "extract the renewal date from every contract we sign," Iris is dramatically cheaper. For "review this one strategic deal end to end against our playbook with citations," a Claude agent earns its tokens.

The hybrid pattern most teams should actually run

After enough implementations, the pattern that wins is not "pick one." It is layered:

Iris does the structured work. Standard extractions, Agreement Manager indexing, provision-level search, obligation reminders. This is the system of record.
Claude does the bespoke reasoning, on top of Iris. When a user asks a hard question, the Claude agent calls the MCP server, pulls the Iris-extracted fields and the agreement text, optionally fetches related context from CRM or ticketing, and reasons. It does not re-extract what Iris already extracted.
Workflow Builder is the action layer. When Claude decides "this needs legal review," it triggers a Workflow Builder run via MCP. The workflow is the audit-clean record of what happened. See our Workflow Builder guide for the orchestration patterns we use.
Source-system triggers stay out of the agent. If the trigger is "deal closed in HubSpot, kick off the agreement workflow," that is a webhook job, not an agent job. We use Baton for the relay because the failure modes (HMAC verification, retries, idempotency) are unforgiving and you do not want a probabilistic system in that path.

A sketched Claude prompt for the reasoning step:

text

You are reviewing an inbound MSA. Use the docusign tools to:
Get the Agreement Manager record for envelope_id={{id}}
Pull the extracted provisions (term, governing_law, indemnity_cap, auto_renewal)
Compare each against our playbook (attached as a resource)
For any deviation > 10% from playbook, draft a redline note
Return a summary with citations to the agreement clauses

Do not send envelopes. Do not advance workflow steps. Output only.

Two things to notice. First, Claude is consuming Iris output, not redoing it. Second, the agent is read-only by policy; any mutation goes through a human-confirmed Workflow Builder step.

Decision guide by use case

Quick rules of thumb we give clients:

"Find all contracts with X clause." Iris and Agreement Manager search. Don't build an agent.
"Summarize this contract before I sign." Iris, in the signing experience.
"Track all renewals and notify owners 90 days out." Iris obligations.
"Draft a response email that references the customer's last three agreements and the open support tickets." Custom Claude agent.
"Auto-classify inbound vendor paper against our 14-page playbook." Custom Claude agent, with Iris doing the field extraction underneath.
"Trigger the agreement workflow when the opp closes in Salesforce." Webhook relay (Baton), then Workflow Builder. No agent in the path.
"Answer 'are we exposed under any agreement to vendor X?' across CRM and Docusign in one shot." Custom Claude agent. Iris cannot leave Docusign.

How to choose

If you are still in implementation, get Iris working first. It is the cheapest, fastest, most-governed path to the 80% case, and it sets up the data layer (clean Agreement Manager records, sane custom fields) that any future agent will need anyway. Building a custom Claude agent on a messy Agreement Manager is a bad time.

Once Iris is steady, the question becomes: what specific decisions do our users make today by hand because Iris cannot reason across systems or apply our policy? Those are the agent use cases. Build narrowly, log everything, keep mutations behind Workflow Builder, and you get the upside without the risk.

We have written the corresponding playbooks for each layer: the MCP integration guide for the agent layer, the Agreement Manager + Iris guide for the AI-in-the-box layer, and the Workflow Builder guide for the orchestration that ties them together.