实习日志 / English / Journals / Journal 2: Project Description and Progress

Journal 2: Project Description and Progress

中文 | English

Background and Original Goals

First Notice of Loss (FNOL) is the point at which a customer first reports a loss to their insurer after an accident, theft or disaster, and the insurer opens a claim on that basis. It is the customer's first contact with the insurer after something unpleasant has happened, and much of how smoothly the rest of the claim goes depends on it.

Scenario 8 describes Northwind, an insurer handling more than 80,000 motor, home and contents claims a year. In the scenario, claims come in mainly through two channels. Phone claims are taken by contact-centre staff, who can follow a customer's natural account and deal with all kinds of exceptions, but each call averages 18 minutes, labour costs are high, and more volume can only be met with more staff. The web form is always available and collects fairly structured information, but it is long, its questions do not adapt to the incident, and 30% of people abandon it. Neither channel collects photos and documents systematically, so materials often have to be chased afterwards. The scenario states that 40% of claims need at least one follow-up contact, that it takes 2.5 days on average from first notice to claim creation, and that severity and fraud risk are assessed by hand only 24 to 48 hours after the claim is made.

The same problems show up in the real market. In its claims review published in 2025, New Zealand's Financial Markets Authority (FMA) found that only 43% of the insurers reviewed told claimants in the claim confirmation how they would receive progress updates. The report also recommended that insurers consolidate their requests for information from claimants [1].

The brief asks for an agent that guides the claimant from their first description through to claim creation, across 10 test scenarios (5 motor, 3 home, 2 contents). It needs to:

• hold a multi-turn conversation and ask clarifying questions;
• accept photos and PDFs;
• check cover and excess against anonymised policy documents;
• grade the severity of the case and flag fraud signals;
• call tools to create the claim in a mock claims system and book an assessor when needed;
• give the claimant the claim number and the expected timeline at the end.

Success is measured four ways: at least 80% of scenarios need no follow-up contact; claims staff blind-rate the severity grading; the fraud flags produce no false positives on the test set; and the claimant finishes in under 5 minutes and fewer than 10 questions.

What User-Centred Research Told Us

While the first prototype was being designed, the team ran user-centred research alongside it, carried out mainly by teammates. It drew on four kinds of source.

The first was an online survey of insurance customers and potential claimants in New Zealand. It was anonymous, ran on Google Forms and took about 3 to 5 minutes. Participants gave informed consent and were not paid. There were 155 valid responses, and about 70% came from people who had never made a claim. Some questions were shown only to people with claim experience, and some respondents skipped questions, so the number of answers varies from question to question. The percentages below are based on the people who actually answered each one.

The second was an informal interview with an insurance audit practitioner. It was conducted in writing and recorded by a teammate, with the interviewee's consent obtained beforehand.

The third was a small website observation, in which five participants from other project teams tried, in person, to go through the claims process on a New Zealand insurer's public website.

The fourth was public material: the FMA review, cases published by the Insurance & Financial Services Ombudsman Scheme, and the claim guides published by several insurers. Online customer reviews were used only as examples of individual experiences, never to infer how often a problem occurs.

Together these sources point to one core finding. Beyond long forms, what claimants struggle with is a string of things they do not know. They do not know what to do first after an incident, what evidence to gather, whether what they have given is enough, or what happens next and who is responsible for it. When AI is involved, they also do not know whether it has understood them, or whether a person will step in when things get complicated.

In detail, about a third (35.4%) of survey respondents with claim experience said they had not been clear about what information to provide, and 60.4% did not know how far their claim had got after submitting it. Asked what matters most, 71.7% chose seeing progress and next steps, and 48.3% chose clear requirements for documents and easy uploading. More than 40% worried that AI would misunderstand the incident or make decisions a person should have checked. The interview confirmed the same problems from the staff side: claimants are often unsure which documents they must get themselves and what the insurer takes care of, and staff spend a great deal of time explaining this over and over. In the website observation, all five participants got stuck on terms such as "policy number", and all five said they felt like giving up.

The findings have clear limits. The survey was exploratory, the sample was small and some questions had very few answers, so the results can help set priorities but cannot be read as population statistics. Evidence on the staff side came mostly from public process material and a single interview, and still needs to be checked with real claims staff. We kept these limits in mind throughout the later design.

My job at this stage was to turn the research findings into a development plan that could be verified. I broke the product goals down into sixteen functional requirements and twelve acceptance scenarios, each describing a complete experience that could be observed. For example:

