PodBrowser
Practical AI

Abundant Intelligence at the Midwest AI Summit

Thursday, 29 October 2026 · 4 min read · Listen to the episode ↗

At the second annual Midwest AI Summit, speakers argue that abundant intelligence means choosing the right tool for each task—not defaulting to an LLM—and grounding AI in reliable data, evaluations, and enforceable controls. They explore how human review and worker feedback improve systems in manufacturing, healthcare, and field service, and why AI amplifies a team’s existing strengths and weaknesses. The discussion also weighs autonomy against verification, especially when mistakes carry serious consequences.

At the second annual Midwest AI Summit, speakers argued that reliable AI depends less on asking a large language model to do everything than on matching each task to the right tool and building ways to verify the result. Heidi Porter said teams should choose among rules, classical machine learning, decision models, and LLMs according to the task. Data quality sets the ceiling: systems must provide accurate, complete, consistent information suited to the work. LLMs can retrieve facts from systems of record at runtime and cite evidence, but grounding cannot compensate for poor underlying data.

Porter distinguished three kinds of control: runtime guardrails, repeatable evaluations, and observability. Guardrails require enforceable mechanisms such as gates, code limits, or human approvals; prompt instructions alone do not enforce rules. Evaluations test answers and outcomes, while observability helps detect drift and recover. Average scores can hide severe failures, so controls should reflect the consequences of an error. Teams can use fixed workflows for known steps, models to choose among branches, or bounded agents. They should require approval for consequential actions, set thresholds and escalation paths for uncertain work, and make actions reversible where possible—especially when errors could otherwise be irreversible.

Her production and healthcare examples showed different ways to keep people accountable. In a 52-week rubber-hose study, a camera and modified YOLO model detected defects; the LLM did not inspect the hose. It retrieved relevant procedures and maintenance history, then drafted explanations and corrective actions. Rule-based checks compared drafts with evidence, unsupported cases went to a person, and operators could accept, overwrite, or comment. Porter said results were good but imperfect, making checks on grounded answers necessary. At Syngenta, CropWise AI supports on-site seed selection: identity services and application code authorize users before the LLM is involved, while existing seed and agronomy models make predictions. The LLM acts as interface, router, and explainer; growers or sales representatives decide. Stanford Health Care’s Surgical Co-Management Navigator screens next-day elective surgeries against an institution-owned rubric and returns “yes,” “maybe,” or “no,” leaving physicians free to confirm, decline, or override. Stanford selected O3 mini after comparing five models with consensus chart review. Physicians agreed with 97% of “no” decisions but declined about four in ten flagged patients as insufficiently complex. The system tended to overflag; a small false-negative review found minimal LLM errors and surfaced other process errors.

For tools used by blue-collar workers, Kevin Solorio urged teams to build with workers rather than rely on a product-owner proxy. Field technicians repairing equipment from meat grinders to ATMs may reject tools that are slow, crash, miss their needs, or make them move information among several systems. Their expertise is also essential to evaluate whether an agent gives correct answers, uses the right tools, and respects boundaries. Solorio considers an agent without evaluations a proof of concept, since expected behavior cannot be confirmed. He recommended representative, curated test sets and an ongoing review loop: score sampled traces, inspect and annotate flagged cases, and add findings to offline evaluations. Direct conversations matter when work traces are scarce and cases vary widely. Starting with an imperfect proposal and showing how feedback changes the tool can build trust and turn contributors into champions.

Chris Schenkel said three recent studies, including a 2025 DORA report, support the view that AI amplifies a team’s existing strengths and weaknesses rather than fixing how it works. Adoption therefore needs to fit the team and its setting, particularly in regulated fields such as healthcare, pharma, and aerospace. Andrew Dunlap identified six constraints on an AI working mode: token budget, organizational readiness, goal definition, domain knowledge, verifiability, and code oversight. When expertise exists mainly in people’s heads, agents may need subject-matter experts; limited tokens can also cap how much work they can do. At a transmission operator, an engineer used agents to reverse-engineer a legacy model-conversion process and produce a working prototype in two days, but the token budget allowed only a couple of days’ work. The approach was hard to scale: a person could verify the prototype more readily than a production system with millions of input parameters.

Other projects illustrated why greater autonomy is not always the goal. For software used to design building components, the team established shared domain knowledge, architecture, workflows, and coding rules, but did not pursue more agent autonomy because verification mattered and failures could have serious consequences. In a mobile-banking project, Form moved a working C# app toward native iOS and Android, with agents taking roles and coordinating through an orchestrator; the higher-autonomy approach was associated with a sixfold reduction in effort. Dunlap’s broader guidance was to choose a mode that fits the constraints: more constraints favor a more individualistic approach, while fewer may support greater autonomy, rather than assuming every team should become a “dark factory.”

Across teams with different working modes, the closing practices were to build shared infrastructure, iterate deliberately, verify before optimizing for speed, address bottlenecks, and remove toil. Teams should first establish that they get the right answer, then improve velocity, and revisit practices as scale or constraints change. As teams improve, review can become a more prominent bottleneck. Automating repeated tasks can save time and tokens, leaving people to exercise judgment and LLMs to handle analytical work. The comparison to lean practice underscored that principles can travel across teams while specific practices depend on the situation.

This summary was generated from the episode transcript and can contain mistakes.