A faster settlement can still leave the customer with the problem
A claim can look finished in your system while the homeowner is still trying to find someone to repair the house.
ASIC's 31 August 2026 review makes that problem concrete. It found that more than half of the cash settlement offers in its Cyclone Jasper review were based on one quote. A preferred supplier's price may also differ from what a homeowner can obtain when arranging the work themselves. ASIC called for realistic repair costs and clearer explanations of what an offer means for the customer. ASIC's cash settlement findings.
That raises a better question for an insurance AI programme: can your team see enough of the claim to make the next decision well, and then carry it through?
The information might already exist. The latest builder's estimate is in a supplier portal. The relevant policy wording is in another system. A claims consultant recorded a concern during a phone call. An earlier offer sits in correspondence. Getting those pieces together is work someone has to do before the customer gets a useful answer.
Start with a settlement evidence workflow
Consider an illustrative home building claim following a severe storm. The insurer has a repair estimate, a partial cash offer, and a customer asking why the amount has changed.
The agent's job is to prepare the case for review and complete the authorised follow-through. Give it a defined set of records and actions, with a result the claims team can inspect.
| Stage | Work the agent prepares or performs | What the reviewer receives |
|---|---|---|
| Establish the case | Match the claim, insured property, and relevant policy version | A traceable link between the claim and its governing documents |
| Compare repair evidence | Read the current estimate and earlier versions; identify changed scope, quantities, and exclusions | A short explanation of what changed, with links to the original evidence |
| Reconcile the offer | Compare the proposed offer with the repair evidence and recorded reasons | The differences that need a claims decision, including any unexplained adjustment |
| Prepare the next contact | Assemble the customer's question, prior responses, and agreed contact method | A draft explanation and a focused list of genuinely missing information |
| Carry out the approved action | Update the claim, assign the next task, and record the authorised communication | Confirmation of what changed, where it changed, and who owns the remaining work |
An unresolved difference stays visible. If two documents describe different repair scopes, the agent should put that conflict in front of the reviewer. Averaging the numbers or selecting the most recent file would conceal the decision your team still needs to make.
The same discipline applies after approval. A task created in the claims system may also need an assignment in the repair network's portal. Treat those as separate actions and verify both. Otherwise the customer can receive a reassuring message about work that nobody has actually been assigned to do.
Australian detail changes the workflow
The local context belongs in the work itself.
ASIC's review included Cyclone Jasper claims from Far North Queensland. Its more detailed findings also describe gaps in recording and sharing relevant customer support information across the people involved in a claim. ASIC's review of cash settlement practices.
For a regional property, design the review to surface whether the proposed repair arrangement is actually available to that customer. A supplier entry in a database is insufficient if nobody has confirmed the work they will undertake, its location, and the basis of the quote.
Keep the relevant contact preference alongside the task. If the customer has asked to speak with someone, an automated portal update should not silently become the whole communication plan. Share only the support information the receiving team needs and is permitted to use.
These are practical design choices. The agent helps preserve context across hand-offs so that the next person can act on it.
The US version needs its own policy and claims context
The underlying coordination problem also applies to US property claims. The National Association of Insurance Commissioners' post-disaster guide describes a process involving adjusters, contractor estimates, policy coverage, and several types of payment. It explains that differences between estimates may need to be reconciled against the detailed repair scope. NAIC Post-Disaster Claims Guide.
A US implementation should use its own policy forms, applicable state requirements, and insurer procedures. Terms such as additional living expenses, deductibles, and replacement cost need to retain their meaning in that claim. An Australian cash-settlement workflow is not a ready-made US decision policy.
The reusable part is the ability to reach the right records, show how evidence relates, and execute the actions your team approves. Keep the local interpretation explicit while reusing the application access and workflow structure where appropriate.
Make the existing systems usable by agents
A claims assistant can summarise the documents you upload. A cross-system agent workflow also needs to find the right documents, understand the records around them, and complete work in the systems your business runs.
That becomes difficult when a supplier portal has no useful API, a claims platform is heavily customised, or the operation you need sits outside an existing connector. The team ends up carrying context between applications by hand.
Monarch discovers how connected applications work and makes verified operations available to agents. It provides an orchestration layer for complex workflows across those systems, including legacy and internally built software. Coverage follows the connected account's permissions and what discovery captures and verifies. The application map is what lets a workflow use the actual business application instead of relying only on a generic description of it.
For this pilot, the useful demonstration is a complete path: reach the claim, assemble its evidence, present the unresolved decision, then carry the approved action into the destination systems. Test the path again after an application change to establish that it still works.
Once that path is proven, the team can reuse the discovered operations for adjacent work such as repair progress enquiries or missing-estimate follow-up. Each new workflow still needs its own purpose, authority, and acceptance criteria.
Measure the next completed action
Start with a representative set of historical claims the team is authorised to use. Include straightforward cases alongside changed estimates, missing records, and conflicting descriptions of damage. Establish what a competent reviewer would need before progressing each one.
Then run a limited live pilot with a claims owner responsible for the result. Measure:
- The share of cases where the reviewer has the necessary evidence on first review.
- Corrections to document matching, repair scope, or the explanation of an offer.
- Repeat requests for information the business already holds.
- Time from review to the next verified action in the operational system.
- Cases that need further support or remain unresolved after that action.
The goal is useful progress for the claim and the person waiting on it. A shorter internal handling time is valuable when it produces that progress. Keep enough case-level detail to see when it doesn't.
Bring one claims workflow and the systems it crosses to a Monarch workflow discussion. Start by showing what the team needs to know and do before the next customer conversation.
Frequently asked questions
What is a practical first use of AI agents in insurance claims?
Preparing a settlement or repair review is a useful starting point. The workflow joins policy records, estimates and claim history, highlights differences and prepares the next authorised action. It produces a result a claims professional can inspect before expanding its authority.
Should an AI agent decide the settlement amount?
In the workflow described here, the authorised claims team owns that decision. The agent assembles the evidence, identifies unresolved differences, and executes approved follow-through within its assigned permissions.
Can this work with legacy claims systems?
The first implementation step is to verify access to the exact records and operations the workflow requires. Monarch's discovery approach can make verified operations in connected legacy and internal applications available to agents. System names alone do not establish coverage.
Can the same workflow serve Australia and the United States?
The case assembly and action sequence may be reusable. Policy language, local requirements, decision rules, and communications need to be configured and reviewed for the jurisdiction and insurer involved.