Large Language Models Case Studies
Technical5 Case StudiesUpdated Sep 2026
Five scenarios follow, each set inside a production setting where a language model sits within a product, a reporting pipeline, or a staff workflow. The organizations are invented, but the pressures will be familiar to anyone who has shipped model-backed features: a release that behaves differently than the test set suggested, figures that disagree across reports, a prompt that can be turned against the system, costs that climb with each new customer, and a pilot that looks efficient until its errors are counted. Each case weighs business goals, evidence, operating limits, and stakeholder impact.
Case Study 1
Support assistant regression after a prompt template release
Kestrel Ledger, a payroll software vendor whose chat-based help assistant serves about 2,400 small business customers.
The situation
Early in the quarter, Kestrel Ledger shipped a revised system prompt and a rebuilt retrieval index for its help assistant. The goal was shorter answers that cited current withholding tables. Within a day, the support queue filled with reports that the assistant was giving outdated rules and refusing questions it had handled well the previous week. Escalations to human agents climbed from about 11 percent of conversations to 34 percent. On-call engineer Dana found that p95 latency had doubled, because the new index returned longer passages and the model was truncating answers to fit a token budget that no longer matched.
The challenge
Rollback was possible but not clean, since the old index had been overwritten during the deploy. Product wanted the assistant back within the hour, support leads wanted the outdated tax answers pulled immediately, and finance had a payroll-season deadline that made any extended outage expensive. Nobody had a clean log of which prompt version produced which answer, which made the scope of bad responses hard to bound.
Analysis
Teams grounded in Large Language Models tend to read this incident first as a question about the objective, not the model. Kestrel's stated aim was fewer tokens per answer and fresher citations, but the measure that mattered to customers was whether a payroll answer was correct the first time. Those goals pulled against each other, and the release had optimized the first while assuming the second would hold. Evidence in the first hours was thin. The prompt version was logged, but retrieval results were not, so the team could see what changed but not what the model actually received. That gap decided the order of work.
The operational constraints were real. Payroll customers were in a filing window, so a full shutdown of the assistant would push load onto three human agents who already had a backlog. Reverting the prompt was cheap, but restoring the index meant about six hours of embedding jobs, and those could not start without pausing ingestion for other products. Stakeholder impact fell unevenly. Small firms that relied on the assistant as their only tax reference were most exposed, and their complaints arrived as ordinary tickets with no mention of the release, which delayed recognition that the failure was systemic.
- Contain Revert prompt and route tax questions to humans
- Investigate Trace which passages each flagged answer actually used
- Rebuild Stage a clean index beside the live one
- Prevent Gate every change on replayed traffic
Actions taken
- Roll back the system prompt to the previous version immediately, and put the assistant behind a banner that routes tax-rule questions directly to a human queue until the index is verified.
- Snapshot retrieval results and prompt version for every conversation going forward, then sample two hundred flagged transcripts by hand to find which answers carried stale passages.
- Rebuild the index into a new namespace while keeping the old one live, and switch traffic only after a regression set of four hundred payroll questions passes at the agreed threshold.
- Add a release gate that compares latency, escalation rate, and answer agreement against the previous build on a fixed replay of recent traffic before any prompt or index change ships.
Results
Service was restored within the same afternoon, and human escalations fell back to about 12 percent by the next morning. The rebuilt index passed the regression set in the second week, after two rounds of chunking changes. The release gate later caught a similar latency regression before it reached customers, and the team came to regard the replay set as its most useful artifact. The sampled transcripts showed that roughly one wrong answer in six came from stale passages rather than prompt wording, which moved index hygiene to the top of the next sprint.
Questions for discussion
- Which signals would have revealed the stale index before the escalation rate moved, and who should own logging those signals?
- When a regulated answer is wrong, how should the decision to pull a feature be weighed against the cost of a full outage for customers in a filing window?
- What would a replay set need to contain for a release gate to catch regressions that appear only in rare payroll scenarios?
Case Study 2
Conflicting loan exposure figures across weekly risk reports
Dunmore Credit Cooperative, a regional lender with about 180,000 member accounts and a small central analytics team.
The situation
Dunmore's risk group publishes a weekly pack that pairs warehouse tables with a narrative summary drafted by a language model from the same extracts. In the most recent cycle, the summary said agricultural loan exposure had dropped about four percent, while the exposure table showed a rise of about two percent. Branch managers read the summary first and the committee read the table, so both numbers reached people who could act on them. Nobody could say which figure was right without rebuilding the extract by hand, and the two analysts who knew the join logic were both away.
The challenge
The committee was due to set provisioning guidance the following week, and the gap between a four percent drop and a two percent rise was large enough to change the recommendation. The team also suspected the problem was not confined to one segment. Member records had been merged from two legacy systems with different account identifiers, and a small share of loans had no matching collateral row. Leadership wanted a defensible number quickly, while the data team needed to avoid papering over a lineage problem that would recur.
Analysis
The business objective was a reliable provisioning recommendation, not a polished summary. Narrative generation had added speed to the pack, but it had no independent check against the tables it described, so its fluency made a stale or mis-joined figure look authoritative. The available evidence was the extract logs, row counts at each join, and a set of manually reconciled accounts from the last audit cycle. Those were enough to locate the divergence in the segment mapping but not enough to say how many loans it touched. Any honest answer had to separate what was confirmed from what was inferred.
Operational constraints shaped the response. The analytics team had two people and a weekly freeze on schema changes that the lending platform team could not waive. Rewriting the pipeline end to end was not feasible in the window, so the work became a sequence of validations placed where loss or duplication could occur. Stakeholder impact ran in two directions. Branch managers had already acted on the optimistic summary in a handful of cases, and committee members were reluctant to delay guidance they had been told was settled. Credibility with both groups depended on showing the reconciliation, not just the corrected number.
Actions taken
- Freeze the summary generator for this pack and publish the table figures alone with a note that the narrative is withdrawn pending reconciliation, so readers stop acting on the disputed sentence.
- Trace each reported exposure total back through its joins, logging row counts before and after every merge, and identify the legacy identifier mismatch that dropped collateral matches.
- Add assertion checks at each stage: row counts within an expected band, no duplicate loan identifiers after the merge, and a reconciliation of totals against the core ledger before publication.
- Require that any generated narrative cite the table and query it was drawn from, and have a named analyst sign off on every figure quoted before the pack leaves the group.
Results
The mapping fault was traced within the first working session. A rule had discarded collateral matches for agricultural loans restructured under the legacy system, and the corrected exposure rose about two percent, consistent with the table. The narrative had been wrong because the model summarized an intermediate extract that predated the fix. The committee deferred guidance by one week. Over the next two cycles, the assertion checks caught a second duplicate-identifier problem before publication, and the group stopped generating narrative from any extract that had not passed them.
Questions for discussion
- Which checks should block publication outright, and which should only raise a warning that a named analyst must clear?
- How should a team decide whether a discrepancy between a narrative and a table reflects a generation error or a data error?
- What ownership model keeps identifier mapping rules current while a legacy system still feeds the warehouse?
Case Study 3
Possible credential exposure through a support assistant's tool calls
Lantern Parcel Group, a regional freight carrier handling about 3,200 shipments a day, with an email assistant that reads account records.
The situation
Lantern Parcel Group runs an email assistant that answers shipment questions by calling internal tools for tracking data and, in some cases, account records. Those tools authenticate with a single service credential that the assistant process holds in memory. In the second week of the month, the security lead, Ruben, noticed an unusual spike in account lookups from conversations that had been classified as simple tracking questions. Several of those emails contained quoted text instructing the assistant to list every account in a postal region and return them in a reply. Two replies had already gone out with partial account identifiers before the rate limit tripped.
The challenge
The team had to decide whether this was a prompt injection the model had merely obeyed, a broader compromise of the service credential, or both. Scope mattered because account records included billing addresses for small business customers. Containment could not wait for a full forensic image, but cutting the assistant off would stop shipment support during the peak mail period, and the customer service director had already promised a same-day answer to a major account.
Analysis
The objective was to limit exposure of customer data while keeping shipment support running, and those two aims did not share the same order of priority in the first hour. The evidence available was the tool call log, the email archive, and the assistant's trace output, which recorded requests but not the full context the model had been given. That gap made it hard to tell whether injected text had reached the model or whether a legitimate customer had asked an odd question. Preserving those logs before any rotation or restart was the first constraint, because automated retention would otherwise overwrite the window under review.
The response was bounded by who could approve each step. Rotating the service credential would break tracking lookups across three other internal tools, so the on-call team needed the platform owners present before acting. Legal had to be informed early, because customer address data is regulated in several of the regions Lantern serves, and notification timing depends on when exposure is established rather than when it is suspected. Stakeholder impact also reached customers who never wrote a suspicious email, since their records were visible to the same lookups. The plan therefore had to document each authorized step so that later review could separate containment from investigation.
Actions taken
- Disable account-record tool access for the assistant at the gateway, leaving tracking lookups in place, and record the change with the approver's name and time before making it.
- Snapshot the tool call logs, email archive, and trace store to write-once storage, and suspend automated retention on those stores until the forensic review closes.
- Rotate the service credential through the platform owners' runbook once the snapshot is verified, then review every account lookup made under the old token for the prior thirty days.
- Brief legal and the customer notification lead using only the list of confirmed lookups, marking suspected cases separately, and hold any outbound message until the scope is agreed in writing.
Results
Account lookups were blocked within the hour, and shipment support resumed on tracking tools while the account path stayed off. The forensic review tied 41 lookups to the injected emails, 38 of them returning records from a single postal region, and found no evidence that the service token had left the environment. Legal confirmed that notification duties applied to the affected customers, and letters went out inside the required window. The assistant's account tool now runs only on verified customer sessions, and inbound email text is treated as untrusted data.
Questions for discussion
- How should a team decide between a narrow containment step that leaves some exposure open and a broader shutdown that stops a service customers depend on?
- What evidence would separate a prompt injection that reached the model from a legitimate but unusual customer request in the trace data?
- Which parts of the response plan should be written before an incident, and which can only be decided once the scope is known?
Case Study 4
Choosing a model serving path for resume summaries
Brightwater Talent, a job marketplace whose resume summaries and candidate matching features now serve about 96,000 users a day.
The situation
The resume summary feature began as a single call to a hosted model, quick to ship and easy to change. Two quarters later, p95 latency had reached about 3.8 seconds, and the inference bill was growing faster than active users. The growth plan called for roughly three times the current volume once a new employer tier opened, and the product team wanted summaries under two seconds. Resumes contain personal data, so the security group wanted to know where text was processed and retained. The platform team had three options: keep the hosted API with aggressive caching, host an open-weight model on dedicated GPUs, or route simple cases to a smaller distilled model.
The challenge
No single option satisfied all three constraints. Caching worked well for repeated resumes but not for new uploads, which made up most of the traffic at peak. Self-hosting gave control over data location but required an on-call rota the platform team did not have. A distilled model would be cheapest and fastest, yet its summaries of senior technical resumes were noticeably weaker in the team's first trial.
Analysis
The business objective was summaries that recruiters kept reading, at a unit cost the growth plan could carry. Latency mattered because recruiters abandoned slow screens, but it was a proxy rather than the target. The evidence was a month of request logs with token counts, a set of about 1,200 summaries rated by recruiters, and traces broken down by stage. The traces showed that most of the delay came from assembling long prompts and waiting on retrieval, not from generation itself. That finding made some options look better than their benchmark numbers suggested, so the team had to measure each option on its own workload.
Operational constraints narrowed the field quickly. Two engineers were comfortable with GPU serving and no one was on call for it, so any self-hosted path implied a staffing decision, not only an infrastructure one. Data residency rules applied to resumes uploaded by candidates in specific regions, which made routing by region a compliance question as well as a cost lever. Stakeholders split along predictable lines. Recruiters cared about summary quality on hard cases, finance cared about the cost curve, and the security group cared about who could read retained prompts. Each group was right about its own risk, and the comparison had to show all three together.
- 1Cache checkReturn stored summary when the resume hash matches
- 2Length and region routerSend short and eligible resumes to the distilled model
- 3Hosted model pathLong or sensitive resumes under regional processing terms
- 4Logging and reviewRecord serving path, latency, and recruiter feedback per request
Actions taken
- Cache assembled prompts and retrieval results for resumes already seen, and measure the hit rate on the first week of production traffic before committing to any larger serving change.
- Route resumes by length and region: short English resumes to the distilled model, long or sensitive ones to the hosted model under a regional data processing agreement, and log which path served each request.
- Run a blind comparison of summaries from the distilled and hosted paths on the labeled set, with recruiters scoring senior technical resumes separately, and set a quality floor before any traffic moves.
- Defer dedicated GPU hosting until the routed volume is measured, and write down the on-call and patching commitments it would require so the decision is made with staffing costs included.
Results
Caching alone brought p95 latency under three seconds for about 60 percent of requests in the first two weeks. Routing short resumes to the distilled model brought the median summary under two seconds. The blind comparison showed recruiter preference held on routine cases but fell behind on senior technical resumes, which kept those on the hosted path. The dedicated GPU option was set aside for the quarter, with the staffing gap written into the plan. Finance accepted a blended unit cost that met the growth case, though the margin was thinner than the original forecast.
Questions for discussion
- How should the quality floor for senior technical resumes be set when recruiter preference and cost pull in different directions?
- What would change the staffing calculation for dedicated hosting, and at what routed volume would it be worth revisiting?
- Which measurements should run continuously after launch, and which only need to be repeated when the model or the routing rules change?
Case Study 5
Evaluating an LLM claims intake drafter before wider rollout
Fennick Marine Insurance, a mid-sized underwriter whose claims desk handles about 620 new property and marine claims each week.
The situation
Fennick's claims desk proposed a language model to draft structured intake records from recorded calls and written statements, with a suggested triage category for each claim. The vendor's pilot summary projected that intake time would fall by about 40 percent. The pilot had run for four weeks in one regional office, and the people who had seen it most closely were enthusiastic. Two adjusters noticed that the drafts sometimes omitted a named exclusion, and that triage categories for claims from non-English-speaking callers were more often set to low severity. Nobody had counted either problem, because the pilot measured speed and not accuracy by claimant group.
The challenge
The claims director wanted a decision on wider rollout before the next reinsurance renewal conversation, and the vendor was pressing for a contract with volume tiers. The team needed metrics that would catch omitted exclusions and uneven triage, not just average speed. Human review capacity was limited, and any oversight design that required adjusters to re-read every draft would erase most of the time savings.
Analysis
The business objective was faster, consistent intake without more coverage disputes or uneven triage. Speed was the easiest part to measure, and it had been the only measure in the pilot. The evidence that mattered came from an audit sample: 300 closed claims from the pilot office, rebuilt independently by two senior adjusters, then compared against the drafts for omitted exclusions, wrong coverage lines, and triage category, broken out by claimant language and region. The sample was small, so the team treated it as a screen for problems rather than a precise error rate.
Operational constraints set the shape of oversight. Adjusters could not review every draft without losing the speed gain, so review had to be targeted: drafts with a low severity suggestion on claims above a threshold, any draft that did not reference the policy's exclusion list, and a random sample of the rest. Several states expect documented human decisions on claim outcomes, so the model could recommend a category but could not set one. Stakeholders had different stakes. Claimants bore the most exposure to error and had the least visibility into how their record was made, while the sales team wanted the pilot extended to new products before the audit results were in.
- Week oneSenior adjusters rebuild audit sample against the drafts
- Week threeFirst stop rule review and exclusion prompt revision
- Week fiveSecond office opens on revised triage guidance
- Week nineIndependent audit decides on wider expansion
Actions taken
- Define the evaluation metrics before any further pilot traffic: omitted exclusions per hundred drafts, coverage line accuracy, triage agreement with reference records, and time to intake, each reported by claimant language group and region.
- Set a human review rule in which adjusters must confirm every exclusion and every triage category before a claim advances, with sampling limited to routine fields such as contact details and loss dates.
- Roll out in stages, starting with one office for four weeks under a stop rule that halts drafting if omitted exclusions exceed the agreed threshold two weeks running, then expand only after independent audit.
- Publish a plain-language notice to claimants that an assistant helped prepare their intake record, with a route to request a full manual intake, and log each request as a signal for the bias review.
Results
The audit sample found omitted exclusions in a little under 4 percent of drafts, concentrated in claims with multiple coverage parts, and triage disagreement was higher for non-English-speaking claimants than for the rest. The stop rule fired once in the first office, and the team corrected the exclusion prompt rather than blaming the reviewers. Intake time fell by about 22 percent in the pilot office, less than the vendor had projected, but enough for the claims director to approve a second office on the revised rules. The disagreement gap narrowed after the triage guidance was rewritten, and the team still reports it monthly.
Questions for discussion
- Which threshold for omitted exclusions should trigger the stop rule, and who should be authorized to override it?
- How much adjuster time should a review design consume before the savings from drafting are no longer worth the oversight?
- What evidence would show that uneven triage reflects a problem in the drafts rather than real differences in claim complexity?
Learning Resources
Technical CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.