What actually happened: frontier reasoning in a tight loop
A researcher at a biotech firm had chased a protein-immune pathway mechanism for three years. GPT-5 Pro proposed a mechanism that turned out to be right. That's real, and it's worth understanding exactly why it worked — because the setup was nothing like the vague "throw a frontier model at hard problems" narrative that spreads.
The model didn't autonomously discover anything. A researcher fed it structured inputs: known immune pathways, prior literature, candidate molecules, and negative results from earlier experiments. GPT-5 Pro combined those constraints to propose a novel mechanism that the researcher then evaluated and validated. The model did the combinatorial reasoning — holding dozens of pathway interactions in working memory at once — that a human couldn't sustain. But the expert stayed in the loop. Each hypothesis took minutes to verify or refute.
This matters because the real pattern is not "frontier models are better at science." It's "a frontier model solved one well-bounded reasoning step inside a human-guided workflow."
The four preconditions that made this work
Every frontier reasoning success we've shipped shares the same shape. First: the hypothesis space is bounded. Not infinite — thousands of candidates, not millions. Second: verification is fast and cheap. An expert or a simulator scores each hypothesis in minutes, not days. Third: the prompt carries high-quality structured priors. Papers, schemas, prior negatives — the model isn't guessing; it's recombining known pieces under new constraints. Fourth: the cost of being wrong is low. A bad hypothesis wastes a meeting, not a deploy.
The immunology case hits all four. The coding-agent case that's spreading through enterprise now — code generation with test feedback — hits all four too. Bounded edits, fast test loop, high-quality priors (the existing codebase), human review, low blast radius. The pattern repeats because these conditions are rare.
Why most domain problems fail at least one test
Support automation hits a wall at condition one: action space explodes. A customer service loop might need to handle refunds, refunds plus shipping labels, partial credits, account changes — suddenly you have millions of outcome combinations. Verification balloons too. The customer decides if the answer was right, not a test suite or a scientist.
Ops workflows fail on visibility: the Amazing Digital Dentures pattern shows agents bolted onto supply chains they didn't own. Domain context lives in systems the model can't see — legacy databases, paper forms, slack channels. You can't reason about what you can't retrieve.
Regulated domains flip the cost calculation. Cost-of-wrong becomes "audit failure" or "patient harm." Expert review stops scaling at 100 decisions per day. If you can't write the verifier in a weekend, you don't have the immunology setup.
The cheaper default: guided workflow with routed inference
For the 80% of problems that don't fit those four conditions, the pattern is different. Start with a deterministic workflow shell — n8n, Temporal, or Postgres plus Redis if you're rolling your own. Layer in retrieval over your structured domain data: not just vector search, but SQL plus hybrid, so the model sees what actually matters.
Use GPT-4o-mini, Claude Haiku, or Llama for per-step inference on the hot path. Reserve the frontier model for the one junction that actually needs it — and lock it behind a budget cap. RAG fails in production when retrieval is the bottleneck, not the model. Throwing a bigger model at a retrieval problem burns money for nothing.
The infra gets boring: retries with exponential backoff, idempotency keys, dead-letter queues. The immunology demo didn't need these because it ran once, with a human watching. You do. Cost math: a guided workflow runs at $0.002 per call on a smaller model. A frontier reasoning loop over the same dataset costs $0.40 per call. At 100k requests per day, that's $40k daily versus $200 daily. Latency: the workflow hits 2s p95 for interactive work, 30s for batch. Frontier reasoning loops blow both.
A decision rule for Monday morning
Ask yourself five questions. Can you enumerate fewer than 10,000 candidate answers? If no, frontier reasoning isn't viable — the search space is too large. Can a human or test verify an answer in under five minutes? If no, the feedback loop is too expensive. Do you have structured priors that fit in 200k tokens? If no, you're prompt-engineering blind; fine-tuning won't save you either. Is the failure mode "wasted meeting" or "wrong production write"? This one changes everything. If it's the latter, frontier reasoning is too risky without heavy safety infra.
If any answer is no, build the workflow. Use the frontier model only on the one step that genuinely requires it. If retrieval is your bottleneck, no model upgrade fixes it.
How we'd ship this in your stack
For an immunology-shaped problem, we'd build a thin orchestration layer that fans out candidate hypotheses to a small queue. GPT-5 Pro sits behind that queue, reasoning over batches, with a hard budget cap — maybe $100 per run. Structured logging captures every (hypothesis, evidence, verdict) tuple; that becomes your eval set and your prod audit trail. Human-in-the-loop UI for the expert review. No pretense of autonomy.
The workflow around it runs on cheaper models and fast deterministic steps. When to build an agent vs. a workflow breaks down the cost and maintenance differences. Most teams should start there before they touch a frontier model.
Find your one bounded step
The immunology story isn't "frontier models can do science now." It's "a researcher with the right setup got 10x leverage from one well-shaped prompt." Find the one bounded, verifiable step in your pipeline that fits that shape. Build the cheap workflow around it. If you're staring at a problem and can't tell which side of the line it falls on, we've written about right-sizing your reasoning loop — or get in touch for a second pair of eyes before you commit to an agentic loop.