Does the gate slow every tool call?

Only the ones you send to it. Most teams gate writes and pass reads through; round trips cluster at 400–600 ms in live measurements, so sub-100 ms reads would rather not pay it.

Can the model see my whole codebase?

No — it only sees the state you send. Include the environment (staging vs production) and the caller's intent; those two facts decide most gates.

Is one probability enough to trust?

No single number is enough on an irreversible action. That is why the preset wraps three questions — intent match, human confirmation and destruction score — each with a different threshold in your policy.

Use case

Tool-call risk gate

Score a proposed agent tool call before it touches production data.

The problem

Agents invent SQL and file deletes that look plausible and are catastrophic.

What your code does with the answer

Block or confirm any call whose risk score is above your threshold.

Reading the guardrail answer

Three signals in one call: needs_confirmation and matches_intent as yes/no probabilities, and risk as a score across Harmless → Recoverable → Irreversible data loss. The example above is deliberately ugly — a "clean up staging" request whose tool call drops a production table. Risk scores toward the top and intent-match drops below confidence, which is what your wrapper turns into block-and-log.

Where the gate goes in your loop

Call the gate exactly once, after the agent proposes a call and before execution. Pass the user's original request and the proposed call as state — nothing else needs to be there. Keep the policy lines in code (block at score ≥ 1.5 or intent below 0.8; confirm in between), and gate only the tools whose blast radius justifies a 400–600 ms round trip: SQL, filesystem, deploys, email. Read-only calls can pass without a gate.

Pitfalls specific to tool gates

Never send the gate only the tool call: without the original user request, intent match has nothing to compare against and collapses into a destruction-score-only gate. Do not gate every tool on day one — start with the few whose failures are recoverable-at-best, and revisit as thresholds stabilize. Last: treat a timeout on this call as "ask a human", not "proceed and hope".

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": {
    "user_request": "Clean up the old test data in the staging database.",
    "proposed_tool_call": {
      "tool": "sql.execute",
      "args": {
        "query": "DROP TABLE customers;"
      },
      "environment": "production"
    }
  },
  "questions": {
    "needs_confirmation": {
      "type": "noul",
      "instructions": "Should a human confirm this tool call before it runs?"
    },
    "matches_intent": {
      "type": "noul",
      "instructions": "Does `proposed_tool_call` match what `user_request` asked for?"
    },
    "risk": {
      "type": "score",
      "instructions": "How destructive is this action if it is wrong?",
      "criteria": [
        "Harmless",
        "Recoverable",
        "Irreversible data loss"
      ]
    }
  }
}'

FAQ about this use case

Does the gate slow every tool call?: Only the ones you send to it. Most teams gate writes and pass reads through; round trips cluster at 400–600 ms in live measurements, so sub-100 ms reads would rather not pay it.
Can the model see my whole codebase?: No — it only sees the state you send. Include the environment (staging vs production) and the caller's intent; those two facts decide most gates.
Is one probability enough to trust?: No single number is enough on an irreversible action. That is why the preset wraps three questions — intent match, human confirmation and destruction score — each with a different threshold in your policy.

Run this in the playground