An incoming request needs the right queue. A document needs a relevance score. An agent needs to decide whether it has enough evidence to continue or should ask for help.
These are useful AI tasks, but the answer your application needs is often much smaller than a paragraph: an option, a probability, or a score.
Aixy now supports decision models through POST /v1/decisions and POST /v1/systemone. You can bring these evaluations into your applications using a project API key and a configured provider connection, with the access controls and operational visibility of the Aixy gateway.
Models such as TypeSafe’s Jev, Cloudflare’s Clef, and Fastino’s GLiDE put this pattern into practice. Here is what decision models do, where they fit, and what changes when you run them through Aixy.
From generated text to application decisions
Decision models evaluate supplied evidence against questions you define. Instead of asking for an explanation and then extracting an answer from prose, your application requests a typed evaluation it can use in its next step.
That makes them useful for classification, workflow selection, content evaluation, and deciding when a person should review an ambiguous case. You can also ask several questions in one call to evaluate different aspects of the same input.
There are three main question types:
- Predicate, called Noul in System One, returns the probability that a condition is true. For example: does this request describe a service outage?
- Choice selects from the options you provide. For example: should this request go to identity, networking, or device support?
- Score evaluates evidence against an ordered rubric. For example: how urgent is the request on a defined scale?
The selected provider and model must support decision inference. A conversational model that can return JSON does not automatically support these APIs.
Jev, Clef and GLiDE: decision models to explore
Jev, from TypeSafe, evaluates supplied state against typed Choice, Score, and Noul questions, returning structured answers and probability information. Its documentation encourages developers to ask focused questions and combine the results in code. That makes Jev a useful starting point for understanding the System One approach: the model evaluates the evidence, and application logic decides what happens next.
Clef and Clef-flash, from Cloudflare, bring decision models to Workers AI. Both evaluate state against typed questions and return probabilities for the permitted answers. The official model pages include API examples for classifying requests, selecting a support team, and scoring severity, giving developers a practical route to explore Cloudflare’s decision model family.
GLiDE, from Fastino, uses the System One schema for structured decisions. Fastino describes its adaptive thinking approach as making an initial assessment, then applying additional reasoning when the choice is uncertain. Its API accepts state and named questions, with structured answers for tasks such as selecting tools, verifying outputs, and choosing workflow steps.
Choosing a model is only part of the integration. Aixy provides the Decisions and System One gateway APIs for compatible provider connections, so teams can centralize credentials, apply project access policies, and inspect operational metadata in one place. Available models and features depend on the configured connection and provider contract.
A practical example: routing an IT request
Imagine an employee submits this request:
My new laptop connects to Wi-Fi, but the company VPN will not authenticate. I need access before a customer workshop this afternoon.
Your application could evaluate it with three questions: choose the most relevant support queue, assess whether it describes a wider outage, and score urgency against a rubric that distinguishes routine work from a deadline-blocking issue.
The result gives the application structured evidence for its next action. It could suggest the identity queue, attach the urgency assessment, and request human review when the evidence is ambiguous or the model refuses to answer. The team receives a more useful starting point than an unclassified message.
The application still owns the workflow. A model's recommendation does not grant access, change permissions, or replace a deterministic authorization policy. It helps interpret the request; your code decides which actions are permitted.
The same pattern works for selecting an onboarding workflow, prioritizing documents for review, or assessing whether an agent should continue with the information it has. Each evaluation can feed a clear branch in your application, while your code retains control over what happens next.
The Aixy advantage: one place to connect and control
Adding a decision endpoint is only part of putting this capability to work. Teams also need to manage credentials, define who can call which models, and understand what happened when a request fails.
Aixy centralizes the provider connection. Provider credentials and endpoint configuration belong to a saved organization or project connection. Your application calls Aixy with its project key and a provider-qualified model ID. Provider configuration stays in the gateway instead of being repeated across applications.
Decision calls use existing gateway controls. Project access, model blocks, guardrails, monthly request admission, request limits, and concurrency controls still apply. Teams can introduce decision workloads within their existing project boundaries and access policies.
Activity provides operational evidence. Decision inputs and outputs are processed transiently and excluded from Activity content capture. Activity retains operational metadata such as status, latency, provider usage when supplied, and cost attribution. Usage and costs remain unknown when the required provider or pricing data is unavailable.
Compatibility is explicit. Aixy accepts both Decisions and System One formats. Native requests preserve the provider contract, and compatible requests can be translated between formats while retaining question identity and typed choice values. When a feature cannot be represented, Aixy returns a clear compatibility error. Support depends on the selected model, provider, and request features.
Together, these capabilities let you add decision inference without building a separate access and operations layer for every integration. Developers can focus on the questions their application needs to answer, while the team manages provider connections, access policies, and request visibility in Aixy.
Put the result to work
Probabilities and confidence describe a model's evaluation; they do not guarantee accuracy. Test representative examples, define how your application handles ambiguous results and refusals, and choose thresholds that fit the consequences of the action.
Decision calls are non-streaming; hard-budget policies currently reject public decision calls because they lack a provider-enforced completion bound for safe reservation. See the decision model documentation for compatibility and policy requirements.
To get started, open the Aixy dashboard, configure a supported decision provider connection, and use your project key with the appropriate endpoint. The API documentation covers request formats, response schemas, and examples.
Bring decision models into your application through Aixy, and keep their connections, access, and operational evidence in one place.