• after a claimant describes a rear-end collision, the system produces a claim draft in which every fact is traced to the claimant sentence it came from;
• when a claimant mentions that someone was hurt, the system stops routine questions and passes the case to a person straight away;
• a Police report usually takes a while to be issued, so a claimant who returns a week later with the report can pick up where they left off without telling the story again.

The team's definition of done was that every demo path had to change the state actually recorded in the system. A demo that only showed the interface did not count.

Our Goals

Building on the research and our bid analysis, we framed the product proposition this way: build a trustworthy front door for claim coordination, where claimants describe what happened in their own words, the system takes on the professional organising and process work behind the scenes, and it stays responsible for moving the claim to the next safe step. "Trustworthy" means that every important fact and its source, every permission decision, every change of state and every human decision can be verified. Put plainly, the claimant should only have to say what happened. They should not have to become the project manager of their own claim.

The proposition rests on two key capabilities.

The first is a trustworthy, adaptive claim intake. The agent decides how much to ask, and how deeply, based on the incident and the claimant's situation. It turns the claimant's own account into a claim record with sources that can be taken further, asks for confirmation of key facts only when it has to, and hands over to a person with the full context when needed. The intake serves staff as well. They receive structured context with sources, uncertainties and outstanding tasks, and they can question, correct, reject or overrule the agent's suggestions.

The second is a coordination layer built on a single claim record. The claimant, the agent, staff and outside parties such as assessors, repairers and whoever provides Police documents all work from the same record. Context survives each handover, and the claimant does not have to repeat the story to everyone who picks it up.

Specifically, we want the system to:

• ask only what is genuinely needed for the next step, and never ask again for anything already confirmed;
• record the source and confirmation status of every fact, which the claimant can view and correct;
• when a document is missing for now, hold only the steps that depend on it and keep everything else that can safely go ahead moving;
• let a claimant who returns days later carry on from where they stopped;
• hand over at once, with the full context, when there are signs of injury or danger or the claimant asks for a person;
• always leave high-impact decisions such as cover, liability, fraud and settlement to people.

For acceptance, the team designed testing on a scale that could measure the four metrics in the brief and validate the system well beyond its 10 scenarios: at least 100 complete end-to-end claim runs on the final version, split across motor, home and contents in a 5:3

Directions Towards the Goals, and My Research and Literature Review

Meeting these goals means working in several directions at once:

• how the agent understands the claimant, makes decisions and works with the system;
• the interfaces and experience on the claimant side and the staff side;
• retrieval of data, policy knowledge and claim history;
• staff workflows and handovers;
• external services and documents;
• deployment and integration.

The team split the work along these lines, and I was mainly responsible for the agent's behaviour and orchestration and for the claimant-side experience. The sections below go through, goal by goal, the research I did for these areas and what I drew from the literature.

Making the agent move claims forward reliably: how mature systems do it

To work out what an agent that can really handle claims should be made of, I first surveyed industry practice: mainstream conversational customer-service platforms, insurance-specific products, and the infrastructure behind long-running processes. Vendor material varies widely in how far it can be trusted, so I sorted sources into four levels: official technical documentation, public implementations with readable code, product descriptions that hide their internals, and my own inferences. Vendor claims about effectiveness counted only as product descriptions.

The findings come down to a few points:

• mature platforms manage conversation state and business processes explicitly, outside the model, for example using pages and parameters to track where a conversation is and separately defined flows to carry the business logic [2], [3];
• the facts and state of a claim should sit with the application, while the model understands, organises and proposes;
• the system needs a defined process, yet claimants may jump around, correct themselves at any point or stop halfway;
• one turn often involves replying to the claimant, recording facts, looking things up and arranging the next step all at once;
• handing over to a person is a normal capability, and a good handover depends on a complete reason, priority and context;
• retrieved policy content is evidence for a judgement and does not authorise any action on its own;
• evaluating an agent means looking at every step it takes.

Keeping the agent controllable: internal orchestration, tool calling and constraints

Two surveys give a framework for how agents are built. Wang et al. describe autonomous agents built on large language models in terms of profile, memory, planning and action modules [4], while Xi et al. discuss them in terms of "brain, perception and action" [5]. Both show that most of the engineering in a usable agent happens outside the model.

