# Confirm-before-apply

Adragent never makes a state-changing operation without your explicit *yes*. Every write goes through a structured preview, and the change runs only when you confirm — not before, not after, not on a re-interpretation.

This page explains how the approval step works, what kinds of action need an explicit confirmation, and how the pattern behaves across channels.

{% hint style="info" %}
**Read operations skip preview.** Listing properties, checking a rate cell, summarising bookings — anything that does not change state — returns immediately. Confirm-before-apply applies to writes.
{% endhint %}

***

## How the loop runs

<figure><img src="/files/qYcphrJCoOqQQzaLMyQJ" alt="Intent → Plan → Preview → (refine loop / cancel exit / confirm) → Apply"><figcaption><p>Every write follows the same loop. You can refine ("only Saturdays"), cancel, or confirm — Adragent re-plans on a refine, drops the operation on a cancel or expiry, and applies exactly the previewed change on a confirm.</p></figcaption></figure>

* **Intent** — what you ask Adragent to do, in your own words.
* **Plan** — Adragent works out which operation matches your intent and what the inputs would be.
* **Preview** — a structured summary of exactly what would change, before anything moves.
* **Confirm** — your explicit *yes*. If you do nothing, nothing happens.
* **Apply** — the change runs with the inputs you saw in the preview. No re-interpretation between approval and execution.

If the preview does not match what you meant, you refine (*"only weekends"*) or cancel. Adragent re-plans and shows a new preview.

***

## What needs confirmation

The level depends on how big the change is. The same operation has the same level for everyone — the platform decides, not the user.

| You ask Adragent to…                                                                                     | What you do                                                                                      |
| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Look something up** — list, search, view, summarise                                                    | Nothing. Adragent answers right away.                                                            |
| **Make a small, single change** — create one record, update a non-critical field, delete one item        | Reply *yes* in chat after the preview.                                                           |
| **Make a critical change** — bulk edits, rate or inventory cells, payment configuration, contract status | Click **Confirm** on a structured preview card.                                                  |
| **Run a destructive bulk operation** — wide-range deletes, full-organization changes                     | Click **Confirm** on the structured preview. The preview shows the full impact in plain numbers. |

Every write — small or critical — comes with a preview you can read before approving. There is no *"Adragent did X without warning me"* state.

***

## What the preview shows

A preview is not a paragraph of prose. It is a structured summary of *exactly* what would change, in operator-readable form:

* **The operation Adragent would run** — *Apply promotion*, *Update rate plan*, *Stop-sale*.
* **What it touches** — the names and identifiers of every property, room, rate plan or contract that would change.
* **Before and after** — for value changes, the current value and the proposed value side by side.
* **The scope** — date ranges, audience filters, channel bindings.
* **Side effects** — anything else that would happen as a consequence (*"this stop-sale will pause 3 outbound channel pushes"*).

If the preview does not match what you meant, refine or cancel. The plan only commits if you approve the preview as-is.

***

## How you confirm

Inside the console, you confirm in line in the chat. For bigger changes, the preview opens as a card with an explicit **Confirm** button.

* *"yes"* / *"confirm"* / *"go"* in chat for inline-eligible operations.
* The **Confirm** button on the preview card for explicit-confirmation operations.
* *"only Saturdays"* / *"skip Hotel Sea Breeze"* / *"add Hotel Marina too"* — Adragent re-plans and re-presents.
* *"no"* / *"stop"* / closing the preview — the plan is dropped.

When channels other than chat are live, you can approve from there too. The approval is bound to the specific operation Adragent staged for you — a token in the message ties them together so you cannot accidentally approve the wrong thing.

***

## How long an operation waits for you

A staged operation waits up to **24 hours** for your approval (configurable per organization). After that it expires and you have to ask again. Within a chat session, Adragent re-prompts sooner — about five minutes — so the flow does not stall on you.

Practical case: you stage *"stop-sale Hotel Sunrise rooms 12 and 14 from 1 to 8 June"* before lunch, you eat, you come back at 1:30 pm — the preview is still there waiting. You stage the same thing on a Friday and forget over the weekend; by Monday morning it has expired and you re-ask.

## You will not get charged twice

If the same approval is delivered twice — through a network retry, a duplicated message, an accidental double-click — Adragent does not double-apply. The change runs exactly once. You see the same outcome on the duplicate; the platform absorbs the rest.

## Where to next

* **The catalog of what Adragent can do** → [Tools](/console/adragent/tools.md)
* **The channels where Adragent meets you** → [Channels](/console/adragent/channels.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/adragent/confirm-before-apply.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
