Decision models
Call System One and OpenAI-format decision models through the gateway using your organization's provider credentials, with explicit formats and proxy behavior.
About
The gateway has dedicated routes for structured decisions. These requests contain state or input and typed questions, not chat messages. The gateway sends the body to a provider that speaks its format and returns the provider’s JSON response. It does not translate System One requests into OpenAI Decisions requests or the reverse.
Decision calls use your organization’s provider credentials, or a key supplied for that call by an authenticated internal caller. They never fall back to a platform operator’s key or a license’s managed-service token. A Generic System One endpoint can be keyless when it is explicitly configured; known vendors still require your key.
When to use
- Route Jev or another System One model through the gateway rather than calling its upstream directly.
- Send an OpenAI Decisions request without converting it into a chat prompt.
- Use an organization-owned decision endpoint with the gateway’s access controls, limits and request logs.
- Route decision traffic through an outbound HTTP proxy while keeping existing chat connections direct.
For reusable Jev evaluations in the Future AGI UI, see Jev evaluators. You do not need to call these routes manually to use Jev in the evaluator editor or Instant eval.
How to
Configure the organization's provider
Configure an enabled provider owned by your organization, with its credentials, base URL and the decision models it serves. Use api_format: systemone for System One providers (typesafe is an accepted alias), or api_format: openai for OpenAI Decisions.
The provider must list the requested model. Saving a vendor key without adding that model is not enough. See Supported providers and Platform integration.
List the available models
Call GET /v1/decisions/models with your gateway API key. It returns decision models from the organization’s enabled, usable providers, including explicitly configured keyless Generic System One endpoints. Each entry identifies its provider and format.
curl "$GATEWAY_URL/v1/decisions/models" \
-H "Authorization: Bearer $AGENTCC_API_KEY"Use a returned model ID, including its provider prefix, to select that provider explicitly. An internal key has no organization and returns an empty list. This endpoint lists configured models; it does not discover a vendor’s catalog by making inference calls. It lists configured System One models; for OpenAI-format providers it lists only configured models the gateway’s decision-model catalog recognizes, so other configured IDs may be absent.
Send the matching request format
Send a System One body to POST /v1/systemone, or send either supported format to POST /v1/decisions.
This System One example uses a two-level score question. The TypeSafe provider must be configured with jev-latest:
curl "$GATEWAY_URL/v1/systemone" \
-H "Authorization: Bearer $AGENTCC_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "typesafe/jev-latest",
"state": {"text": "The assistant answered the question and confirmed the next step."},
"questions": {
"q1": {
"type": "score",
"instructions": "Rate whether the assistant provided a clear next step.",
"criteria": ["No clear next step", "Clear next step"]
}
}
}'Question types and criteria are defined by the upstream API. The gateway preserves the request body apart from rewriting the model name for the selected upstream; the successful response body is returned unchanged.
Inspect the response or error
A successful call returns the provider’s decision JSON, including its answers and usage when supplied. Decision calls do not use chat routing strategies, model maps, retries or fallback models. Correct the provider, format or key when a call is refused; do not expect a different model to answer it automatically.
Routes and formats
| Route | Request format | Behavior |
|---|---|---|
POST /v1/systemone | System One: model, state, and questions as an object keyed by question ID | Sends to a System One provider; an OpenAI-style question array is refused |
POST /v1/decisions | System One question object, or OpenAI Decisions question array | Detects the format from questions and requires a provider that speaks it |
GET /v1/decisions/models | No request body | Lists the caller organization’s configured decision models |
The two POST routes are not chat-completions routes. A System One-only provider cannot answer a chat request.
Supported dialects
| Provider or endpoint | api_format | Default upstream | Decision path |
|---|---|---|---|
| TypeSafe / Jev | systemone or typesafe | https://api.typesafe.ai | /v1/systemone |
| Perplexity Decider | systemone | https://api.perplexity.ai | /v1/decisions |
| Generic System One endpoint | systemone | None; an explicit base_url is required | /v1/systemone |
| OpenAI Decisions | openai | OpenAI provider endpoint | /v1/decisions |
For System One, the gateway identifies TypeSafe and Perplexity from the base URL’s host, then the provider ID. Another explicit endpoint uses the Generic dialect. A provider configured with the wrong api_format is refused rather than treated as a compatible decision provider.
Generic means a server that actually implements the System One body and response format. Merely serving OpenAI-compatible chat is not enough. It can include a compatible self-hosted server or a compatible endpoint under a longer base path, such as a Foundry resource path. The configured base path and API path prefix are used to build the decision URL.
Keyless Generic System One
An enabled organization provider can omit credentials only when it is a Generic System One provider with an explicit usable base URL and a model list. The endpoint may implement its own network access controls; keyless does not mean public access is safe.
This exception does not make TypeSafe, Perplexity or OpenAI keyless. A Generic endpoint is still subject to the organization’s URL checks and model access rules. See Private and local provider URLs.
Which key is used
| Caller | Credentials used |
|---|---|
| An organization’s gateway API key | Only that organization’s enabled providers serving the requested model |
| An authenticated internal platform caller | The customer’s provider key in x-agentcc-provider-key, for this call only; the model must name typesafe/, perplexity/ or openai/ |
| A license managed-service token | Refused with byok_required |
| A standalone gateway with authentication disabled | The exact provider configured in its own config.yaml; no organization isolation is available in this mode |
Ordinary organization keys cannot send x-agentcc-provider-key. The internal header is removed before request headers are retained for logs or spans. Internal callers never borrow a config.yaml provider’s API key, even if it serves the same vendor. The authentication-disabled case is for a gateway whose operator is the customer, not a way for tenants to use a platform-owned key.
Outbound proxies and host checks
Every decision call honors HTTP_PROXY, HTTPS_PROXY and NO_PROXY in the gateway’s environment. This applies to both formats and to providers from config.yaml, organization providers, and internal calls carrying the customer’s key. Set these variables on the gateway process or service, not only on the Future AGI backend. The Helm chart’s global.proxy supplies them.
Chat providers still connect directly. A proxy that permits decision traffic does not by itself make chat traffic work behind a restricted firewall.
For an organization-owned endpoint, the gateway validates the destination even when a proxy is used. Private-address policy and the blocks on loopback, link-local and cloud metadata addresses still apply. DNS is resolved before each HTTP/1.1 request, including reuse of a pooled connection. A DNS failure or refused address fails closed rather than asking the proxy to bypass the check. Configure the proxy’s own destination policy too.
Decision calls never follow upstream redirects, so a redirect cannot carry the provider key or request content to another destination. Trusted operator-configured providers have different URL rules from organization providers; see Private and local provider URLs.
Errors
Errors use the gateway’s JSON error envelope. Useful codes include:
| Status | Code | What to check |
|---|---|---|
| 403 | byok_required | Use the organization’s provider key, not a managed-service token; an internal caller must supply the customer’s key |
| 400 | provider_key_header_not_allowed | Remove x-agentcc-provider-key from an ordinary organization-key call; save the key on the organization provider instead |
| 403 | provider_key_missing | Add the key required by the configured System One vendor |
| 403 | decision_provider_not_configured | Enable the organization provider, add credentials where required, and list the requested model |
| 403 | decision_provider_wrong_format | Correct the provider’s api_format |
| 422 | format_mismatch | Match the body dialect, route and selected provider |
| 403 | provider_base_url_blocked | The organization provider URL violates the destination policy |
| 502 | provider_base_url_unusable | The organization provider URL is invalid or its host cannot be resolved |
| 403 | provider_key_rejected | The upstream rejected the saved key |
| 402 | provider_payment_required | The account owning the upstream key needs payment |
| 404 | model_not_found | The configured upstream does not serve the requested model |
| 413 | request_too_large | Reduce the request; the gateway also enforces its own body limit |
| 429 | rate_limit_exceeded | Wait according to Retry-After, when supplied |
| 503 | provider_overloaded | Retry later; Retry-After is preserved when supplied |
| 504 | gateway_timeout | The gateway or the upstream timed out, including upstream HTTP 408 and 504 responses |
| 400 or 422 | upstream_rejected | Correct the request according to the sanitized upstream error |
| 502 | upstream_error or upstream_invalid_response | The upstream failed or did not return a usable JSON object |
A decision request body is limited to the smaller of the gateway’s configured body limit and 32 MiB. Upstream response bodies are capped at 10 MiB. The gateway does not retry a decision automatically.
Next steps
Questions & Discussion