AI Agents in Insurance: Where Human Approval Still Counts
Verdocs Team
On September 22, 2026, BriteCore introduced new AI copilots, an underwriting workbench, and an Open Agentic Core: an MCP (Model Context Protocol) server layer that lets AI agents "securely interact with the platform using standardized protocols while honoring each user's existing role-based permissions." Its CEO put the shift directly: AI "is rapidly evolving from simply generating content to becoming an active participant in core insurance operations."
BriteCore is not alone. Duck Creek, Guidewire, and Majesco have all announced agents that read policy, claims, and billing data and, increasingly, act inside the system of record. The capability question is being answered quickly. The harder question for insurers and the platforms that serve them is this: as agents gain the ability to act, how does their work become a completed, authorized, and well-documented transaction?
What the four platforms have announced
Vendors use "introduced," "launched," and "available" loosely. The summary below records what each release says, not what the headline implies. All capability and performance claims are the vendors' own.
| Vendor | What was announced | Main workflows | Availability stated in the release |
|---|---|---|---|
| BriteCore (Sept 22, 2026) | FNOL Copilot, Submission & Quote Copilot, action recommendations in Claims and Policy Copilots, Underwriting Workbench, Open Agentic Core with MCP layer, Claude Cowork plugin | Claims intake, submission to quote, underwriting | Only the Claude Cowork plugin is described as "recently released." No availability date for the rest; the CEO describes the agentic core as "our vision." |
| Duck Creek (Apr 28, 2026) | Agentic AI Platform with orchestration, governance ("AI Assurance"), and an MCP and A2A gateway; Agentic Underwriting Workbench; Agentic FNOL built with Google Cloud and Gemini | Submission intake and triage, claims intake | Platform "launched"; the two applications are "introduced" without a stated availability status. |
| Guidewire (Aug 3, 2026) | Qusar release: Agentic Framework, Agentic FNOL by conversational voice, Claim Summarization and Policy Change for its ProNavigator assistant | Claims intake, claims handling, policy change | Agentic FNOL and Claim Summarization are marked Restricted Availability; Policy Change is marked Early Access. |
| Majesco (Apr 7, 2026) | Spring '26 release: agentic automation "across quoting, servicing, billing, and claims"; new agents for bill validation, payment reconciliation, and claim reopening | Quoting, servicing, billing, claims | "Available now" through standard upgrades, following 13 agents in its Fall '25 release. |
Two patterns stand out. Every vendor starts with the same two workflows, underwriting submission intake and first notice of loss, because both are document-heavy, high-volume, and early enough in the process that mistakes are cheap to catch. And every vendor now pairs its agents with a governance story: permissions, traceability, human-in-the-loop controls. BriteCore's copilots "enable employees to approve and execute recommended actions." The vendors are drawing a line between what an agent does and what a person decides.
Assist, recommend, execute
"Agent" covers three different levels of autonomy, and each needs different controls.
A copilot assists an employee. It summarizes a claim file or surfaces the issues an underwriter should check first. The employee remains the actor, and the control problem is accuracy.
A recommending agent proposes a specific action: quote this submission at these terms, fast-track this claim, refer this endorsement. BriteCore says its Submission & Quote Copilot "assembles coverages, applies rating, and transforms unstructured submissions into a quotable policy." A person still decides, so the record has to show who decided and what they saw.
An executing agent performs the action. BriteCore's FNOL Copilot "creates the claim record in real time." Its Claude Cowork plugin allows "permission-gated write capabilities" so agents can "execute approved core insurance operations." Here the agent is performing an action in the transaction, and the insurer must be able to show what it did, under whose authority, and within what limits.
None of these announcements describes an agent binding coverage, paying a claim, or issuing a policy to a customer with no human or customer involvement. That reflects how insurance transactions work, not a lack of ambition.
Where human action enters
Most agent activity does not need a signature. Pulling a loss run, validating coverage, drafting a claim summary, or updating a mailing address can be logged and moved on. The question is which steps call for something only a person can provide, and that depends on the transaction, the line of business, the jurisdiction, and the insurer's own authority rules.
Three kinds of human action recur.
Internal approval. An underwriter binds within a letter of authority; an adjuster settles within payment limits. When an agent acts on a person's behalf, it borrows that person's authority, which is why vendors emphasize role-based permissions. For decisions above routine thresholds, the record should show that a named person reviewed and approved.
Customer or counterparty participation. Some steps require the policyholder, claimant, or producer to acknowledge, consent, or sign. Under the US E-SIGN Act, an electronic signature is one "executed or adopted by a person with the intent to sign the record" (15 U.S.C. § 7006). An agent can prepare an application, a settlement release, or an appointment agreement. Where applicable requirements call for the other party's signature, the agent cannot supply it. Similarly, before delivering required disclosures electronically to consumers, E-SIGN requires the consumer's affirmative consent and, where the provision applies, consent given electronically in a way that shows the consumer can access the records (15 U.S.C. § 7001(c)). An agent can present that disclosure; the consumer has to give the consent.
Identity assurance. When the stakes justify it, the person approving or signing must be identified with a strength proportionate to the risk. NIST's SP 800-63-4 Digital Identity Guidelines provide a common vocabulary for choosing that level.
What the handoff has to preserve
The vendors' governance layers address the agent's side of the record: what it accessed, what it proposed, what it did. When a workflow calls for review, consent, or signature, a second requirement appears. The handoff from agent to person must preserve three things together: what the agent prepared, what the person saw and did, and the resulting record.
That is harder than it sounds. If a person approves a summary in one system while the document they are approving lives in another, the record cannot prove they saw the final terms. If an agent sends a request and never learns that the signer declined, the transaction looks complete when it is not. If the signed document, the approver's decision, and the agent's log sit in three places, reconstructing a single transaction for a market-conduct exam or a dispute becomes a project.
Where Verdocs could fit
This is the gap a document and eSignature workflow layer is built to close. Verdocs provides embedded, white-label eSignature and document workflow through APIs, webhooks, and native components, so a platform can keep review and signing inside its own product. The examples below describe how an insurer or insurtech could connect agent-driven work to that kind of layer. They are illustrations, not existing integrations.
A signed application after agent-assisted underwriting. A recommending agent finishes submission intake and an underwriter approves the quote. The platform then calls the eSignature API to generate the application and supplemental forms from a template, pre-filled with the values the agent extracted. The applicant and producer review and sign inside the portal they already use, under the carrier's or platform's brand. The signed documents and certificate of completion return to the policy record through a webhook, and issuance proceeds only when they arrive. The record now shows three separate, attributable events: the agent's preparation, the underwriter's approval, and the applicant's signature.
A signed release before an agent-prepared settlement is paid. A claims agent calculates a settlement within the adjuster's authority and drafts the release. The adjuster approves it. The release goes to the claimant with identity verification set by the insurer's rules for that amount, such as knowledge-based authentication. Payment waits until the signed release is on file with its audit trail. If the claimant declines or the request expires, a webhook notifies the claims system so the agent reopens the file rather than treating the settlement as done.
In both cases, the agent does the preparation it is good at, the person does what only they can do, and the record ties the two together. For platforms serving many carriers or agencies, the white-label model keeps each signing experience under the right brand.
The question to ask before granting write access
For product leaders evaluating these platforms, model quality is only part of the evaluation. The more important question is whether the transaction holds together: which actions an agent can execute alone, where a person must review, consent, or sign, and whether the insurer can later produce what the agent prepared, what the person saw, and what they did, in one place.
Agents will keep getting better at doing the work. Making that work stand up as a completed insurance transaction still depends on the handoffs to people and on the records those handoffs create.
To see how embedded review and signing could fit an agent-driven workflow in your platform, visit the Verdocs insurance overview or book a demo.
