Troubleshoot an incorrect or unsupported answer
Trace a weak Agent answer to Knowledge, catalog, guidance, tools, or an unsupported request without adding conflicting fixes.
Diagnose the smallest layer responsible for an incorrect, missing, unsupported, or unsourced answer. A disciplined trace prevents a quick instruction from masking stale source data.
An Agent combines instructions, customer-facing interface settings, Knowledge, catalog data, and optional tools. A reliable setup is tested with realistic customer questions before deployment. Tests should cover expected answers, missing information, product scenarios, escalation, and any optional interaction that the team has enabled.
Before you begin
Access: Use Playground or test access plus read access to the relevant Agent, Knowledge, catalog, and tools.
- Save the exact customer prompt and response.
- Record the Agent, channel, time, and expected result.
- Remove personal information before sharing the example.
Work in the smallest owning area described below and keep the current customer-facing state available while you prepare the change. Before clicking any final action, confirm the active company, Agent, store, language, and market shown in Humind. A missing control can indicate read-only access or a capability that is not configured for this company. In that case, record the intended task and ask an administrator to review the exact permission or dependency. Do not bypass the boundary by sharing an account, copying data into another area, or promising a capability that the workspace does not expose.
Step-by-step workflow
Reproduce the response
Run the same prompt in the closest available test surface. If it cannot be reproduced, compare channel context, market, product, conversation history, and configuration.
- Change no settings during the first reproduction.
- Capture the smallest repeatable prompt.
Identify the required source
Decide whether the answer should come from Knowledge, catalog data, Agent guidance, or a configured tool. Unsupported requests should have a safe boundary rather than fabricated completion.
- Open the authoritative source.
- Check visibility, lifecycle, sync, and indexing state.
Apply one focused correction
Update the authoritative source when facts are wrong, guidance when behavior is wrong, or tool configuration when an available action fails. Do not duplicate the fact in several layers.
- Document the exact change.
- Wait for required synchronization or indexing.
Retest and add regression coverage
Repeat the original prompt and a nearby boundary case. Add the failure to a Batch Test when it represents a recurring or high-impact customer journey.
- Compare before and after responses.
- Verify the correction did not broaden unsupported claims.
Important limits and operating notes
- A plausible response can still be unsupported.
- Conversation history may affect a live response.
- Changing several layers at once makes the root cause impossible to prove.
- Unavailable capabilities must remain clearly unavailable in the answer.
Verify the result
- The original failure is reproducible or its context difference is known.
- One authoritative source owns the correction.
- The response now answers or declines safely.
- A regression case protects the corrected journey.
Keep a short record of what you tested, which customer scenario you used, and what changed. This makes later troubleshooting more precise and helps another teammate reproduce the result without relying on memory.
Troubleshooting
No source contains the expected answer
Confirm the information is approved and maintainable, then add it to the appropriate source. If the business has not decided the answer, do not invent one for the Agent.
The correction works only in one channel
Compare the deployed Agent, market, domain, conversation context, and publication state. The content may be correct while the channel still uses a different configuration.