Verifiable Intelligence Is Splitting From Product Reliability

The strongest August 7 signal came from Digg AI clustering around the awkward contrast between systems that can solve open mathematical problems and systems that still miss simple operating instructions. The primary capability proof is OpenAI’s August 1 publication of ten advances in mathematics and theoretical computer science, where model work is valuable precisely because the outputs can be checked, formalized, and reviewed. The operator lesson is different. Simon Willison’s running commentary this week keeps pointing toward harness quality, long-sequence tool use, and eval design as the practical determinants of shipped performance. The useful synthesis for product builders is that frontier intelligence is advancing fastest in domains with strong verifiers, while day-to-day product reliability still depends on workflow design, not just model prestige.

Teams still collapse these dimensions into one vague judgment about whether a model is “good.” That leads to bad shipping decisions: paying frontier prices for workflows that mostly need discipline, trusting research-grade capability where escalation judgment matters more, and letting agent loops declare success without satisfying local rules. Builders who keep capability and operational reliability separate will make better routing, pricing, and safety decisions than teams that confuse a benchmark leap with a production readiness signal.

Split one AI workflow into two eval tracks. Trigger: the workflow mixes nontrivial reasoning with strict local rules, such as coding agents, analyst copilots, support drafting, or research loops. Context: define which steps need search or abstraction, which require obedience to instructions or policy, and which failures are expensive. Tools: keep one benchmark for capability, such as task completion or verifier pass rate, and a separate benchmark for operational behavior, such as tool discipline, formatting, escalation, and policy compliance. Verifier: use an external checker for the hard task and a separate checklist or policy eval for reliability. Budget: assign different model and runtime ceilings to the two tracks, because the best reasoner is often not the cheapest dependable operator. Artifacts: keep a dual-score eval sheet, traces of accepted and failed runs, routing rules, and examples of when the workflow must escalate. Stop condition: trust the workflow only when it clears both tracks at an operating cost you can sustain.