On tool calling, ReAct has the model alternate between reasoning steps and concrete actions, drawing on outside information to cut down fabrication [6]. Toolformer shows that a model can learn to call external tools such as calculators and search when it needs them [7]. Our agent also uses tightly bounded tools to look up policies and read claim records. Both studies, though, ask whether a model can call tools. In a regulated business we also have to ask whether it is allowed to.

τ-bench tackles exactly that question. It tests agents in customer-service domains such as retail and airlines, where they must deal with users, tools and domain policies at the same time, and finds that even strong models succeed on fewer than half of the tasks and give inconsistent results across repeated runs [8]. For us this meant two things. Compliance with insurance requirements cannot rest on the prompt alone, and evaluation has to look at the whole interaction and at whether repeated runs agree.

On the limits of prompting, Zamfirescu-Pereira et al. found that non-experts design prompts largely by trial and error, and that prompt-based interaction is brittle [9]. LMQL treats prompts as programs, adding constraints and control flow on top of model output [10]. AI Chains breaks complex tasks into a chain of steps, which in a user study improved output quality, transparency and controllability together [11]. Following these studies, I took behavioural constraints out of the prompt. The fields, actions and tools the system allows are each written down as a finite list, and each kind of output is validated separately. A turn is split into three stages that are recorded separately: the model proposes, the system approves, and the action is carried out.

Structured output has a cost too. Tam et al. found that strict format restrictions weaken a model's reasoning [12]. So I kept the parts the system must validate narrow and stable, and left the rest for the model to express naturally.

On context, Liu et al. found that models perform noticeably worse when the relevant information sits in the middle of a long context [13]. Each turn therefore loads only what is needed at that moment: a snapshot of the current claim, open questions and the last few turns of conversation. The full record is kept outside and fetched when needed.

On safety, Greshake et al. showed that attackers can hide instructions in data an application will later retrieve, and so steer the model [14]. NeMo Guardrails offers a way to define conversational constraints outside the model [15]. We therefore treat policy documents and claimant uploads strictly as data, never as instructions, and the system checks for safety signals such as injury or danger before the model is called.

On evaluation, Shankar et al. found that the criteria for judging LLM output need to be calibrated by people, and that people's own criteria shift as they grade [16]. Automated checks help find problems, but people still have to set the standard.

Making the agent serve people: the external journey, division of work and trust

Customer journey research treats the sequence of touchpoints a customer passes through as the unit of analysis and design [17]. We take the claim journey as our unit in the same way, from the claimant's first sentence to the moment staff take over.

On dividing work between people and AI, Huang and Rust sort service tasks into mechanical, thinking and feeling, and argue that for now mechanical service goes mainly to AI, thinking service is shared, and feeling service stays mainly with people [18]. Our division follows the same lines. Organising and recording information goes to the agent. Questions that need professional judgement, such as cover and liability, are prepared by the agent and decided by staff. A claimant who is in an emergency or in distress is passed to a person as quickly as possible.

In a field study with about 600 participants, Xiao et al. compared an ordinary online survey with an AI-powered conversational one and found that the conversational survey drew more engagement, with open-ended answers that were more informative, relevant, specific and clear [19]. This backs our choice of conversation over long forms for collecting the incident description.

On chatbot personas, the research offers two cautions. Adam et al. found that human-like language cues, and making a small request before a larger one, make users more willing to go along with a chatbot's requests [20]. Crolic et al., on the other hand, found that when customers arrive angry, a human-like bot lowers their satisfaction, because it raises their expectations [21]. Someone who has just had an accident may well be anxious or angry, so our agent's persona is restrained: professional and friendly, not pretending to be human, and focused on getting things done properly.

On human-AI interaction design, Yang et al. identify two root causes that make it hard to design: uncertainty about what the AI can do, and the complexity of its output [22]. Amershi et al. set out 18 guidelines, including making clear what the system can do and supporting efficient correction [23]. Our interface therefore shows what the agent has recorded and where each piece of information came from. Claimants can edit it directly or ask for corrections in plain language, and anything the backend cannot yet do is shown honestly as unavailable.

Finally, trust. People often over-rely on AI, and explanations do not necessarily help. Bansal et al. found that explanations made people more likely to accept AI recommendations whether or not they were right [24]. Vasconcelos et al. found that over-reliance falls only when explanations make the AI's judgement cheaper to verify [25]. Buçinca et al. designed "cognitive forcing" interventions that reduce over-reliance, although users liked them less [26]. These findings shaped the staff side of our design. The staff-side agent only produces drafts, which are carried out once staff have edited and confirmed them. Fraud appears only as a signal with its sources, never as a conclusion. And every fact carries its source, so that checking it costs staff very little.

