Name the decisions before you buy the classifier.

A cheap classifier is still a policy decision

OpenAI put a limited-preview Decisions API into the world for fast, bounded classification—outputs locked to a predetermined set of choices, not open-ended prose. Think allow / flag / block for software automation and agent supervision. TypeSafe's Jev and other "System One" decision models are pushing the same shape: small, fast calls that pick from a labeled set instead of narrating a paragraph.

That is useful. It is also where teams get lazy.

Someone sees a vendor demo where a classifier sorts actions in milliseconds. The slide says the gate is cheaper than a full generative pass. Fine—vendors will always show you a cheap classifier demo. Treat the demo cost as marketing, not as your measured bill. What the demo does not show is who named the labels, who owns the threshold, and what the agent is allowed to do while a human stares at the flag queue.

If you wire the API before you write the decision set, you did not buy a gate. You bought a lottery ticket with three buckets and no policy.

This note is a walk-through. You fill a TWIMCO Agent Decision Set Card for one agent job that can change money, inventory, PII, access, or ERP state. The card is the unreproducible asset: your labels, your thresholds, your owners, your ambiguity rule. The model merely scores against it.

When that work is how you are putting agents into real systems, start from AI applications & agents.

What a Decision Set Card forces you to name

Fill one card per agent job that proposes an action the business must either allow, hold, or refuse. Not one card for "all AI." One job. One sink class.

Decision labels. The closed set the classifier may emit. Start simple: allow, flag, block. Add a fourth only when you can define it without overlapping the other three. "Maybe" is not a label—it is why you have a flag band.

Meaning. One plain sentence per label. Allow means the agent may execute the proposed action under the scopes already granted. Flag means a named human must decide before execution. Block means refuse, log, and do not silently retry as allow.

Auto-ok threshold. The confidence (or score band) at which allow may fire without a person. Write the number and the fixture you will use to defend it. If you cannot name a fixture pack, you do not have a threshold—you have a hope.

Flag band. The range that must queue. Include what "confidence" means in your stack (model score, calibrated probability, rule overlay). Vague "medium risk" fails the card.

Block rule. Hard fails that never auto-ok—even at high model confidence. Examples: policy-exception refunds above a dollar ceiling, vendor bank-detail changes, exporting a full customer list, disabling audit logging. The block rule is yours; the model does not invent it.

Human owner. The role who edits labels and thresholds, who owns the flag queue SLA, and who gets paged when block volume spikes. A shared Slack channel is not an owner.

Audit field. The join keys: agent id → proposed action → classifier label + score → human decision (if any) → downstream record id. If you cannot join those, "we use a Decisions API" is a slide, not a control.

What the agent may do while waiting. When the label is flag, may it hold a soft lock, send a customer a "in review" note, or must it do nothing? Write it. Ambiguity during wait is how double-charges and duplicate tickets happen.

That field set is the point. Another lab can ship a bounded classifier. They do not have your labels tied to your sinks and owners.

Walk through: fill the card for one live gate

Pick a job you already want to automate or supervise—draft a purchase order, reopen a ticket with a credit, adjust a stock level, change a ship-to.

1. List the actions the agent may propose. Verbs and objects: create_po, issue_credit, adjust_qty. If the list is "whatever the model thinks," stop. The decision set cannot supervise an unbounded action space.
2. Map each action to a default label if the classifier were offline. That default is your safety floor. Many teams default to flag for money and block for identity or bank changes.
3. Write allow / flag / block meanings in the language ops already uses. Do not invent a parallel vocabulary the night shift will ignore.
4. Set the auto-ok threshold only after you have fixtures. Ten to thirty anonymized historical cases with the label a senior operator would have chosen. Run the classifier. Adjust the threshold until false allows are rare enough that a named owner will sign. Do not set the threshold from a vendor slide.
5. Name the flag owner and the wait behavior. Who clears the queue in business hours? After hours? What does the customer or downstream system see while the ticket sits?
6. Name the block rule and the audit join. One drill: force a block, confirm the sink did not fire, confirm the log joins.

You are not done when the API key works. You are done when a skeptical operator can read the card and predict what happens on an ambiguous case.

The same discipline shows up when a platform must keep claims, checks, and decisions distinct on a shared record—as in Sutton|Place, where disclosure and judgment stay explicit actions with an actor and a timestamp. An agent gate that can allow, flag, or block needs that same accountability, not a slide about latency.

How teams fake a decision gate

Composites—not measured error rates, not a client scorecard.

The three buckets with no meanings. Allow / flag / block exist in the schema. Nobody wrote what allow authorizes for this agent. Operators invent meanings under load.

The threshold from the demo. A vendor showed a cheap classifier run. Your team copied a confidence cutoff without fixtures. False allows show up in production first.

The flag queue that is also the backlog. Everything "uncertain" lands on the same humans who already drown in exceptions. They rubber-stamp. The gate becomes theater.

The model as policy author. Someone asks the generative model to "decide if this refund is OK" with no closed label set, then wraps the prose in a regex. That is not a Decisions API pattern. That is open-ended judgment with extra steps.

The silent label drift. Product adds a fourth label mid-pilot. The card, the fixtures, and the owner's understanding stay on three. The runtime emits a value nobody handles.

When you see these, do not add another system-prompt sticky note about "being careful." Fill the Agent Decision Set Card. Wire refuse paths on the sinks. Drill one ambiguous case before the first production allow.

Ambiguity is a designed path—not a surprise

Bounded classifiers shine when the world is mostly clear. Real operations are not. The card's job is to make ambiguity cheap to handle and expensive to ignore.

Prefer flag when the action is reversible only with pain, when two policies collide, or when the evidence the agent saw is incomplete. Prefer block when the only authority for the action would be untrusted prose, when the sink is irreversible money or identity change above a ceiling, or when the audit join would break.

Prefer allow only when the action is in the named set, the score clears the auto-ok threshold, and no block rule matches. Allow is not the default for "the model sounded confident."

If your flag band is enormous, you do not have a classifier problem—you have an action-space or fixture problem. Shrink what the agent may propose, or improve the evidence it must attach, before you buy a faster model.

The Decisions API shape—and System One decision models like it—are good news for operators who already know their labels. They are a trap for teams who hoped the model would invent governance.

Put this into practice

1. List every agent (or planned agent) that proposes actions touching money, inventory, PII, access, or ERP state.
2. Fill a TWIMCO Agent Decision Set Card for each: labels, meanings, auto-ok threshold, flag band, block rule, human owner, audit field, wait behavior.
3. Refuse production allow until fixtures exist and one block drill has been run with the sink confirmed quiet.
4. Treat vendor classifier demos as a hook for the pattern—not as your threshold, your cost model, or your policy.
5. If the gap is designing agents that operate inside real business systems with gates you can defend—not another demo—bring the filled cards into a scoping conversation for AI applications & agents. Wiring the same handoffs and exception paths sits next door at business automation.

A bounded decision API can make the gate fast. Only you can make the gate true. Name the decisions before you buy the classifier.