You can build an Agentkit website chatbot without writing an application. Add approved pages or files, choose how the agent should answer, test it in the Playground, then copy both generated script tags into your site's code area. The last step is a test on the published page. A chat bubble appearing in the editor does not establish that visitors can use it.
You need an Agentkit account, content you are allowed to use, and permission to add custom code to your website. If your site plan or role cannot publish scripts, an inline iframe may be an option where embeds are permitted. Check your site's rules before starting.
1. Start with a question and its approved answer
Pick three questions visitors actually ask. Include a routine question, one whose answer depends on a current policy, and one your sources do not answer. Write down the approved answer or the human contact route for each. This small answer key gives you something concrete to check later.
For example, a shop might ask, "When can I return a sale item?" Use its current returns policy as the answer source. If the policy does not cover sale items, the acceptable response is to say it cannot confirm the rule and direct the visitor to the store. The example is a test pattern, not a claim about any store's policy.
2. Create the agent and add sources
Create an account, open the dashboard, and choose Add AI agent. The setup wizard takes you through Link, Sources, Design, and AI. You can give it your site URL or add sources manually. In Sources, select the few pages that contain your approved answers. Add a file, text snippet or Q&A pair only when it supplies an answer those pages lack. The source guide explains the available source types.
Review what the crawler included. A site URL does not guarantee that every page is usable, current or approved. Avoid adding duplicate or conflicting policy versions. After a policy changes, update the affected source and retest its question. Paid auto-retraining refreshes existing indexed website URLs; it does not discover every new page or replace uploaded files for you. The website-source guide explains that boundary.
3. Set design and answer rules
In Design, set a recognizable name, color and opening message. Tell visitors what the agent can answer. In AI, choose from the models currently offered in your account and write short instructions about scope and uncertainty. Model names and plan access change, so use the selector in your workspace rather than a static list in an article.
A useful instruction is: "Answer questions about our published returns policy using the supplied sources. If a detail is missing or the sources conflict, say you cannot confirm it and point the visitor to [support route]." Replace the bracketed route with one your team actually monitors. Instructions guide behavior; they cannot make missing or contradictory source material true.
Finish the wizard and open the Playground. Ask your three questions, then a follow-up that changes one important detail. Compare each answer with your written answer key. Fix the source or instructions and repeat the test if a response is wrong. If the agent offers lead capture or an action, test its actual destination before enabling it for visitors; a conversational promise alone is not a completed handoff.
4. Install the generated widget code
Open the agent's Channels → Website embed page, select Chat widget, and enable the channel. Copy the complete code generated for your agent. It contains a short command-queue bootstrap tag followed by an async loader tag with your agent ID and configured widget URL. Paste both tags together into your site's footer-code field or shared HTML template, before </body>. Publish the site. Do not copy an ID or script URL from an example article.
If you want a chat panel inside a page section rather than a floating bubble, enable Iframe on the same Website embed page and use its generated iframe code. For platform placement, follow the current JavaScript widget, React and Next.js, WordPress, Webflow or Framer guide. Add the widget code once per rendered page.
5. Check the public page
Open the published URL in a fresh browser window, including on a phone. Keep this short acceptance record:
| Check | Expected result | If it fails |
|---|---|---|
| Page source | Both generated widget tags appear once | Check the site's code-placement permission, publishing step and cache. |
| Chat opens | The bubble opens and accepts a message | Check that Chat widget is enabled and the script loads. |
| Known question | The answer agrees with the approved source | Correct the source or instructions, then retest. |
| Unknown question | The agent avoids inventing a policy and offers the real contact route | Add an explicit escalation route and test again. |
| Human handoff | The contact link, form or action reaches the intended destination | Fix the destination before launch. |
If the widget appears in Playground but not on the public domain, check domain restrictions as well as the generated code. If the bubble opens but cannot answer, check source processing and your message allowance. Record the test URL, question, observed answer and date so you can repeat the same check after a source update.
A no-code launch still needs source ownership and answer review. Start with a narrow question set, publish, and inspect real conversations for gaps. If you want to try this workflow, create an Agentkit account and test the published widget before directing visitors to it.
