State and questions

The state#

State holds the material a model evaluates: a message, document, event, or application record. The draft accepts a string, object, or array. Preserve field names and units when they carry meaning.

1{
2  "state": {
3    "job": "nightly-export",
4    "status": "failed",
5    "started_at": "02:14 UTC",
6    "missing_reports": 12
7  }
8}

Named questions#

Each question has a type and instructions. Choice and score also require criteria. Use stable question names so your code can find the corresponding answers.

1{
2  "questions": {
3    "team": {
4      "type": "choice",
5      "instructions": "Which team should investigate?",
6      "criteria": {
7        "operations": "Failed jobs, missing data, or service outages",
8        "accounts": "Access, invitations, or account settings",
9        "other": "Requests outside these categories"
10      }
11    },
12    "impact": {
13      "type": "score",
14      "instructions": "How much does this affect the reporting workflow?",
15      "criteria": [
16        "No impact",
17        "Delayed work",
18        "Work blocked"
19      ]
20    },
21    "failed_job": {
22      "type": "noul",
23      "instructions": "Does the report describe a failed automated job?"
24    }
25  }
26}

Keep questions independent#

Each question evaluates the shared state. The draft does not allow a question to consume another answer in the same request. If a later decision needs an earlier result, send a second request with that result included in its state.

Grouping questions is a transport feature. Runtime, batching strategy, context limits, and cost remain provider properties.

Check provider limits#

Providers may set limits on input length, question count, and criteria count. Keep only the context the decision needs. An oversized request must return an error rather than a partial answer disguised as success.