An AI tool call is not consent: building visitor-approved question forwarding

Safak Akyol — Sun, 04 Oct 2026 17:48:57 +0000

I build Tasda, a web platform where people configure an AI representative using their own information and share a public profile. This is a product implementation note from its developer, not an independent review.

A useful piece of feedback was that a representative needs a way to hand an unanswered question back to its creator. The tempting implementation is to give the model a “send to owner” tool. I chose a different boundary: the model can prepare a question, but the visitor decides whether to send it.

Separate proposing from writing

The model-facing tool returns a short preview. Calling the tool does not create a request. The web client shows the exact question and a confirmation control. Only a separate authenticated confirmation request can persist that question.

In simplified pseudocode, the distinction is:

model proposes question
    -> server creates signed preview
    -> client displays question
visitor confirms
    -> server validates preview and current eligibility
    -> server stores one request

That last step is an application action, not a second interpretation of the conversation by the model. This matters because “the model decided it should forward this” is not the same as “the visitor chose to share this.”

Bind the preview to its context

The preview expires after one hour and is signed. Confirmation checks its representative, visitor and chat binding, as well as whether forwarding is still available for that representative. A valid signature alone is not sufficient if the current context no longer permits the action.

The confirmation payload is kept out of the model-visible tool result. The model receives the conversational result it needs; the client receives the separate confirmation card.

Share the question, not the transcript

Only the short question shown in the preview is stored for the creator. The forwarding action does not send the rest of the conversation or its attachments. This is a boundary for this feature, not a claim that the platform processes no chat data.

The creator answers through the existing Requests area, and the visitor finds the answer in My requests. The answer does not automatically become new knowledge for the representative. Responding to one visitor and changing what a representative tells future visitors are separate decisions.

Make confirmation safe to repeat

A double-click or a retried network request should not create two questions. The confirmation path uses transaction locking and a receipt key derived from the preview token so the same confirmation is idempotent.

The checks cover the absence of a write before confirmation, the allowed question payload, expired or mismatched previews, and repeated confirmation. We also verified the real web flow: prepare the question, confirm it, answer it as the creator and read that answer as the visitor. These checks do not establish usefulness for real customers; that needs user testing.

Do not expose a flow the client cannot support

This feature is live in web text chat. Realtime voice does not expose it because the voice flow does not have the explicit confirmation card. Older mobile clients are also excluded from receiving a card they cannot handle. The newer mobile UI is implemented in source but should not be described as publicly released.

The practical lesson for me is to design the write boundary before designing the AI tool. A tool can suggest an action while the application owns authorization, context validation and the durable result.

If you build conversational products, how do you distinguish a model recommendation from a user-authorized write? I would particularly welcome examples of preview-and-confirm flows that were confusing to users.

Disclosure: I am the developer of Tasda. This post was generated by an AI agent from the implementation records and checked against the documented web workflow.

Show DEV: Tasda, a platform for human-designed AI representatives

Safak Akyol — Sat, 03 Oct 2026 22:17:04 +0000

I've been building Tasda as a side project: a web platform where anyone can create an AI representative and share it with a link.

What it does

A guided wizard collects the representative's description, behaviour rules, scenarios and capabilities. No code.
Knowledge comes from the owner's own documents and links.
Visitors talk to it by text or voice and can leave service requests for the person behind it.
The interface and representatives work in English, German and Turkish.

Why

People who share knowledge or services online can't answer everyone around the clock, and generic chatbots don't sound like them. I wanted each representative to feel like the person or character who designed it.

Try it

https://tasda.com/en/ — new users get free starter credits. A few public examples: English Buddy (English conversation practice) and Startup Critic (feedback on startup ideas).

Feedback on the creation flow is very welcome.

DEV Community: Safak Akyol