Skip to main content
An agent about to spend money or change data should check the move against your rules first. Put the goal, the proposed action, and the policy in state, then ask GLiDE what the agent should do next. Your code, not the model, carries out the decision.

Request

Request schema

Response

Measured against https://api.fastino.ai. Confidence values vary slightly between calls.
The user said “just get it done”, but the policy requires confirmation for a non-refundable purchase over $100, so GLiDE picks confirm. Remove the policy line and the same request returns book. Put the rule in state whenever it should win.

Response schema

Act on the answer

Only the safest path, asking the user, is the fallback. An uncertain or irreversible answer never executes on its own.

Adapt it

  • Make each criteria key a branch your agent already supports, such as run, ask_user, escalate, or abort.
  • Quote the policy text exactly. GLiDE applies the rule you supply; it does not know your policies otherwise.
  • Include the facts the policy depends on (amount, recipient, refundability) in proposed_action.
  • Keep the final check in code. For example, never let a spend over a hard limit run, whatever the answer.
Use GLiDE as decision support, not as the only safeguard for irreversible or high-impact actions. Validate on representative cases and keep a human-review path.

Policy and safety guide

Design gates that fail safely on uncertainty.

GLiDE API reference

Every field, limit, and error for POST /v1/systemone.