What about attachments and threads?

Paste the thread as text into the state; attachment summarization happens upstream of the call. A 20-mail thread still lands well under the token ceiling.

Does the "other" intent catch spam?

Partly — most spam scores other with low urgency, where a faster filter can drop it. Phishing deserves a security classifier, not this one: the cost of a wrong direction here is human.

Can each team tune their own queues?

The intent choice is one shared decision — keep criteria wording owned by the shared-inbox owner so "sales" does not quietly mean something different to each team.

Use case

Email and lead triage

Sort inbound email into billing, support or sales and mark what is due today.

The problem

Shared inboxes become a pile. Renewals wait behind feature questions.

What your code does with the answer

Route by intent. Anything marked urgent skips the backlog.

Reading the inbox in one call

The email (subject and body as one state) decides where it goes: intent (choice across billing, support, sales, other) and urgent (should this be answered today). The sample mail — a renewal blocked because finance never received INV-2041, resend requested today — scores intent=billing and urgent high, which is exactly the mail that must not wait behind feature questions in a shared inbox.

The queue rule

Route on intent, each queue keeping its own SLA; anything urgent skips the backlog. One more rule earns its keep: mail whose intent probability is contested between two queues goes to both rather than to whichever is higher. At roughly 400 tokens an email, triaging ten thousand mails costs a few dollars of credits.

Pitfalls specific to inbox triage

The common failure is reply context lost: a "re:" arrives with the prior chain stripped, and intent reads on nothing. Paste the thread into the state. Also — if two teams' SLAs differ (support answers in hours, sales same-day), intent and urgent each need their own path, otherwise "urgent" quietly deprioritizes half the sales mail.

The request shape

This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.

curl

curl https://jevai.website/api/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "state": "Subject: Re: invoice INV-2041\nHi, we never received INV-2041 and finance is blocking our renewal until this is sorted. Can someone resend it today?",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What is the sender asking for?",
      "criteria": {
        "billing": "Invoice, payment or refund",
        "support": "Product help",
        "sales": "Pricing or a new deal",
        "other": "Something else"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Should this be answered today?"
    }
  }
}'

FAQ about this use case

What about attachments and threads?: Paste the thread as text into the state; attachment summarization happens upstream of the call. A 20-mail thread still lands well under the token ceiling.
Does the "other" intent catch spam?: Partly — most spam scores other with low urgency, where a faster filter can drop it. Phishing deserves a security classifier, not this one: the cost of a wrong direction here is human.
Can each team tune their own queues?: The intent choice is one shared decision — keep criteria wording owned by the shared-inbox owner so "sales" does not quietly mean something different to each team.

Run this in the playground