Practical use cases
Four practical ways to put an AI decision model to work.
A language model writes. A decision model chooses: you give it a situation and a multiple-choice question, and it answers with a probability. Because it is fast and cheap, you can run it on every action, click, or frame.
The pattern that works best is a sandwich: a language model prepares the situation, a decision model decides, and a language model acts on the result. Here are four places that pattern pays off in AI coding and business workflows.
Security guardrails for coding agents
The decision: Before an agent runs a command or reads a file, ask yes/no questions: does this expose secrets, destroy data, send sensitive data out, or drift off task? Block it if the answer is yes.
Where a language model still fits: Writing the safe alternative. When an action is blocked, the agent has to find another route, such as reading an example config instead of the real one.
Pattern matching misses many ways to do the same thing and blocks harmless text. Asking a language model every time is slower and costs more as calls add up. In early tests shown in Chhavi’s walkthrough, a decision model blocked nearly all risky calls with few false positives in about a quarter of a second per check. Treat that as a promising early result, not an independent benchmark.
Gameplay testing
The decision: At 30 or 60 frames per second, choose the next move from the state of the game: attack, dodge, move.
Where a language model still fits: Building the harness that turns game state into the model’s input and defines the moves, then acting on the bugs the run uncovers.
A language model is too slow to react in real time, so the scene has moved on before it answers. A decision model keeps up, so the game can be played the way a user would play it. The same idea applies to any application that needs snap decisions.
Browser testing
The decision: On a web page, choose what to focus on and which button or field to use next.
Where a language model still fits: Anything that needs free-form text, such as the message typed into a chat box. Pre-generate it with a language model and let the decision model drive everything else.
Tools like Playwright and agent browsers already let a language model test a site. Decision-model versions keep the same idea while being faster and cheaper per step. You can run the finished test and have a language model review the log for bugs.
Workflow classification
The decision: At the start of a workflow, classify the incoming work: is this GitHub issue a bug to investigate or a feature to plan? Does it need a fast, standard, or strong model? Does this pull request need a full architecture review or a quick check?
Where a language model still fits: Doing the actual work with the model tier and steps the classifier picked.
This keeps a workflow dynamic without a person making the same call each time, and avoids sending easy work to the most expensive model. In tests shown in Chhavi’s walkthrough, the classifier agreed with a human reviewer on 12 of 12 issue runs and 15 of 16 pull-request runs. Again, an early result, not an independent benchmark.
Practice the pattern at the workshop.
In the October 25 AI workshop you decide where an agent can act on its own, where it must ask, and where it should stop. That is the same judgment these use cases rely on. Try a small version in the “Would you let it send?” challenge.
From Chhavi Jain’s video walkthrough of practical decision-model use cases in AI coding workflows. The figures above are early test results from that walkthrough, not independent benchmarks; test them on your own workflow before relying on them.