AI Agents Can Automate the Workflow. Someone Still Has to Sign.

Agent platforms spent the last two years getting good at the middle of a business process. They retrieve records, reason over them, write back to the system of record, call other services, and coordinate a sequence across all of it. What most of them cannot do is the last step, because the last step is not theirs to take: at some point a person has to agree to something, and no amount of autonomy on the agent's side produces that agreement.

This is a smaller problem than "AI cannot be trusted" and a more interesting one. It is an architecture gap, and it is starting to get filled.

The agents got good at the middle

Look at what is being shipped rather than what is being predicted.

In customer experience, NiCE Cognigy describes agents operating in a governed model that senses, decides, and acts across systems, with human handover built in so a person can pick up a case without breaking the conversation. Inbenta markets its Encore platform on the same axis: agentic CX on a governed foundation, sold to enterprises whose risk and compliance teams have to sign off on it.

In financial services the claims are more operational. Saris says it orchestrates the lending lifecycle from document intake through origination, processing, underwriting, and closing. Covecta sells an orchestration layer of specialized agents sitting on top of a bank's existing stack rather than replacing it. Gradient Labs runs borrower conversations and the back-office case work behind them, and its product explicitly lets an institution require approval for sensitive decisions. Titan puts it plainly: its banking agents automate repeatable workflows across compliance, underwriting, risk, and operations while keeping humans in control of final decisions.

And on the developer side, platforms like Lyzr treat this as plumbing. An agent is assembled from tools, each tool is an API call, and the platform supplies the guardrails, the observability, and the approval chains around them.

None of these companies uses Verdocs, as far as we know, and none of them is a partner. They are cited here because they are the clearest public evidence of a trend: agents that complete operational work, in regulated industries, under governance. Read those product descriptions closely and one word keeps appearing at the edge of the automation. Approval. Handover. Human control. Closing.

That word is where the workflow stops.

Three layers, and the third one is thin

It is useful to separate what these systems actually consist of.

Reasoning and orchestration. The agent decides what should happen: which case this is, what the policy says, what step comes next. This layer is crowded and improving fast.

Enterprise tools. The agent acts on systems: the CRM, the core banking platform, the policy admin system, the payment rails, the database. This layer is mature, because it is mostly APIs that already existed.

Agreement execution. The workflow reaches a point where a human has to consent, authorize, or sign, and that consent has to be captured in a form that holds up later. This layer is thin, and it is the one most agent roadmaps skip.

The gap is not that agents cannot send documents. Sending a document is an API call, and it has been an API call for a decade. The gap is that most agent architectures have no designed answer for what happens at the moment human intent is required, so they improvise one: drop the case in a queue, email a link to a third-party portal, or hand the customer to a person who redoes work the agent already finished.

What it looks like when the layer exists

Take lending, because it is the example where every step is legible.

An agent works a loan file. It pulls the documents, spreads the financials, runs the checks, and gets the file to a decision. Underwriting clears. The file is ready to close.

Today, in most stacks, that is where a human picks it up. With an agreement-execution layer, the agent continues: it calls the signature API, which creates the envelope from a template the institution governs, with the terms already populated from the file. The borrower reviews and signs, authenticating at whatever level the document warrants. A webhook fires on completion. The agent resumes and moves the file to funding.

The agent automated four steps. The borrower made one decision. That division is the point, not a compromise.

The same shape appears everywhere once you look for it:

• A recruiting agent finishes an approval chain and an offer letter needs a candidate signature.
• A claims agent reaches a settlement and the claimant has to execute a release.
• A matter-intake agent prepares an engagement letter for a new client.
• A sales agent closes an opportunity and an order form has to be countersigned.
• A procurement agent clears a vendor and the vendor agreement has to be executed.
• A patient-onboarding agent reaches a consent form that a patient, not a system, has to accept.

The trigger differs. The structure does not: the agent knows what should happen, and a person has to agree before it can.

Does any of this need MCP?

The Model Context Protocol is having a real moment in agent tooling, and the eSignature category is now part of it. Docusign announced on September 4, 2026 that its MCP server reaches general availability on September 30, under the banner "Agreement Layer for the Agentic Enterprise," making agreement actions callable from Claude, ChatGPT, Gemini, Copilot, and Slack.

