Eight Industries, One Question: Where AI Pays Off First in Kansas City
AI use cases by industry are usually ranked by hype. A better ranking asks how many months it takes to prove a use case worked. Across eight Kansas City industries, the answer runs from under a month to more than 70 years, and every industry has both kinds. Python included.
Every Kansas City executive I talk to asks a version of the same question: where does AI actually pay off, and where is it still a science project? The answer usually comes back as an industry ranking. Finance first, healthcare next, manufacturing someday. That framing is wrong in a useful way. Inside every industry in this metro there is a use case that can prove itself in about a month and another that will take years. The difference has less to do with the industry than with arithmetic.
The arithmetic is about learning speed. A use case pays off first when it produces many decisions a month, when you find out quickly whether each decision was right, and when a wrong answer is cheap to catch. A service center handles thousands of cases a week and grades them the same day. A credit model waits a year to see who defaults. A commodity forecast gets one winter a year to be right or wrong. Those three facts decide which projects can show a return before the next budget cycle, and they are knowable before anyone buys a license.
This piece takes the eight industries I cover at Vector1 Research (healthcare, finance and insurance, engineering and architecture, marketing and advertising, manufacturing, transportation and logistics, utilities and energy, and commodities and agribusiness) and asks one question of each: how many months until you can prove it worked? You get one formula, a Python model that runs as written, the published field evidence behind each industry’s fastest use case, and plain numbers on the ones that take years. It is written for executives deciding where to spend a first AI budget, and for hiring managers deciding what kind of people that budget needs.
The short answer
- Every industry has a fast use case and a slow one. In the model below, a bank or insurer’s service assistant can be proven in about 1.0 month, ambient clinical documentation in 1.1, content production in 0.7 and route optimization in 0.6. Credit losses take about 5 years, sepsis mortality 27 months, transformer failures 6.3 years and fleet crash rates nearly 12.
- The field evidence favors high-volume knowledge work. Generative AI raised resolutions per hour by 14% across 5,179 support agents, cut time on professional writing tasks by 40% across 453 professionals, and made consultants 25.1% faster on tasks inside its abilities. The same consultants were 19 percentage points less likely to get a task right when it fell outside them.
- Some industries start in a hole. Census research on U.S. manufacturing finds that industrial AI lowers productivity in the short run before it raises it, with the largest losses at older plants.
- Forecasting is the slowest place to prove a gain. Using my own natural gas backtest, a winter price model 10% better than the futures curve would take about 71 years of winters to prove.
- Time saved is not money saved. A study of 25,000 Danish workers found AI chatbots saved 2.8% of work hours and that only 3% to 7% of those savings reached earnings. For a 100-agent service center, payback runs 4.2 months if every saved hour is captured and 22.6 months if a quarter is.
The one question: how long until you can prove it worked?
A use case pays off only after someone can show it worked, because that is when a budget owner scales it, renews it or kills it. So the useful number to estimate before a pilot is the time to proof:
T = A + L + max(0, N − H) / r
A is setup time, the weeks it takes to instrument the work and run the analysis. L is the feedback lag, the months between a decision and knowing whether it was right. N is the number of units (cases, notes, loans, route-days) the test needs. H is history already on hand that a fair backtest can use, which is zero for most new workflows and large for forecasting. r is the number of units the organization produces a month.
N comes from the ordinary sample size formulas, and they are where most pilots go wrong. For an outcome measured on a scale, like minutes per note or cases per hour, a randomized test with two arms needs this many units per arm:
n = 2 × (z₀.₉₇₅ + z₀.₈₀)² × (CV / δ)²
δ is the relative improvement you want to detect and CV is the outcome’s coefficient of variation, its standard deviation divided by its mean. At 5% significance and 80% power, (z₀.₉₇₅ + z₀.₈₀)² = 7.85. When both methods can be scored on the same units, as in a forecast backtest, the test is paired and the leading 2 drops out. For an event rate, like defaults or crashes, the formula uses the baseline rate p₀ and the improved rate p₁:
n = 7.85 × [p₀(1 − p₀) + p₁(1 − p₁)] / (p₀ − p₁)²
Here is the worked example that sets up the rest of the piece. A Kansas City insurer runs a 100-agent service center and tests an AI assistant on half its agents. The best field evidence says resolutions per hour rise about 14%. If weekly resolutions per agent have a CV of 0.35 (an assumption), the test needs 2 × 7.85 × (0.35 / 0.14)² = 98 agent-weeks per arm, or 196 in total. A 100-agent center produces about 400 agent-weeks a month, so the data arrives in 0.49 months. Add a week of quality review as the lag and a week of setup, and T is 1.0 month.
Now the same insurer tests a model meant to cut 12-month credit or fraud losses by 10% from a 3% base rate. The event formula gives 48,289 accounts per arm. At 2,000 new accounts a month, collecting them takes 48.3 months, and the last one needs another 12 months to show whether it went bad. T is 60.5 months. Same company, same data team, a sixty-fold difference.
The three terms that set T are properties of the work, not of the model. Volume r is how often the decision happens. Lag L is how fast the world grades it. And the ratio CV / δ is how loud the signal is against the noise, which is why rare events are so slow: when p₀ is small, (p₀ − p₁)² is tiny. A vendor can promise a bigger δ. It cannot change r, L or p₀.
"""payoff.py, part 1: time to proof for an AI use case (a proposed model).
Brian Curry | Vector1 Research."""
from dataclasses import dataclass
from statistics import NormalDist
Z = NormalDist().inv_cdf(0.975) + NormalDist().inv_cdf(0.80) # 5% two-sided test, 80% power
def n_continuous(cv: float, delta: float, paired: bool = False) -> float:
"""Units per arm to detect a relative change `delta` in an outcome with coefficient of variation `cv`.
Paired designs (both methods scored on every unit, as in a forecast backtest) need one arm."""
return (1 if paired else 2) * Z**2 * (cv / delta) ** 2
def n_binary(p0: float, reduction: float) -> float:
"""Units per arm to detect a relative `reduction` in an event rate p0."""
p1 = p0 * (1 - reduction)
return Z**2 * (p0 * (1 - p0) + p1 * (1 - p1)) / (p0 - p1) ** 2
@dataclass
class UseCase:
industry: str
name: str
per_arm: float # units needed per arm (from n_continuous or n_binary)
rate: float # units a month the organization produces
lag: float # months from a decision to knowing its outcome
paired: bool = False # True when both methods can be scored on the same units
history: float = 0.0 # units already on hand that a backtest can use
setup: float = 0.25 # months to instrument and analyze, even when data is on hand
def months_to_proof(self) -> float:
"""T = A + L + max(0, N - H) / r, with N the total units the test needs."""
total = self.per_arm * (1 if self.paired else 2)
return self.setup + self.lag + max(0.0, total - self.history) / self.rateThe formulas assume units are independent. Agent-weeks from the same agent are not, so a real test randomizes by agent or team and needs more data than this; the section on where the ranking breaks returns to that. Treat T as a lower bound.
The eight industries, scored for Kansas City
The eight industries sit in five Bureau of Labor Statistics lines that held 485,700 of the metro’s 1,178,000 nonfarm jobs in August 2026, about 41% of the total. Engineering and marketing share the professional, scientific and technical services line with law and accounting firms; logistics and utilities share one line; commodities and agribusiness has no separate metro line. For each industry I picked one fast use case, where the effect size comes from a field study wherever one exists, and one slow use case, where the outcome is rare or late.
The employer base explains why these eight matter here. Oracle Health runs the former Cerner campus, Children’s Mercy and the University of Kansas Health System anchor a large hospital sector, and H&R Block, UMB, Commerce Bank and the Federal Reserve Bank of Kansas City hold tax and financial records. Burns & McDonnell ranked seventh on ENR’s 2026 list of the top 500 U.S. design firms, and Black & Veatch is headquartered here too. Garmin, the Ford assembly plant in Claycomo and the Panasonic battery plant in De Soto are on the manufacturing side, BNSF’s intermodal park in Edgerton on the logistics side, and Evergy on the utility side, with grain, feed and food companies across the region on the agribusiness side.
National adoption already tracks the pattern this piece describes. In the Census Bureau’s Business Trends and Outlook Survey AI supplement (November 2025 to January 2026), 18% of firms used AI in the previous two weeks. The rate was 38% in information, 34% in professional, scientific and technical services and 30% in finance and insurance, while manufacturing was below average and transportation and warehousing much lower. Among firms using AI, sales and marketing was the most common function, at 52%. Adoption is highest where the work is text, the volume is high and the feedback is fast.
The effects marked as assumptions are mine, chosen to be conservative, and the volumes in the next section describe one mid-sized Kansas City organization in each industry. Swap in your own numbers; the code is built for it.
Where AI pays off first: high volume, fast feedback, cheap mistakes
Run the model for all sixteen use cases and the industry stops being the useful unit. Every fast use case can be proven in 2.3 months or less, and every slow one takes more than 21 months.
Months to prove each use case worked, under the inputs in the code below. Blue is the fast use case in each industry, grey the slow one. Proposed model with illustrative inputs.
The fast use cases share three traits. They happen thousands of times a month, the world grades them within days, and a wrong answer gets caught by a person before it costs much. Most of them are text work, which is also where the strongest field evidence sits.
Service work has the best evidence. Brynjolfsson, Li and Raymond followed 5,179 customer support agents as a generative AI assistant rolled out, and resolutions per hour rose 14% on average. The gain was 34% for novice and lower-skilled agents and minimal for the most experienced. For a Kansas City bank or insurer, that second number matters as much as the first: the payoff concentrates in onboarding, so a center with high turnover gains more than one with a veteran staff.
Writing work is close behind. In Noy and Zhang’s experiment in Science, 453 college-educated professionals using ChatGPT on occupation-specific writing tasks took 40% less time and produced work rated 18% higher in quality. That is the evidence base for content production at an agency, proposal sections at an engineering firm and contract summaries at a grain merchandiser. It is also why sales and marketing is the most common AI function in the Census data.
Knowledge work has a sharper edge. In the Harvard and BCG field experiment, 758 consultants using GPT-4 on tasks inside its abilities completed 12.2% more tasks, 25.1% faster, at more than 40% higher quality. On a task chosen to fall outside those abilities, they were 19 percentage points less likely to reach the correct answer than consultants without AI. For Burns & McDonnell or Black & Veatch, that pairs naturally with proposal and specification drafting, where a senior engineer reviews every page anyway. The review is the lag term L, and it is what keeps the cheap-mistakes condition true.
Clinical documentation is real but smaller than the marketing suggests. In UCLA Health’s randomized trial in NEJM AI, 238 physicians across 14 specialties and about 72,000 encounters were assigned to one of two ambient scribes or usual care. With Nabla, time in notes fell about 41 seconds per note, from 4:30 to 3:49, against 18 seconds for usual care, a reduction 9.5% larger than control. The DAX arm’s reduction was smaller and not statistically significant. Both tools improved burnout scores by about 7%. A health system can prove that kind of effect in about a month, which is exactly why it should test before it signs a system-wide contract.
The operational cases are fast to prove but not always fast to build. Route optimization is graded every evening when the trucks come back. UPS reports that its ORION system saves about 100 million miles and 10 million gallons of fuel a year, worth $300 million to $400 million, but it took 10 years and $250 million to build. A Kansas City distributor proving a purchased routing tool on 200 routes needs weeks; building ORION would need a decade. Day-ahead load forecasting is the extreme case: the past is the control group, so a utility with five years of history can score a new model against its current one in a backtest without waiting for new data. Google reported that DeepMind’s forecasts for 700 MW of wind farms, made 36 hours ahead, raised the value of that wind energy by roughly 20%, which is Google’s own measurement of its own system.
Here is the full set of inputs behind the chart. Volumes describe one mid-sized organization; the sepsis sample size comes from Episode 1 of my healthcare series.
"""payoff.py, part 2: sixteen use cases across eight industries (illustrative inputs)."""
CASES = [
# Finance and insurance: 100 agents; QA review settles in a week
UseCase("Finance and insurance", "Service and claims-intake assistant",
n_continuous(0.35, 0.14), rate=400, lag=0.25),
UseCase("Finance and insurance", "Credit and fraud loss model",
n_binary(0.03, 0.10), rate=2000, lag=12),
# Healthcare: 200 physicians; 30,000 admissions a year at 6% sepsis prevalence
UseCase("Healthcare", "Ambient documentation",
n_continuous(0.40, 0.095), rate=860, lag=0.25),
UseCase("Healthcare", "Sepsis alert, mortality",
1957, rate=150, lag=1),
# Engineering and architecture: senior review of every drafted section
UseCase("Engineering and architecture", "Proposal and spec drafting",
n_continuous(0.50, 0.251), rate=80, lag=0.5),
UseCase("Engineering and architecture", "AI design review, change orders",
n_continuous(1.0, 0.15), rate=20, lag=18),
# Marketing and advertising: 20 markets for the geo test
UseCase("Marketing and advertising", "Content production",
n_continuous(0.60, 0.40), rate=200, lag=0.1),
UseCase("Marketing and advertising", "Incremental revenue, geo test",
n_continuous(0.15, 0.02), rate=86, lag=1),
# Manufacturing: one line at 200,000 parts a month; 300 critical machines
UseCase("Manufacturing", "Visual defect inspection",
n_binary(0.01, 0.30), rate=200_000, lag=0.5),
UseCase("Manufacturing", "Predictive maintenance, downtime",
n_binary(0.02, 0.30), rate=300, lag=1),
# Transportation and logistics: 200 routes; 1,000 drivers
UseCase("Transportation and logistics", "Route optimization",
n_continuous(0.15, 0.05), rate=4400, lag=0.25),
UseCase("Transportation and logistics", "Driver-safety AI, crashes",
n_binary(0.005, 0.20), rate=1000, lag=1),
# Utilities and energy: five years of daily history; 20,000 monitored transformers
UseCase("Utilities and energy", "Day-ahead load forecast",
n_continuous(0.50, 0.10, paired=True), rate=30, lag=0, paired=True, history=1826),
UseCase("Utilities and energy", "Transformer failure prediction",
n_binary(0.0002, 0.30), rate=20_000, lag=1),
# Commodities and agribusiness: one winter a year; ten winters already backtested
UseCase("Commodities and agribusiness", "Contract and confirmation processing",
n_continuous(0.60, 0.25), rate=1500, lag=0.1),
UseCase("Commodities and agribusiness", "Winter price forecast vs. futures curve",
n_continuous(0.32, 0.10, paired=True), rate=1 / 12, lag=5, paired=True, history=10),
]
if __name__ == "__main__":
for c in CASES:
print(f"{c.industry:30s} {c.name:40s} units/arm {c.per_arm:9,.0f} "
f"proof in {c.months_to_proof():6.1f} months")The CVs and the assumed effects are the inputs to argue with. The structure is not: in every row, the fast case is fast because r is large and L is short, not because the model is better.
Where it pays off later: rare events, long lags and J-curves
The slow use cases are often the valuable ones. They are slow for one of four reasons, and each reason has a different fix.
The first reason is rare outcomes. A crash, a transformer failure and a default are the events these models exist to prevent, and their rarity is what makes them expensive to prove. A fleet where each driver has a 0.5% chance of a crash in a given month (an assumption) needs 70,318 driver-months per arm to detect a 20% reduction. With 1,000 drivers, that is 11.8 years. A utility monitoring 20,000 transformers that fail at 0.02% a month needs 741,153 transformer-months per arm to detect a 30% reduction, which takes 6.3 years. Neither model is a bad idea. Neither can be proven by one Kansas City organization on its own data inside a budget cycle, so the honest plan pools data across fleets or utilities, or proves a leading indicator first: harsh-braking events per thousand miles, or the share of flagged transformers that inspectors confirm are degraded.
The second reason is lag. A credit model waits 12 months for defaults to mature, and it needs 48,289 accounts per arm on top of that, so a lender originating 2,000 accounts a month needs about 5.0 years. AI design review at an engineering firm is judged on change orders that show up during construction, 18 months or more after the drawings. At 20 projects a month and a 15% target reduction, the test runs 7.3 years. In both cases the faster path is to grade the model against outcomes already on the books, as a backtest, before any prospective test.
The third reason is that some AI makes things worse before it makes them better. McElheran, Yang, Kroff and Brynjolfsson linked Census data on about 28,500 U.S. manufacturing plants and found that about 23% used some form of AI by 2021 and about 8% used it in production. Their causal estimates show J-curve returns: industrial AI adoption lowers productivity and profits in the short run, with work-in-progress inventory rising, before longer-term gains arrive. The losses concentrate in establishments at least 25 years old, and the authors attribute roughly a third of the loss at those plants to dropping structured management practices such as KPI reviews and production targets. Younger firms, firms pursuing growth strategies and early adopters fared better. For a Kansas City plant, that means predictive maintenance has a 4.2-year proof window in the model and may show a dip inside it. Keeping the existing management system running while the AI comes in is the cheapest insurance available.
The fourth reason is forecasting against an efficient benchmark, and here I can use my own numbers. In my natural gas piece, machine learning lost to the futures curve at every horizon from 1 to 4 months, by 2.5% to 12%. My PyCausalSim simulation cut the average winter miss from 28.7% to 22.3% over ten winters, with a paired t-statistic of about 2.2, and a simple correction for the curve’s winter premium did as well. That result implies a coefficient of variation of about 0.32 for the per-winter difference in error (0.223 × √10 / 2.2). A model 10% better than the curve would need 7.85 × (0.32 / 0.10)² = 80 winters to prove, and with ten already backtested, the wait is about 71 years. For a commodity desk, the payoff from AI comes from ranges, scenarios and decisions made against a stated risk limit, such as hedging to a budget ceiling, and from the confirmations and contracts on the operations side, not from beating the curve.
Marketing sits in between. Content production proves itself in under a month. Whether the extra content sells anything is a 2% lift in revenue per market-week, and a 20-market geo experiment needs about 22 months to see it. That is why the measurement layer, from geo tests to the marketing mix models I covered in the CMO guide, decides whether a marketing AI budget survives its second year.
Proving enterprise AI ROI: time saved is not money saved
A fast proof shows that a use case works. It does not show that the company makes money from it. Two studies explain the gap, and every Kansas City budget owner should know both.
The first is about capture. Humlum and Vestergaard linked surveys of about 25,000 workers at 7,000 Danish workplaces, in 11 occupations exposed to AI, to national employer-employee records. Users said AI chatbots saved them about 2.8% of their work hours. Across the 2023 and 2024 survey waves, the authors found no significant effect on earnings or recorded hours in any occupation, with confidence intervals ruling out effects larger than 1%, and estimated that only 3% to 7% of the time saved showed up in earnings. Saved minutes turn into money only when someone decides what to do with them: absorb volume growth without hiring, cut overtime, shorten a backlog or move people to work that was not getting done.
The second is about perception. METR ran a randomized trial with 16 experienced open-source developers working in their own repositories. Before the study they expected AI tools to make them 24% faster. Afterward they believed they had been 20% faster. Measured against the randomized control, they took 19% longer. A pilot judged by a satisfaction survey can report a gain that does not exist. Time to proof only means something if the proof comes from measured outcomes against a control group.
Put capture into the payback arithmetic and the service center example gets more honest:
P = 12 × F / (k × g × W − C)
P is the payback in months. F is the one-time cost to integrate and train, g is the productivity gain, W is the annual wage bill of the people affected, C is the annual run cost and k is the capture rate, the share of the gain the business actually turns into money. For the 100-agent center, take W = $5.5 million (100 agents at a $55,000 loaded cost, an assumption), g = 14% from the field evidence, F = $250,000 and C = $60,000 a year, which is about $50 a seat a month (both assumptions). With full capture, P is 4.2 months. At k = 0.5 it is 9.2 months, and at k = 0.25 it is 22.6 months. The model did not change across those three cases. The management plan did.
"""payoff.py, part 3: payback once you account for how much of the gain is captured."""
def payback_months(fixed: float, wage_bill: float, gain: float, capture: float, run_cost: float) -> float:
"""P = 12 x F / (k x g x W - C): months to recover a one-time cost F from annual savings."""
net = capture * gain * wage_bill - run_cost
return float("inf") if net <= 0 else 12 * fixed / net
if __name__ == "__main__":
for k in (1.0, 0.5, 0.25):
p = payback_months(fixed=250_000, wage_bill=100 * 55_000, gain=0.14, capture=k, run_cost=60_000)
print(f"capture {k:.2f}: payback {p:.1f} months")The design that produces a believable number is not complicated. Randomize by team or site rather than by person, so agents do not share the tool with the control group. If the business insists everyone gets the tool, stagger the rollout so later teams serve as the control for earlier ones. Name the outcome metric and the capture plan before the pilot starts, keep a small holdout after it ends, and report the result as a range rather than a point. I will cover the full design, with difference-in-differences code, in How to Measure Whether Your AI Pilot Worked on November 12.
Where the ranking breaks
The model is mine and the inputs are illustrations. The structure (volume, lag, noise, history) is standard statistics, but every CV and most of the volumes are assumptions chosen to describe one plausible organization, and the effects marked as assumptions have no field study behind them. Change them and the months change. What should not change is the ordering within each industry.
The formulas assume independent units, and real pilots do not have them. Weeks from the same agent or notes from the same physician are correlated, so the effective sample is smaller. The usual correction multiplies the sample by a design effect of 1 + (m − 1) × ICC, where m is the number of units per person and ICC is the share of variation that sits between people. With four weeks per agent and an ICC of 0.5, the factor is 2.5, and the service center’s time to proof rises from 1.0 to about 1.7 months. Randomizing by team makes the correction larger still. Treat every number in the chart as a lower bound.
The field evidence comes from other places. The support study ran at one large software company, the writing experiment used assigned tasks rather than real jobs, the consultants worked for one firm, and the UCLA trial ran at one academic center over about three months. Each is the best evidence available for its use case, and none was run in Kansas City. Early effects can also fade as novelty wears off, or grow as people learn the tool, and a one-month test cannot tell which.
Time to proof is not value. Sepsis alerts take 27 months to prove on mortality and may matter more than every fast use case in the table combined. A fast use case is the right first budget because it builds the data pipelines, the measurement habits and the trust that slow use cases need. It is not a reason to skip the slow ones.
Tests also fail in both directions. At 80% power, one real effect in five goes undetected. A company that runs twenty pilots at 5% significance should expect about one false positive even if nothing works. Pre-registering the outcome metric, as in the section above, is what keeps the second problem small.
Finally, the job counts are preliminary for the latest months, not seasonally adjusted, and the BLS lines are broader than the industries. The professional services line includes law, accounting and consulting, and the transportation line includes warehousing. Use them for scale, not for precision.
What Kansas City executives and hiring managers can do this quarter
Start by listing every AI idea on the table and estimating four numbers for each: how many times a month the decision happens, how long until you know whether it was right, how rare the outcome is, and how much history you already have. Run them through the code above. Most portfolios split cleanly into proofs that take weeks and proofs that take years, and the first budget belongs to the first group.
Pick one fast use case and run it as an experiment. Randomize by team, name the metric before you start, and decide in advance what happens to the saved hours. The service center example says the capture plan is worth as much as the model: the same tool pays back in 4.2 months or 22.6 depending on it.
For each slow use case, find the leading indicator you can prove this year. Confirmed degraded transformers, harsh-braking events, issues caught per design review hour and forecast calibration can all be measured long before failures, crashes, change orders or a winter’s price. Where the outcome is too rare for one organization, look for partners. Kansas City has enough hospitals, fleets, lenders and utilities that a pooled test is realistic, and it is the only way most of the slow cases in the chart get proven at all.
For hiring managers, the model says something specific about who to hire first. The fast use cases need people who can instrument a workflow, randomize a rollout and read a confidence interval, more than people who can train a frontier model. The field evidence also says the biggest gains go to newer workers, so the payoff from AI shows up in onboarding speed and in how quickly a junior analyst, agent or engineer reaches full productivity. A team that measures both will know within a quarter whether its AI budget is working.
If you run these numbers on your own portfolio, I would like to hear which use cases land where. Kansas City does not need to wait for anyone else to find out where AI pays off first. Its employers produce enough decisions a month to prove it here.
About the Author
Brian James Curry is an applied econometrician, AI researcher, and founder of Vector1 Research. His work focuses on causal inference, structural simulation, and high-dimensional measurement in complex enterprise systems. Drawing on more than two decades leading data science and analytics initiatives across organizations such as Koch Industries, Tractor Supply Company, and Hallmark, he develops open-source frameworks (including Papilon and PyCausalSim) that bridge econometrics and modern machine learning. He is also the founder of KC AI Lab, an applied AI and ML community of over 1,500 practitioners. An alumnus of Kansas State University, Brian writes on the mathematical boundaries of observational inference, generative economics, and agentic system architecture. Contact: brian@vector1.ai.
Sources
- U.S. Bureau of Labor Statistics, Kansas City, MO-KS economy at a glance, nonfarm employment by supersector, 2026.
- Federal Reserve Bank of St. Louis, FRED, Kansas City MSA employment: health care and social assistance, finance and insurance, professional, scientific and technical services and transportation, warehousing and utilities, 2026.
- Bonney K, Breaux C, Dinlersoz E, Foster L, Haltiwanger J, Pande A. The Microstructure of AI Diffusion: Evidence from Firms, Business Functions, and Worker Tasks. U.S. Census Bureau, CES 26–25, 2026.
- U.S. Census Bureau, Large Firms With at Least 20 Employees Biggest AI Users, 2026.
- Brynjolfsson E, Li D, Raymond LR. Generative AI at Work. Quarterly Journal of Economics, 2025.
- Noy S, Zhang W. Experimental evidence on the productivity effects of generative artificial intelligence. Science, 2023.
- Dell’Acqua F, McFowland E, Mollick ER, et al. Navigating the Jagged Technological Frontier. Harvard Business School Working Paper 24–013, 2023 (summary with abstract).
- UCLA Health, UCLA study finds AI scribes may reduce documentation time and improve physician well-being, on Ambient AI Scribes in Clinical Practice: A Randomized Trial, NEJM AI, 2025.
- INFORMS, UPS ORION and the 2016 Franz Edelman Award, OR/MS Today, 2016.
- Google DeepMind, Machine learning can boost the value of wind energy, 2019 (the company’s own measurement).
- McElheran K, Yang MJ, Kroff Z, Brynjolfsson E. The Rise of Industrial AI in America: Microfoundations of the Productivity J-curve(s), 2025; also Census CES working paper 25–27.
- Humlum A, Vestergaard E. Large Language Models, Small Labor Market Effects. Becker Friedman Institute Working Paper 2025–56, 2025.
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025, summary by Simon Willison.
- Burns & McDonnell, Burns & McDonnell maintains top 10 position on ENR’s Top 500 Design Firms list, 2026.
- Mid-America Freight Coalition, BNSF Logistics Park Kansas City.
- Curry B. The Future of AI in Kansas City; How to Use PyCausalSim to Improve LNG and Natural Gas Forecasting; and How AI and ML Will Save Lives in Healthcare, Episode 1. Vector1 Research, October 2026, for the employer list, the natural gas backtest and the sepsis sample size.
