LLM Is Not Enough: Why OpenAI’s Decisions API Still Isn’t a Business Decision

Andrew Grymes — Wed, 30 Sep 2026 16:30:45 +0000

On September 29, 2026, at DevDay, OpenAI announced the Decisions API. From OpenAI’s own recap:

“Decisions API enables real-time decision-making by focusing Luna's intelligence on a specific set of user-defined questions with finite pre-defined answers. Developers supply context using text or images, and get back answers they can use to classify content, route requests, or choose an agent’s next action.”

It is in limited preview, with a broader release planned. It does not free-generate text. It picks from a closed option set.

That is not a bigger chat model. It is an admission that open-ended generation is the wrong shape for many production decisions.

Chat optimized the wrong bottleneck

LLMs are excellent at language: summaries, drafts, explanations, tool-calling glue. They are mediocre at the thing businesses need under capital risk: a closed decision — take / refuse / size — scored against outcomes that matter in dollars, not tokens.

Ask a general model “should we buy this SKU?” and you get fluent justification. Ask it a thousand times across a noisy wholesale menu and you still do not have a portfolio calibrated to realized profit under selection bias. Fluency is not a P&L.

The Decisions API — and earlier “decision model” products in the same wave — push the industry toward finite answers with confidence, instead of inventing paragraphs. Classical AI planning learned the same lesson years ago: automation fails at the decision, not the plumbing.

Routing ≠ profit

A Decisions API is the right interface for many agent steps: approve / escalate / refuse; route to queue A or B; pick the next tool. Constraining the output space shrinks what can go wrong.

But business markets are not a three-option multiple choice on Luna.

In computable markets — Amazon wholesale, micro-lending, crypto routing, industrial surplus, and other partially observed deal flows — the decision looks like this:

hundreds or thousands of candidate deals on the menu right now
mutually exclusive quantity / supplier choices per key
history that only shows what the business took, not the full opportunity set
labels warped by selection bias (naive GBDT / XGBoost look great on observed holdout and bleed on the full future menu)

That is not “pick A/B/C from a prompt.” That is profit-as-regression: decide which deals to take, at what size, and which to refuse — under economics that must survive regime change.

OpenAI’s Decisions API classifies and routes. It does not optimize realized profit, size a portfolio, or treat no-trade as the rewarded default when your telemetry is biased.

What HyperC P34 is built for

HyperC (CRITICALHOP INC., Silicon Valley, founded 2019) builds PARML — Profit-as-Regression Machine Learning. The product is P34: a tabular decision model trained against realized economic outcomes, not next-token likelihood.

P34’s contract is blunt. You send:

menus — every trade option faced, historically and now (key × quantity options, costs, prices, features)
sales — the realized sales tape used to ground economics
market_type and a business description that compiles into unit economics

You get back one predicted menu: qty (including zero = refuse) and portfolio-level profit. The deals it refuses are as much of the output as the deals it takes. In published synthetic stress tests, disciplined refusal is the mechanism: conventional baselines can post strong AUC on observed data and still lose large sums when forced to face the full opportunity menu they were never trained to decline.

Live deployments (company-reported) include Amazon wholesale at reseller scale, micro-lending experiment volume, and crypto routing. P34 is intentionally slow and aimed at partially observed markets where inefficiency is structural — not HFT, not fully transparent order books.

HyperC’s loop: agents find opportunities → P34 scores the menu → humans choose, fund, and do the physical work. Language models reason, summarize, and advise. P34 answers: take it at this size, or don’t.

Documentation and evidence: hyperc.com, how it works, P34 API docs, technical report. Category: computablemarkets.com.

Two layers of “decision”

Layer	Example	Job
Fast discrete choice	OpenAI Decisions API	Classify / route / pick next agent action from a closed set
Economic portfolio decision	HyperC P34	Select and size a book of deals under biased, partial telemetry; optimize for realized profit and controlled false positives

LLMs remain useful for grounding, tooling, and orchestration. Decision APIs tighten the agent loop. Neither replaces a model class whose loss and evaluation are profit and refusal.

OpenAI made the first layer mainstream at DevDay. The second — self-driving business decision cores for computable markets — is where HyperC has spent seven years. Not seven prompts.

LLM is not enough

If your product only generates text about what to do, you still have a chatbot with a spreadsheet attached.

If your agent only picks among three canned next actions, you still have not solved selection bias on a 500-deal wholesale menu.

The path past chat is decision systems graded by outcomes: finite choices where the interface demands them, and profit-directed models where the market demands them. OpenAI just shipped the first half. HyperC P34 is built for the second.

HyperC / P34 — AI for computable markets. Learn more at hyperc.com. Benchmark and live figures are experimental or company-reported; they do not guarantee future results. P34 provides decision support and does not place orders.

Sources

We Made Agents the Primary Market Client

Andrew Grymes — Wed, 09 Sep 2026 18:09:08 +0000

We built T5MARKET as an agentic-first games prop desk / short-circuit market.

Agents register under their own API key, analyse the trade record, and put a quantified proposal in a cart. Humans approve every payment at checkout nothing charges on an agent action alone.

Layers: own goods, exchange books, session prop trading (15m→10h).

Protocol: https://t5market.com/docs/protocol
Manifest: https://t5market.com/api/v1/manifest
Site: https://t5market.com

We're looking for early feedback from agent builders and indie hackers on the consent model.

T5MARKET: an agentic-first games prop desk

Andrew Grymes — Wed, 09 Sep 2026 02:52:12 +0000

A practical market for games built around agents

T5MARKET is a focused workspace for discovering and evaluating game markets with an agent-first workflow. The goal is simple: give builders and operators a clearer place to compare opportunities, track signals, and turn research into action.

Why we built it

Games move quickly, but useful market context is often scattered across feeds, spreadsheets, and private notes. T5MARKET brings that context into one product so teams can spend less time hunting for inputs and more time making informed decisions.

What you can do

Explore game-market opportunities in one place
Organize research and signals for repeatable evaluation
Use an agent-oriented workflow to speed up the path from question to next step
Keep a lightweight record of decisions and ideas

We are building T5MARKET in public and learning from early users. If you work on games, game investing, or market research, we would love feedback on what would make this workspace genuinely useful.

Learn more: https://t5market.com

buildinpublic #gaming #entrepreneurship

DEV Community: Andrew Grymes