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.
Top comments (0)