Why our AI never acts without a yes: inside confirmed write actions

An AI that can only talk is easy to trust. An AI that can open a support ticket, book a callback or save a request in your system is far more useful, and it needs rules that do not depend on the model behaving. This post explains how Ordina's write actions work: what has to happen before the Secretary changes anything in another system, and why each of those checks lives in code rather than in a prompt.

The problem with "the AI will ask first"

Most AI agents are told, in their instructions, to confirm before acting. That works until it does not: a model misreads "sure, what are my options?" as a yes, or skips the question when a conversation gets long. We tested prompt-only rules on our own Secretary and saw them fail in live conversations. So we moved the rule out of the prompt.

In Ordina, the Secretary cannot call a write action at all. It can only propose one. The call itself is made by Ordina's code, and only after checks the model cannot skip.

Step 1: the owner switches each action on

A partner app (or the business's own developer) registers a write action through the API, with "effect": "write". It arrives switched off.

The business owner opens Integration, then Connected actions, reads the title and description, presses Test with real values, and switches it on. For a write action they are asked once more, with the app's name, what it says it does, where the request goes, and which of the customer's contact details it will receive.

Then the rule that keeps it honest: any change switches it off. If the app changes the title, description, parameters, URL, effect or the contact fields it receives, the action turns itself off until the owner approves it again. The dashboard shows them what changed, field by field. Revoking the app's key, or disconnecting the app, switches its actions off too. Only the owner can switch an action on; the API cannot.

Step 2: the Secretary proposes, Ordina writes the summary

Say a courier has a create_support_ticket action. A customer writes:

My parcel SC123456789 arrived damaged, the box was crushed and the lamp inside is broken. Can you look into it?

The Secretary fills the action's parameters (tracking number, problem, summary). Ordina checks them against the schema the app declared and drops anything unknown. If a required value is missing, the Secretary asks for it.

Then Ordina shows the customer what will be sent. That text is built by Ordina from the action's title, the details and the contact fields. It is never written by the AI, so the model cannot describe one thing and send another:

Support ticket (tracking number: SC123456789, problem: Damaged, summary: The box was crushed and the lamp inside is broken). Sent to tunde@example.com.

On the website chat, the customer also gets Confirm and Cancel buttons.

Step 3: the customer's yes, checked in code

The proposal waits for the customer, and the rules for what counts as a yes are strict:

• Only the customer's next message can confirm it, and only a clear yes. A question with a question mark is not a yes.
• A clear no cancels it, and so does a message about something else, or a reply more than 30 minutes later.
• A yes within 1.5 seconds of the request appearing neither confirms nor cancels it. Nobody can read the details that fast, so the customer is asked to check and reply again.
• Before calling, Ordina checks the action is still switched on and unchanged since it asked. If the owner changed or disabled it in between, nothing is sent.

Only then does Ordina make one signed call to the app's endpoint.

Step 4: contact proof, stated or verified

Some writes need to know who the customer is. A callback must go to the right phone; a ticket's replies must go to the right inbox. Ordina treats this carefully.

Contact details are never parameters. An action whose parameters ask for an email, phone, name or address is refused when it is registered. Instead, a write action declares customer_fields (any of name, email and phone), and Ordina fills them from what it knows about the customer, never from what the AI writes.

The action also says how sure Ordina must be, with customer_proof:

When a verified contact is needed and the channel cannot prove one, the Secretary says this can be done on a channel that can, or that the team can help directly. A name is always taken as given and never proves who someone is.

Step 5: an Idempotency-Key on every confirmed call

Networks fail. The worst outcome for a write is doing it twice: two tickets, two callbacks. So every confirmed call carries a header:

Idempotency-Key: 3f0c2a8e-5b1d-4b8e-9a7c-2d4e6f8a1b3c

The same value appears in the body as idempotency_key, next to confirmed_at and a customer block that holds only the fields the owner approved, each with its proof:

"customer": {
  "email": { "value": "tunde@example.com", "proof": "stated" }
}

The contract is simple:

• Treat the key as the request's identity. If the same key arrives twice, change nothing the second time and answer as you did the first time.
• Ordina does not retry a write by itself, and never reuses a key for a different request.
• Each confirmation gets its own key. A customer who asks for two tickets confirms twice.

What the customer sees

The app answers within 10 seconds, and the customer is told what happened in Ordina's own words, never the AI's:

• { "ok": true }: "Done:" plus what was confirmed, and the app's optional message, such as a ticket number.
• { "ok": false } or an error status: the customer is told it did not go through and nothing was changed.
• No answer in time, or an unclear reply: recorded as unknown. The customer is told it could not be confirmed and the team will check, and the owner is asked to check with the app.

That last case matters. We never tell a customer something worked unless the other system said so.

Watching it from your side

Apps and owners can follow every step through opt-in webhook events: action.requested, action.confirmed, action.declined (with a reason such as declined, expired or moved_on), action.failed, and action.enabled and action.disabled. Their proposal_id matches the Idempotency-Key, so events and calls line up. None of them carries the customer's contact details.

Where write actions run today

On every chat channel: the booking page chat, the website widget, Telegram, email, and Instagram, Messenger and WhatsApp for businesses in early access on those channels. Not on phone calls yet; on a call the Secretary only uses lookups. Write actions are also not available to AI assistants connected over MCP yet.

The same rule on the owner's side

The principle is not only for partner apps. When an owner runs their business through the Secretary in the dashboard, or from Claude with our connector, anything that tells a customer something they cannot take back (cancelling or moving an appointment, cancelling an order, emailing someone) comes back as a proposal. Nothing happens until the owner says yes, and that check is in code too.

FAQ

Can the AI confirm an action on the customer's behalf?

No. The confirmation has to be the customer's own next message, and it has to be a clear yes. A yes that arrives within 1.5 seconds, or more than 30 minutes later, does not count.

What stops an app from changing what an action does after approval?

Any change to an action through the API switches it off until the owner approves it again, and the owner sees exactly what changed.

Does a lookup action receive customer details?

No. Lookups never receive a customer's name, email or phone. Only write actions can, and only the fields they declared and the owner approved.

Which plan includes connected actions?

The Business plan, at $39 a month or $390 a year. Read the full contract in the connected actions guide.