Limits of this research in the claims setting

Most of the research above comes from general tasks or from customer-service settings such as retail and airlines. After an insurance incident, emotions run higher, and the business requirements involve policy wording and regulation, so these findings need to be re-validated in our setting. That is also why the team insists on real end-to-end testing and blind testing.

Research in other directions

On the front end, I read Refactoring UI [27], worked through it section by section to decide which principles suited our product, and drew on mature products in the industry to turn the rough first prototype into a design system shared by both sides. The design's tone comes from an observation the industry mentor shared: what people really trust is a professional personal client manager who sees things from their side. The interface therefore uses a soft off-white background, keeps accent colours for places where they carry meaning, does not flag outstanding documents in red, and keeps claimant-side body text at 16px or larger. Colour, type size, spacing and other design elements were turned into design tokens shared by both sides.

On response speed, to keep the agent's response times and call costs under control, I also looked at how several mainstream AI coding tools and agent frameworks load context [28]. My conclusion was that letting the model know something exists and sending it the full text of that thing in the current turn should be handled as separate steps.

Where We Are Now

The system can now take a claim from start to finish with a real model in motor, home and contents scenarios. Starting from the claimant's own account, the agent pulls several facts out of a single sentence and records their sources, asks follow-up questions where needed, recognises signs of injury and requests for a person and hands over promptly, sends third-party service requests such as assessments once the claimant consents, and finally either creates the claim in the mock claims system or hands the case to staff with its full context. The claimant side and the staff workbench work from the same claim record, and staff can see sources, gaps and risk signals and move the case on. Because a real deployment may come with data privacy requirements, the system can switch between cloud models and a local model hosted on the team's server.

What remains unfinished should be said plainly. Testing so far relies mainly on synthetic data and mock services, with no connection yet to a real insurer's systems. The migration to AWS is being carried out by the teammate responsible for the backend. The 100 complete claim runs and the real blind test will take place on the final version after the feature freeze.

In the most recent sprint presentation feedback, industry judges pointed out that the claims process needs to be closer to real practice. After a real rear-end collision, for example, the claimant usually notes the other party's registration, driver and insurer first; when someone is hurt, Police are often involved; and the excess is treated differently depending on who is at fault. We went back and researched the real claims process and the order in which a client manager asks questions, and divided the follow-up work into four parts:

• add the fields that are needed, such as the other party's details, witnesses and the status of the Police report;
• have the agent check on safety and ask for key information more proactively, and explain why when it hands over to a person;
• where policy wording calls for professional judgement, have the agent set out the basis and offer a preliminary view for staff to decide on;
• link the claimant's policy to its actual excess structure.

Next, we will freeze the feature set and complete these tests, record a demo video and finish the slides and poster from the same version, and then draw the whole project together in the final presentation and report.

References

[1] Financial Markets Authority, "Weather events claims insights," Jul. 2025. [Online]. Available: https://www.fma.govt.nz/library/reports-and-papers/weather-events-claims-insights/

[2] Google Cloud, "Dialogflow CX: Pages." [Online]. Available: https://cloud.google.com/dialogflow/cx/docs/concept/page

[3] Rasa, "Flows." [Online]. Available: https://rasa.com/docs/reference/primitives/flows/

[4] L. Wang et al., "A survey on large language model based autonomous agents," Frontiers of Computer Science, vol. 18, no. 6, 2024, doi: 10.1007/s11704-024-40231-1.

[5] Z. Xi et al., "The rise and potential of large language model based agents: A survey," Science China Information Sciences, vol. 68, 2025, doi: 10.1007/s11432-024-4222-0.

[6] S. Yao et al., "ReAct: Synergizing reasoning and acting in language models," in Proc. Int. Conf. Learning Representations (ICLR), 2023.

[7] T. Schick et al., "Toolformer: Language models can teach themselves to use tools," in Advances in Neural Information Processing Systems 36 (NeurIPS), 2023, doi: 10.52202/075280-2997.

[8] S. Yao, N. Shinn, P. Razavi, and K. Narasimhan, "τ-bench: A benchmark for tool-agent-user interaction in real-world domains," in Proc. Int. Conf. Learning Representations (ICLR), 2025.