MCP is a genuinely useful standard, and a signing surface exposed through it is a good thing for the category. But it is worth being clear about what it is: a convention for describing tools to agents. It is not a prerequisite for an agent to do anything.

If an agent can call a payments API, a CRM API, or a messaging API, it can call an eSignature API. That is the whole argument. Every agent framework in production already supports authenticated HTTP calls with typed parameters, because that is how it talks to everything else. A signing action is not architecturally special. It is a POST that creates an envelope and a webhook that tells you when the human is done.

Where MCP helps is distribution and discovery: it makes a tool available in places you did not integrate with individually. Where it does not help is capability. An MCP server that wraps an API cannot do anything the API could not already do, and a team building a product integration will generally want the API anyway, for the error handling, the idempotency, and the control over what the agent is permitted to send.

Verdocs, for its part, publishes an MCP endpoint for its developer documentation today, so the assistant you code with can read the API reference while you build. A product MCP surface that exposes envelope operations as tools is on the roadmap and is not shipped. Neither fact changes what an agent can do with the REST API right now, which is everything described in this post.

What an agent log proves, and what it does not

Here is the part that tends to get missed, and it is the reason agreement execution is a distinct layer rather than a feature of the orchestration layer.

Agent platforms are already good at evidence. Gradient Labs markets timestamped audit trails of every decision, disclosure, and consent. Governance vendors sell runtime policy enforcement that blocks a prohibited action before it executes. Compliance layers verify that an action was permitted before the agent takes it. All of this is real, and in a regulated workflow it is necessary.

But it is all evidence about the system. It proves what the agent did, what policy it checked, and what it was authorized to do.

A signature is evidence about a person. Under the E-Sign Act and UETA, what carries legal weight is that a specific individual was identified, saw the terms, and intended to be bound by them, along with a record that can be reproduced later. An agent's execution log cannot supply that, no matter how detailed it is, because it is answering a different question. One says the process was followed. The other says this person agreed.

The practical consequence: a policy layer that confirms an action is permitted and a signature that records what the customer actually agreed to are complements, not substitutes. The first protects the institution from its own automation. The second is what you produce when someone disputes the transaction two years later.

Designing the checkpoint

None of this argues that every automated step needs a signature. Most do not, and a workflow that stops for consent it does not need is worse than one that does not stop at all. Whether a signature is required depends on the transaction, the law that governs it, the risk, the institution's own compliance rules, and the experience you want the customer to have.

Where the answer is yes, the checkpoint is worth designing rather than tolerating.

Put it where the decision actually is. The signature should sit at the point of real consequence, not scattered across every step that touches a document.

Match the assurance to the stakes. A renewal acknowledgment and a loan agreement do not need to prove the same thing. Identity assurance should scale with the transaction, from an emailed link up to knowledge-based authentication or an ID check.

Keep the authority on your side. The agent should choose when to send a governed template, not compose terms. The narrower the agent's authority over the document, the less there is to review later.

Do not make the customer leave to finish. If the whole interaction happened inside your product and the final step sends the customer to a vendor portal, the last thing they remember about the transaction is someone else's brand. This matters most in exactly the cases where the agent added the most value.

The framing worth holding onto: handing off to a human agent is an escalation and usually means something went wrong. Handing off to the customer for signature is a completion and means everything went right. Those are different events and they deserve different infrastructure.

Where this leaves platform teams

If you are building agents into a product your customers already use, the signature step is not an afterthought to bolt on at the end. It is the moment your automation converts into something enforceable, and it is the moment your brand is either present or replaced.

Verdocs already provides the pieces that step needs: a REST API that creates and sends envelopes, prefilled from your data; signing that renders inside your own application through web components rather than a redirect; white-labeling across the builder, the notifications, the signing screen, and the certificates; webhooks that resume your workflow the moment a recipient signs or declines; and audit trails and signing certificates that carry the evidence. None of that was built for agents. It works for them because it was built as infrastructure for software platforms, and an agent is just another caller.

Agents can automate the process. Something still has to execute the agreement.

If you are scoping where that checkpoint belongs in your workflow, the eSignature API for AI agents page walks through the call, the webhook, and the architecture choice, or start for free and send one.