Agents can gather the facts, check the systems, and decide what happens next. They cannot consent on a customer behalf. Verdocs is the signing step your agent calls when a workflow reaches a human decision that has to be legally meaningful, and it renders inside your product instead of sending your customer somewhere else.
An agent can retrieve records, reason over them, update the system of record, call an API, and coordinate a workflow across several of them. Then it reaches the step where a person has to sign, authorize, consent, or accept, and the automation runs out of road. Three things tend to happen, and none of them is good.
The agent has everything it needs and no way to finish. The case sits in a queue waiting for a human to do by hand what the agent already assembled.
The agent sends the signer to a third-party portal under a vendor brand. At the highest-stakes moment in the journey, your product disappears and someone else takes over.
An agent log proves what the system did. It does not prove that a named person read the terms and meant to be bound by them. Those are different artifacts.
The third one is the one teams notice last. Agent platforms already keep careful records of what the agent did and why. That is evidence about the system. A signature is evidence about a person: who they were, what they saw, and that they intended to be bound by it. An execution log cannot stand in for it.
Five steps. The agent automates four of them, and the fourth one is deliberately left to a human.
Underwriting clears, the payment plan is agreed, the offer is approved. The workflow arrives at a point where a person has to consent, authorize, or sign.
One API call creates the envelope from a template you govern, with fields already populated from what the agent gathered. The agent chooses the document; it does not draft the terms.
Web components, not iframes: override any control, style with standard CSS. The signer stays in the interface the agent has been running in, under your brand, on your domain.
The one step that is not automated. The signer sees what they are agreeing to, and the audit trail records their identity, their consent, and their intent.
The moment the envelope completes, an event fires. The agent picks the workflow back up and funds the loan, provisions the account, or files the signed PDF where it belongs.
If your framework can expose a CRM write or a payments call as a tool, it can expose signing. The agent gets a typed action and an event to resume on. What it does not get is authority over the terms: the template is yours, the fields are yours, and the signer is the one who decides.
// A signing action, defined like any other agent tool
{
name: 'execute_agreement',
description: 'Send an agreement for signature. Returns an envelope id.',
parameters: { template_id, signer_email, fields },
async run({ template_id, signer_email, fields }) {
const envelope = await verdocs.envelopes.create({
template_id,
recipients: [{ role: 'signer', email: signer_email }],
fields, // prefilled from what the agent gathered
})
return { envelope_id: envelope.id, status: 'sent' }
},
}
// The workflow resumes on the event, not on a polling loop
app.post('/webhooks/verdocs', ({ body }) => {
if (body.event === 'envelope.completed') agent.resume(body.envelope_id)
})MIT-licensed SDKs on GitHub and npm, and the same three calls in React, with the component API: embed signing in a React app.
No. MCP is one way to hand a tool to an agent. An authenticated HTTP call is another, and it is the one every framework already supports. Verdocs is a REST API with SDKs and webhooks, so a signing action sits in your tool catalog beside the CRM actions, the payment calls, and the database queries, with the same auth model and the same error handling as the rest of them.
What Verdocs publishes as MCP today is its documentation, so the assistant you code with can read the API reference while you build the integration. That is a help for the developer, not a channel for the agent. A product MCP surface is on the roadmap and is not shipped, and nothing on this page depends on it.
The agent platforms reaching this problem look nothing alike. They arrive at the same place.
Agents that resolve customer requests end to end, in chat or voice, across banking, insurance, telecom, and utilities.
Where it stops
Resolution requires consent. A servicing change, a waiver, a settlement acknowledgment, or a disclosure the customer has to accept before anything moves.
Why it matters
These agents are judged on containment. Sending the customer to an external portal to finish is the same abandonment risk as transferring them to a queue.
Agents running origination, underwriting, servicing, collections, and onboarding inside banks, credit unions, and lending platforms.
Where it stops
The file is ready to close. A loan agreement, a payment-plan arrangement, an account authorization, or a KYC disclosure needs a borrower signature.
Why it matters
The document is the regulated artifact. Assurance has to match the transaction, and the evidence has to survive an examination years later.
Frameworks and orchestration platforms where teams assemble agents from tools, with guardrails, approvals, and observability around them.
Where it stops
A builder needs a signing action in the tool catalog, next to the CRM writes, the payment calls, and the messaging steps.
Why it matters
The action has to behave like every other tool: an authenticated call, a typed response, an event to resume on. No special protocol, no bespoke integration.
The trigger is different in every industry. The shape is identical: the agent knows what should happen, and a person has to agree to it before it can.
| Industry | What the agent finishes | What has to be signed |
|---|---|---|
| Financial services | Underwriting clears, or a payment plan is agreed | Loan agreement, payment arrangement, account authorization |
| Insurance | An application completes, or a claim is settled | Application packet, settlement release, endorsement, policy change |
| Healthcare | A patient is onboarded, or care is authorized | Consent form, authorization, provider enrollment packet |
| HR and workforce | A candidate is approved, or a policy is updated | Offer letter, employment packet, contractor agreement, acknowledgment |
| Legal | Intake completes, or a matter opens | NDA, engagement letter, attestation, final agreement |
| Sales and CRM | An opportunity closes, or a renewal comes due | Order form, renewal, amendment |
| Procurement | A vendor clears review | Vendor agreement, statement of work, risk acknowledgment |
| Real estate | A unit is approved, or an offer is accepted | Lease, disclosure packet, management authorization |
Verdocs is built for the platforms these workflows run on: insurance, financial services, accounting, and six more.
A signature is usually described as the thing slowing the agent down. It is more useful to read it as the one place in an automated workflow where a human is shown exactly what is about to happen and gets to say yes or no. Autonomy does not remove accountability, and the more of a process an agent completes on its own, the more the remaining human decision has to be real, visible, and recorded.
Handing off to a human agent is an escalation, and it usually means something went wrong. Handing off to the customer for signature is a completion, and it means everything went right. Verdocs is the second kind of handoff: the agent automates everything around the decision and leaves the decision itself with the person whose name goes on the document.
Not every automated step needs a signature. Whether one is required depends on the transaction, the governing law, your risk position, and your own compliance rules. Where the answer is yes, the assurance should match the stakes: a renewal acknowledgment and a loan agreement do not need to prove the same thing.
Set per document type and per recipient. What knowledge-based authentication is, and where it stops being enough.
Most ways of adding signing to an agent end the same way: the customer receives an email from a vendor they did not choose and signs on a page that belongs to someone else. For an internal workflow, that is fine. For a customer-facing agent built by a software platform, it undoes the thing the agent was built to do. You spent the whole interaction earning trust in your product, and the last step gives it away.
Verdocs renders signing inside your application, on your domain, in your styles, and white-labels the whole lifecycle around it: the template builder your users work in, the notification emails from your sender, the signing screen, and the certificates and audit trails that prove it. If you serve many customers, each of them gets their own brand on their own documents, and neither you nor Verdocs has to appear.
The architecture question in full, including when a redirect is the right answer: standalone, integrated, or embedded signing. What white-label covers end to end: white-label eSignature.
Yes. An agent sends a document for signature the same way any other service does: an authenticated API call that creates an envelope, assigns a signer, and returns an id to track. The agent decides when a signature is needed and which governed template to use. The human decides whether to sign.
No. Verdocs is a REST API with SDKs and webhooks, so any agent framework that can call an HTTP endpoint can expose signing as a tool. Verdocs publishes an MCP endpoint today for its developer documentation, which lets a coding assistant read the API reference while you build the integration. That is a documentation surface, not a signing surface, and it is not required to send an envelope.
Verdocs captures a signature from the person it is addressed to, after they authenticate. The agent prepares and routes the agreement; it does not sign it. Whether any given transaction can be executed by an automated system instead of a person depends on the law that governs it, the risk, and your own compliance position, and that is a question for your counsel rather than a product setting.
A webhook. The moment a recipient opens, signs, or declines, Verdocs fires an event to your endpoint, so the workflow resumes on the event rather than on a polling loop. The signed PDF, the signing certificate, and the audit trail come back through the API.
No, and this is the part that usually decides the architecture. Web components, not iframes: override any control, style with standard CSS, so signing renders inside the application the agent is already running in, on your domain, under your brand. There is no redirect to a vendor portal and no vendor logo in front of your customer.
Set it per document type and per recipient, from an emailed link up to knowledge-based authentication and live ID scans. Every step a signer clears is recorded in the same audit trail as the signature, so the evidence reflects the assurance actually applied.
More questions? The full FAQ lives in the developer docs, from API auth and webhooks to eIDAS signature levels.
SOC 2 Type I · HIPAA compliant · ESIGN & UETA · eIDAS SES / AES · GDPR. Legally valid in 50+ countries and 60+ jurisdictions. Live in 1-2 business days.
Give your agents a signing action, or talk through where the checkpoint belongs in your workflow. If you want the argument rather than the product, read why agreement execution is becoming its own layer.