Propose, Then Confirm: How We Let an AI Change Real Business Data Without Fear

I run a small coworking space in Burgas, Bulgaria, with my wife. I also build OhMyDesk, the software we run it on.

Most of the admin in a small space happens on the go. Someone walks in and wants a desk tomorrow. A member pays in cash. A bill for coffee beans arrives. You are standing at the door with a phone, not at a desk with a dashboard.

So we added an AI operator to the Telegram bot that already sent us booking alerts. You type what you need in plain words. It answers questions about your space, and it can do the work.

That second part is scary. An AI that answers questions can be wrong and you shrug. An AI that writes to your bookings and invoices can be wrong and you lose money or a customer.

Here is the pattern that let us ship it anyway.

You: Book a free desk for June 30 Bot: There's 1 free desk on June 30. That's Desk 2 (Room 1). Who should I book it for? You: Alex Bot: Book Alex — Desk 2 (Room 1), Tue 30 Jun · 1 day · 8 EUR [Confirm] Bot: ✅ Booked Alex on Desk 2 (2026-06-30). Enter fullscreen mode Exit fullscreen mode Four messages. No forms. And the AI never had the power to save anything by itself.

If you build an agent that touches real data, I think this is the single most useful rule. Below are the lessons that came with it.

A vague proposal is useless. "I will book a desk for Alex" does not let you catch a mistake. Which desk? Which day? At what price?

So every staged action shows the full result: who, what, when and how much. The human checks the same facts they would check on a paper form. If the date is wrong, you see it before it matters.

A good test: could a tired person at 8 a.m. spot the error in two seconds? If not, the proposal needs more detail.

When a request is missing something, the AI asks. "Who should I book it for?" "Which desk?"

It is tempting to let the model fill gaps with its best guess. Don't. A guess that looks confident is worse than a question. The question costs one message. The wrong guess costs an awkward call to a member.

People reply with fragments. "10:00." "Desk 4." "Yes, her."

If your agent treats each message as a new request, a fragment like "Desk 4" means nothing. Worse, it might start a new action. We made sure a short follow-up stays attached to the open conversation. The time or desk number fills the missing slot in the proposal already on the table.

This sounds small. In practice it is the difference between a chat that feels natural and one that feels like a broken form.

Operators ask things like "revenue this month versus last" or "how many desks are free this week."

A language model will happily produce a plausible number. That is the worst possible failure for a business tool, because nobody checks a number that looks right.

So answers are grounded in the space's live data. If the data is not there, the answer says so. And each space only ever sees its own data. The AI cannot read another space's records.

Telegram is a busy app. People type in the wrong chat. They paste text by accident. Kids grab phones.

With propose-then-confirm, a random message can at worst produce a proposal you ignore. It cannot cancel a booking or mark an invoice paid on its own. That gave us the confidence to let the bot do real work, not only answer questions.

Our customers are small spaces across Europe. Many prefer to type in their own language.

The operator can write in English, Bulgarian, Russian or most other European languages, and the bot replies in the same language. Since the action itself is structured (a date, a desk, an amount), the language of the chat does not change what gets saved.

Some actions should stop one step earlier. An invoice is one of them.

When you ask the AI to draft an invoice, it saves a draft on the Invoices page. It does not send anything to the member. You review it and send it yourself. Money sent to the wrong person in the wrong amount is very hard to take back, so the human keeps the last word.

For context, this is the list of actions the operator can stage, each behind a Confirm tap:

It also answers questions like who is in today, which plans end soon, and which leads have gone quiet.

A short checklist, whatever your domain:

None of this needs a better model. It needs a smaller job for the model and a clear button for the human.

If you want to see how it looks in a real product, the OhMyDesk AI Autopilot page has a short demo. The rest of the product is on ohmydesk.app.

I would love to hear how others handle this. Do you let your agents write data directly, or do you keep a human tap in the loop?