state and questions it sends, and the code that acts on the answers. For a full build with every step explained, follow the System One tutorial, which triages support tickets.
The thresholds below are starting points, not recommendations. Before you let an app act on its own, choose them from your own labelled examples, as described in Best Practices: System One.
Setup
Every example calls one helper,ask, that sends state and questions and returns the parsed response. It needs your API key from the API Keys page in GLOO_API_KEY.
Moderate posts with a review band
The decision: a community app checks each new post before it appears. Clear posts are published, clear violations are hidden, and everything in between goes to a moderator. Onechoice question covers every outcome. ok is the option for posts that follow the rules, and other_issue catches problems the named options don’t cover. Gloo applies no guardrails to System One, so your rules live in criteria.
Request body
ok, not on the top pick. A post is published only when ok is very likely, hidden only when it is very unlikely, and sent to a moderator otherwise:
moderate returns the top violation (answers.policy.choice) as reason. Keep it with the post so the author and your moderators can see why. Widen the band if your moderators overturn too many automatic decisions; narrow it if they agree with nearly all of them.
Route a chat message by intent
The decision: a chat assistant decides which handler should answer each message: a help article search, an order lookup, a booking flow, or a person. Put the latest message and a little recent context instate, so short replies such as “yes, that one” can be understood. Include other so a message that fits no handler isn’t forced into one.
Request body
other to a person. When it isn’t, ask the user to choose between the two most likely named intents instead of guessing:
clarify list into a question, such as “Do you want to check your order or talk to someone?”, and routes on the reply.
Check a request against a policy
The decision: a care team’s request form must not give medical advice, and urgent requests must reach a person quickly. The app checks every request against both rules before it is answered. Each rule is its ownnoul question, written as a statement that is either true or false of the request. Asking both in one request sends the state once.
Request body
urgent uses a very low threshold. Adding a “see a professional” note costs little, so medical_advice uses a low one too. If a probability is missing from the response, the code takes the action anyway rather than skipping it.
noul is a probability, so set each threshold from what a miss costs, not at 0.5 by default.
A check like urgent can miss a request at any threshold, so don’t make it your only safeguard. Show how to get urgent help (for example, your local emergency number) on the form itself, and keep every request in a queue a person reads, whatever the answer.
Choose the next step
The decision: when someone fills in a sign-up card, the app picks one follow-up for them. If the model isn’t sure, the app sends a standard welcome and leaves the card for a staff member. Put the card’s fields instate as an object, so each fact stays separate. Give every follow-up an option, plus none for cards that need nothing.
Request body
noul, with a low threshold, as in the policy check, rather than relying on one option of a choice.
model with each decision lets you tell which model version made it when you review the cards later.
Next steps
Tutorial: Triage Tickets with System One
Build a support-ticket triage step from start to finish, in Python and TypeScript.
Best Practices: System One
Write clear options, choose thresholds from your own data, log decisions and control cost.
System One Guide
What System One is, when to use it, the model it runs on, and pricing.
API Reference: System One Decisions
Every request and response field, and every error status.

