When AI Prepares the Agreement, Who Makes the Commitment?

Designing human approval and signing into AI agent workflows

Consider a hypothetical claims platform with an AI assistant built in. An adjuster finishes a call with a claimant and asks the assistant to prepare the release for the agreed settlement. The assistant selects the carrier's release template, fills in the claim number and amount, and queues the document for the claimant.

Several decisions are hiding in that one step: whether the amount is within the adjuster's authority, whether the document is ready to go out, whether it will reach the right claimant, and whether the claimant accepts it.

The design question is which acts the agent should perform, which it should only prepare, and how the system makes sure the right person takes the step that creates a commitment.

Five acts that are easy to blur

Agreement workflows contain distinct acts that often get run together:

Act	What it means	Who typically does it in our example
Prepare	Assemble a document from an approved template and data	The agent
Approve release	Decide the document may go out with these terms	The adjuster, within the carrier's authority limits
Send	Deliver the document to the recipient	The system, after approval
Verify the recipient	Confirm the person signing is who they claim to be	The signing service, using the checks the carrier requires
Sign	Adopt a signature on this document, with intent to sign	The claimant

The insurer authorizes the settlement through its adjuster. The claimant accepts it by signing. An agent helping the insurer has no role in the claimant's decision beyond presenting the document clearly.

Access is not authority

Four different things are easy to conflate:

• Technical permission is what a credential, such as an API key or OAuth grant, can do in a system.
• Identity is who a person is. A one-time code shows that someone can access an email address or phone number. Identity proofing goes further: it establishes that a claimed identity is real and belongs to the person presenting it. NIST's identity guidelines treat these as different functions.
• Authority is whether someone may bind a person or company to terms. It comes from the person or organization being bound.
• Intent to sign is a person's decision to adopt a signature on a specific record.

None of these implies another. An API key does not show an adjuster may settle a claim. A passed identity check does not show the claimant agreed to anything.

US law does allow software to take part in forming agreements: the E-SIGN Act says a contract may not be denied legal effect solely because electronic agents were involved, as long as their action is legally attributable to the person to be bound (15 U.S.C. § 7001(h)). It also defines an electronic signature as one executed or adopted by a person with intent to sign (§ 7006). Whether a particular automated action binds someone depends on the facts.

For the settlement-release workflow described here, we recommend a clear handoff: the agent prepares and routes the document, and the claimant reviews and signs through an embedded signing experience. That recommendation is about clarity and evidence, not a claim about what the law requires in every case.

Put the controls on the server, not in the prompt

"Always ask the adjuster before sending" is useful guidance for a model, not a control. Prompts can be misread or bypassed, and text inside a document can try to steer the agent.

Rules that matter belong in the systems the agent calls, enforced the same way for every caller. The controls below are a recommended architecture. They should be enforced by the platform's backend, the signing provider, or both, and teams should establish which system owns each control before implementation.

• Approved templates. Agents work from templates the organization has approved, so the terms come from the business, not the model.
• Values the agent may supply. The platform defines which fields an agent is allowed to fill, and validates the values, such as checking the amount against the adjuster's authority, before anything is sent.
• Values the signer may change. Separately, fields with approved values should be read-only for the signer. Verdocs templates support read-only fields today.
• Recipient rules. The system, not the model, decides who may receive a given document type, for example by taking the claimant's contact details from the claim record rather than from the agent's output. That makes a typo or injected instruction far less likely to redirect a release.
• Tenant isolation. Every request should act for one tenant, using credentials scoped to it, so an agent working for one carrier is restricted to that carrier's documents.
• Review before consequential actions. Sending a document, especially one that commits money, should require an approval tied to the exact version being sent. If the document changes, the approval no longer applies.
• Safe retries. Agents retry. A repeated request should return the existing document rather than send a second one, and event handlers should tolerate duplicate deliveries.

Why tie approval to the exact version? Suppose the adjuster approves a $12,000 release, then the claimant sends a corrected repair invoice and the agent updates the amount to $13,500. The earlier approval covered a different document, so it shouldn't authorize sending this one. Any change after approval should require a new approval.

The handoff should feel like your product

Once the adjuster approves, embedded signing lets the claimant review and sign inside the carrier's portal or app, under the carrier's brand, instead of in an unfamiliar vendor window.

The signing experience should support a deliberate decision. The claimant sees the full release, not a summary. Any required identity check runs before signing. Verdocs lets the carrier choose checks per recipient, including one-time codes, knowledge-based authentication, and ID verification. Which to use depends on the carrier's risk policy and the rules that apply; not every method meets every standard. NIST's SP 800-63A, for example, excludes knowledge-based methods from identity verification under its requirements. The signing action is clearly labeled. A casual chat acknowledgment should not automatically be treated as authorization to sign a particular document.

What the record should help establish

If a release is questioned later, the record should help answer:

• Which document version was presented and signed.
• Which approvals came before sending, and who gave them.
• Which identity checks the signer completed.
• What signing action the signer took, and when.
• What role the agent played, such as preparing the document or initiating the send.

Verdocs' audit trail and certificate of completion cover the signing side: the document, the recipient's verification, and the signing events. Recording the agent's role alongside them is an emerging practice; today, a platform can log its own approvals and agent actions next to the signing record.

The record supports conclusions but cannot prove the claimant read every clause or that the agreement is enforceable.

Resuming the workflow

A signature can take days, so events, not an agent's memory, should drive the next step:

• Signed: a completion event signals that the finalized documents are ready for retrieval. The claims system then applies the carrier's rules to the next step, such as releasing payment once other requirements are met.
• Declined: a decline event sends the file back to the adjuster.
• Expired or cancelled: the request ends. If terms change, the platform prepares a new document with a fresh approval.

Questions to answer before agents initiate agreements

1. Which documents may an agent prepare, and which templates are approved for each?
2. Which values may the agent supply, and which may the signer change?
3. Who must approve before anything is sent, and is that approval tied to the exact version?
4. Who may receive each document type, and how is that enforced?
5. Which identity checks does each recipient need?
6. What happens on retries, declines, expiration, or a change in terms?
7. Where is the agent's role recorded alongside the signing record?

For the integration side of this topic, see our companion post, Building an eSignature Integration With AI Coding Agents. If you're designing an agent-led agreement workflow and want to talk through the handoff, schedule a conversation with our team or start with the developer documentation.