Understand the system
The conversation is the interface.
Your application does the work.
Your visitor should not need to understand your API, navigate an employee workspace or know which tool answers the question. Buffaly connects their request to the permitted operation and brings the result back into the conversation.
From a visitor’s question to a useful answer
The browser refreshes the public history to show the answer. In parallel, the authenticated staff workspace reads the same conversation and can take control. When an answer needs application data, the installed connector calls your application’s API from the server—not from the visitor’s browser.
Business path: Buffaly → supplied application connector → your application API → your existing business records. Staff path: authenticated staff workspace → shared chat integration → the same Buffaly conversation.
What gets installed where?
| Component | Lives on | Responsibility |
|---|---|---|
| Website embed | Your public website | Displays the hosted chat window. Contains a public URL, never server API credentials. |
| Buffaly.PublicChat | A public HTTPS gateway | Serves the visitor UI and narrow open/send/refresh API. Protects the conversation handle and projects public messages. |
| Buffaly.Chat | Your connected Buffaly installation | Application registry, canonical conversation references, ownership, worker coordination and staff commands. |
| Application connector | The Buffaly installation | Exposes the application’s permitted facts and workflows to its restricted assistant. Supplied separately; authoring it is outside this guide. |
| Staff adapter + shared admin UI | Your authenticated staff application | Inbox, history, takeover, replies and settings. The reference integration uses FeedingFrenzy.Chat.Admin; an optional ASP.NET Core adapter also exists and needs its own target validation. |
| Your business API | Your application | Current prices, availability, leads or bookings, with its existing authorization and persistence. |
Your team takes over without starting again
- Staff open the conversation and read its existing history.
- Take over switches ownership to a registered staff member. The interface must confirm the transition before a staff reply.
- Customer messages continue to be saved while staff owns the chat; AI does not reply over the staff member.
- Staff send their reply in that same conversation.
- Return to AI leaves the history intact. AI waits for the next new customer message; it does not replay messages that arrived during human ownership.
Takeover stops new AI publication and checks whether the worker is quiet. It does not undo an application operation already authorized and completed. Uncertain operations go to review, not a second blind submission.
Follow one real calculation, end to end
The CFL reference uses its existing website calculator. A standard, biweekly clean for a maintained 2,000-square-foot home with two bathrooms returned $155–$195. That recorded result makes each system's responsibility visible.
| Step | What happens | What does not happen |
|---|---|---|
| 1. Ask | The visitor describes the home and service in the website conversation. | The visitor does not receive server credentials or use the internal agent workspace. |
| 2. Select the operation | The application-specific assistant has a permitted calculator tool. | The public assistant does not get all employee tools or a free choice of API destination. |
| 3. Calculate | The connector runs the business's existing calculation with the provided inputs. | The language model does not invent a price or implement a second pricing formula. |
| 4. Answer | The returned range is explained to the visitor and retained in the conversation. | A displayed estimate is not reported as a saved booking or a submitted callback. |
| 5. Continue with staff | The staff member reads that same history, takes over and replies. | The customer does not begin a separate ticket with a copied transcript. |
Recorded reference result from 6 October 2026. This page does not call the calculator or submit a new enquiry. A different business connects its own sources and verifies its own result.
What is remembered—and what gets read again?
Conversation history gives the assistant and staff the context of what the visitor already said. Application tools provide facts such as current prices and availability when the workflow needs them. Remembering an earlier answer is not the same thing as reading the latest business value.
The browser holds a protected conversation capability in session storage so the same browser tab can resume while that capability remains valid. That is not a customer login or a promise of cross-device identity. The operator verifies the intended reload, expiry and restart behavior before launch.
Published settings are versioned. New conversations use the new revision; existing conversations retain their binding. This keeps a settings update from silently changing the rules underneath an ongoing customer exchange.
Simple access boundaries
- Visitor: receives a protected, expiring conversation capability. The browser does not receive a private Buffaly session key or staff authority.
- Staff: sign in to the staff application. Current roles and the registered application/subject allowlists are checked on the server.
- Connector: uses a server-owned HTTPS API destination and credential. The model does not choose an arbitrary URL or authorization header.
- Storage: conversation text stays in canonical Buffaly messages. Chat control state stores references and ownership metadata; your application stores its business records. The reference staff adapter does not create a second CRM transcript.
Website origins are configuration boundaries, not a way to authenticate a customer identity. An anonymous web conversation should not gain access to private customer records just because someone types a name.