[9] J. D. Zamfirescu-Pereira, R. Y. Wong, B. Hartmann, and Q. Yang, "Why Johnny can't prompt: How non-AI experts try (and fail) to design LLM prompts," in Proc. CHI Conf. Human Factors in Computing Systems, 2023, doi: 10.1145/3544548.3581388.

[10] L. Beurer-Kellner, M. Fischer, and M. Vechev, "Prompting is programming: A query language for large language models," Proc. ACM on Programming Languages, vol. 7, no. PLDI, 2023, doi: 10.1145/3591300.

[11] T. Wu, M. Terry, and C. J. Cai, "AI chains: Transparent and controllable human-AI interaction by chaining large language model prompts," in Proc. CHI Conf. Human Factors in Computing Systems, 2022, doi: 10.1145/3491102.3517582.

[12] Z. R. Tam et al., "Let me speak freely? A study on the impact of format restrictions on large language model performance," in Proc. Conf. Empirical Methods in Natural Language Processing: Industry Track, 2024, doi: 10.18653/v1/2024.emnlp-industry.91.

[13] N. F. Liu et al., "Lost in the middle: How language models use long contexts," Transactions of the Association for Computational Linguistics, vol. 12, 2024, doi: 10.1162/tacl_a_00638.

[14] K. Greshake et al., "Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection," in Proc. 16th ACM Workshop on Artificial Intelligence and Security, 2023, doi: 10.1145/3605764.3623985.

[15] T. Rebedea et al., "NeMo Guardrails: A toolkit for controllable and safe LLM applications with programmable rails," in Proc. Conf. Empirical Methods in Natural Language Processing: System Demonstrations, 2023, doi: 10.18653/v1/2023.emnlp-demo.40.

[16] S. Shankar et al., "Who validates the validators? Aligning LLM-assisted evaluation of LLM outputs with human preferences," in Proc. ACM Symp. User Interface Software and Technology (UIST), 2024, doi: 10.1145/3654777.3676450.

[17] A. Følstad and K. Kvale, "Customer journeys: A systematic literature review," Journal of Service Theory and Practice, vol. 28, no. 2, 2018, doi: 10.1108/JSTP-11-2014-0261.

[18] M.-H. Huang and R. T. Rust, "Engaged to a robot? The role of AI in service," Journal of Service Research, vol. 24, no. 1, 2021, doi: 10.1177/1094670520902266.

[19] Z. Xiao et al., "Tell me about yourself: Using an AI-powered chatbot to conduct conversational surveys with open-ended questions," ACM Transactions on Computer-Human Interaction, vol. 27, no. 3, 2020, doi: 10.1145/3381804.

[20] M. Adam, M. Wessel, and A. Benlian, "AI-based chatbots in customer service and their effects on user compliance," Electronic Markets, vol. 31, 2021, doi: 10.1007/s12525-020-00414-7.

[21] C. Crolic, F. Thomaz, R. Hadi, and A. T. Stephen, "Blame the bot: Anthropomorphism and anger in customer-chatbot interactions," Journal of Marketing, vol. 86, no. 1, 2022, doi: 10.1177/00222429211045687.

[22] Q. Yang, A. Steinfeld, C. Rosé, and J. Zimmerman, "Re-examining whether, why, and how human-AI interaction is uniquely difficult to design," in Proc. CHI Conf. Human Factors in Computing Systems, 2020, doi: 10.1145/3313831.3376301.

[23] S. Amershi et al., "Guidelines for human-AI interaction," in Proc. CHI Conf. Human Factors in Computing Systems, 2019, doi: 10.1145/3290605.3300233.

[24] G. Bansal et al., "Does the whole exceed its parts? The effect of AI explanations on complementary team performance," in Proc. CHI Conf. Human Factors in Computing Systems, 2021, doi: 10.1145/3411764.3445717.

[25] H. Vasconcelos et al., "Explanations can reduce overreliance on AI systems during decision-making," Proc. ACM on Human-Computer Interaction, vol. 7, no. CSCW1, 2023, doi: 10.1145/3579605.

[26] Z. Buçinca, M. B. Malaya, and K. Z. Gajos, "To trust or to think: Cognitive forcing functions can reduce overreliance on AI in AI-assisted decision-making," Proc. ACM on Human-Computer Interaction, vol. 5, no. CSCW1, 2021, doi: 10.1145/3449287.

[27] A. Wathan and S. Schoger, Refactoring UI. 2018.

[28] Anthropic, "Effective context engineering for AI agents." [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents