Begin with three modes.

I would separate an explanation, a proposal, and an action. The interface should make it obvious which mode the user is in.

1. Explain

The agent can retrieve approved material and explain it. It should distinguish facts, estimates, and missing evidence. Reading about a booking is not the same as making one.

2. Propose

The agent can prepare a draft, a summary, or a proposed next step. The user can review the relevant information before anything changes outside the conversation.

3. Act

A real action should have an explicit scope, an appropriate permission check, and a result that comes from the system responsible for it. A button click alone should not become “your meeting is booked.”

Do not make the animation more certain than the evidence.

A review checklist for this portfolio.

Can the guide answer without inventing an accomplishment? Can the visitor browse without interacting with it? Is voice clearly opt-in? Does the page explain whether a booking is a preview or a confirmed event? Those are good tests before adding more autonomy.

Keep the record useful, not invasive.

The proposed implementation should retain only the information required for its intended purpose, make that purpose clear, and separate optional follow-up from simply using the website.

Sources & further reading

Model Context Protocol: introductionCartesia developer documentationOriginal sample editorial for this mockup. The links are further reading, not independent validation of the author's project outcomes.