Assistant Troubleshooting
Assistant failures usually come from a missing active profile, an incompatible model, unclear instructions, unsynchronized knowledge, or an existing conversation chain.
Assistant behavior is produced by several inputs at once: the active local profile, selected model, instructions, previous conversation context, retrieved knowledge, and any tool results. A clean private-window test with a known synchronized answer helps isolate those inputs. Chat History then shows whether the failure occurred before, during, or after the OpenAI request.
First, confirm one profile shows active. The useful result comes later when you change one assistant field and repeat the same test, because configuration values matter only when their effect can be seen in retrieval, a generated reply, visitor access, or the connected service.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Isolate configuration issues before changing security, tools, or frontend design.
Use this feature in the following situations:
- The widget reports that no assistant is active or a model request fails.
- Answers appear to follow old instructions after a profile change.
- The assistant responds but ignores expected knowledge, identity, or tools.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Confirm one profile shows Active.
- Open it and verify all required text and model fields.
- If the model list fails, troubleshoot the regular API key.
- Start a new browser/private session to avoid old conversation context.
- Ask a question with a known answer in a synchronized source.
- Check Chat History for status, error, routing, knowledge, and tool details.
- Change one assistant field and repeat the same test.
Fields, controls, and important values
Section titled “Fields, controls, and important values”These clues show whether the profile you edited is actually the one producing replies. The active identifier selects the runtime profile, the model must support the request, and instructions must be clear enough for the model to follow without contradiction. Logs help distinguish those problems from missing knowledge, tool failures, or frontend issues.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| Active badge | Confirms the local ID used by runtime. | For “Active badge”, the practical behavior is: Confirms the local ID used by runtime. This matters to future conversations only when the edited profile is active; presentation-only values can change what visitors see without changing the model’s reasoning. |
| Model | Must be compatible with the plugin Responses API request. | Select “Model” for the audience and workflow actually being served. Review fresh output after the change—especially instructions and policy-sensitive text—because generated language can sound polished while changing meaning. |
| Instructions | Should define scope and missing-information behavior without contradictory rules. | Shape “Instructions” around one clear job. If the model reads it, remove ambiguity that could alter an answer or tool call; if visitors read it, help them ask a question the configured knowledge can genuinely support. |
| Chat History diagnostics | Records success/error, model, duration, tokens, knowledge routing, and tools when available. | Changing “Chat History diagnostics” only changes the administrator’s view. Keep the selection focused enough to compare similar conversations, and avoid treating a visible pattern as proof until individual rows support it. |
How to confirm it is working
Section titled “How to confirm it is working”After saving Assistant Troubleshooting, repeat the final test with clean context. That distinction matters because WordPress can store a valid value even when remote processing, access rules, caching, or delivery prevents it from influencing the real experience.
Practical example
Section titled “Practical example”If an old test still follows previous instructions, compare it with a private-window conversation before concluding activation failed.
Recommended practice
Section titled “Recommended practice”- Change one part of Assistant Troubleshooting at a time and keep a short record of the previous value and test result.
- Compare the same representative prompts before and after the edit so changes in tone, scope, and tool choice are visible.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| No active assistant. | Create or activate a profile; deleting the active profile clears the runtime selection. |
| Answers ignore site content. | Confirm the sources are selected and Synced, then review knowledge diagnostics. |
| Assistant Troubleshooting is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Confirm which local profile is active before editing instructions or blaming the knowledge base. |
| A change on Assistant Troubleshooting does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Confirm which local profile is active before editing instructions or blaming the knowledge base. |
Screen reference
Section titled “Screen reference”- Capture
- Show the Assistants list with the intended active profile and a nearby sanitized error notice or diagnostic callout.
- Show
- Active badge, model, management actions, notice area
- Viewport
- Desktop, 1440 × 900
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text