Debug with AI
AI funding and usage
AI included uses REDA credits. Bring your own AI uses your organisation’s provider account, billed directly by that provider. The licence selects one funding model for the organisation. In either model, REDA AI governs configured tools and actions in Salesforce. Set up your licence and AI accounts.
In customer-account mode, the selected model determines which Deep Reasoning levels and capabilities are available. Review the AI Account selector’s supported levels and warnings; do not assume every provider supports the same combination. Admin AI tools and document processing use the organisation default connection. Configure the default and test the workflow.
What It Does
Hard failures in agent runs land in the Incident Log — Apex exceptions, callout errors, validation rule failures, configuration mistakes that prevented a tool call from completing. The raw log captures the technical detail (stack trace, error context, class and method) but leaves the interpretation to whoever reads it.
Debug with AI is the assistant that reads the log for you. It explains what the error means, makes a confident guess about the cause, and proposes specific fixes. Because it’s a conversation, you can push back, ask for more detail, or pivot the analysis when the first answer doesn’t fit.
Multi-Turn, Not One-Shot
Unlike a single-pass analyser, Debug with AI is conversational. The first turn produces an initial assessment from the incident’s raw data; subsequent turns let you steer the diagnosis:
- “What configuration would cause this specific error?”
- “Could field-level security be involved?”
- “Show me the agent setting that controls this behaviour.”
- “Why didn’t the validation rule message reach the user?”
Each follow-up consumes a small additional credit budget but typically produces a sharper answer than the first turn alone.
How a Run Works
-
Open the incident
From the AI Incident Logs tab or directly from an Incident Log record.
-
Availability check
Before the Debug button is enabled, the platform checks that AI debugging is available — license active, credits remaining, feature switch on. If any of those fails, you see a clear reason rather than a generic error.
-
Click Debug with AI
The first turn assembles the incident’s details and the relevant context (class name, method, stack trace, error message, the conversation it occurred in) and sends them to the model.
-
Read the initial assessment
A panel renders the response — explanation, root-cause guess, suggested resolution steps.
-
Ask follow-ups
Type a follow-up question; the platform sends the conversation history along with your question for context. The model’s reply lands in the same panel.
-
Save the final analysis
When you have an answer you trust, save it to the incident’s Resolution Notes field. The next admin who opens the incident reads your work without re-running the AI — but copy out any notes already there first, because saving overwrites them.
What the Debugger Sees
The Debugger is given far more than the error text. Every run assembles:
- The incident itself — error type, message, context, severity, status, class name, method name, line number, stack trace, and any resolution notes already recorded.
- The agent’s configuration, when the incident is linked to one — display name, channel, the first part of its persona, and its default context objects.
- The agent’s active custom prompts, up to five, each as a snippet.
- The agent’s active tools, up to ten, with type and description.
- A configuration-conflict report for that agent — see below.
- The conversation’s context, when the failure happened inside one — its channel, context object and context record Id.
- This debug session’s own history on follow-up turns, so it builds on what it already said rather than restarting.
The conflict report is not the model’s opinion. Before the prompt is sent, REDA AI runs a deterministic check over the agent’s configuration and writes its findings into the prompt as fact. So when the Debugger says two prompts contradict each other, that came from an analysis of the configuration, not from the model’s reading of your error. If that check fails for any reason it is skipped silently and the rest of the diagnosis proceeds unaffected.
What it is not given is the conversation’s message text. It sees which conversation failed and in what context, not what was said in it. If the wording of the exchange matters, open the conversation yourself — or use the Conversation Debugger, which is built for exactly that.
What the Debugger Will and Won’t Tell You
The Debugger has a deliberate guardrail: it explains your Apex (custom executor classes, your Flows, your validation rules) in detail, but does not expose the internals of the REDA AI managed package. Questions about how the platform works under the hood are politely declined — the Debugger points you back to the public documentation instead.
This isn’t about hiding bugs — it’s about keeping the analysis useful. The fixes you can apply are in your code and configuration, not inside the package. Steering the conversation toward those is what produces actionable advice.
Saving the Analysis
Saving writes the analysis into the incident’s Resolution Notes field. There is no separate “debug analysis” field — the explanation lands in the same place a human would type their own findings.
Saving replaces whatever is already in Resolution Notes. It is an overwrite, not an append. If you or a colleague have already written notes on the incident, copy them somewhere first, or paste the AI’s explanation in yourself underneath them.
Saving also moves the incident on: an incident still at New is set to Investigating automatically. An incident already at Investigating, Resolved or Dismissed keeps the status it has.
- Later readers see the explanation on the record, without re-running the model.
- The text can be copied into a runbook or an escalation ticket.
- Re-running Debug with AI starts a fresh conversation — it does not read the saved text back in.
Credit Cost
Each turn is a model call. Cost scales with the size of the incident’s context (stack traces and conversation snippets are the biggest variables) plus your follow-up’s length. The platform reports actual credits consumed.
First turns cost more than follow-ups because the incident’s full context is sent on every turn for grounding. Several follow-up turns on a long stack trace can add up; if you find yourself asking the same kind of question across many incidents, summarise the answer in a runbook so future incidents reference the existing knowledge instead of re-asking.
With AI included, a callout timeout can incur the documented 20-credit charge. With Bring your own AI, REDA does not deduct a credit allowance; your provider controls its billing. Check the recorded usage and the error before retrying. A timeout by itself does not establish the cause.
The reply itself is capped by the Debugger Max Output Tokens platform setting, 3,000 by default. If answers are being cut off mid-explanation, that is the setting to raise — a longer answer costs more credits, so raise it deliberately.
How It Differs From the Conversation Debugger
- Conversation Debugger — for cases where the conversation completed but the agent gave the wrong answer or skipped a step. Returns a structured root-cause analysis.
- Debug with AI on Incidents — for hard failures where the conversation crashed or a tool errored. Multi-turn conversational analysis on the Incident Log record.
Most behavioural problems start in the Conversation Debugger. Errors that show up as Incident Logs go here.
What Debug with AI Does Not Do
- It doesn’t apply fixes. The output is advisory; you make the configuration or code change yourself.
- It doesn’t reproduce the failure. Each analysis is on the captured incident only. To verify a fix, run the operation again and check whether a new incident is created.
- It doesn’t resolve incidents automatically. The incident stays open until you mark it resolved — the AI doesn’t change record status.
- It doesn’t expose package internals. Custom Apex you wrote is fair game; the managed package’s implementation is not.
Best Practices
Start broad, narrow with follow-ups. The first turn produces a general assessment; the value of the conversation comes from your follow-ups pinning down the root cause.
Save the analysis when you’re done. Incidents are forgettable. The saved analysis is what makes the next run-through useful.
Quote the user’s prompt back. If the failure happened mid-conversation, ask the Debugger about the specific user turn that triggered the failure. Tightly-scoped questions produce tighter answers.
Don’t ask the Debugger to dump the package. The guardrail will refuse, costing a credit for nothing. Phrase the question as “what configuration in my Apex/Flow/agent could cause this?” instead.
Pair with the Conversation Debugger when the failure happened mid-run. If the conversation has both an incident and a behavioural symptom, run both debuggers; the two together usually pin down what went wrong.
Frequently Asked Questions
It’s a chat. The first turn produces an assessment from the incident details; you can ask follow-up questions, and the platform passes the conversation history back to the model so subsequent turns build on previous answers.
The platform runs an availability check before enabling the button — license must be active, credits must be available, the feature switch must be on. If any of those fails, the UI explains why instead of letting you click.
No. The guardrail is explicit: questions about the package’s internal implementation are declined. The Debugger focuses on configuration and your custom Apex — the things you can actually change.
Into the incident’s Resolution Notes field — the same field a human writes findings in. It overwrites whatever is already there, and moves an incident still at New to Investigating.
Yes — every turn is a model call. The actual credit consumption is reported on screen and depends on the size of the incident context plus the follow-up question.
Yes. Incidents are channel-agnostic — whether the failure happened in the internal widget, an external widget, an inbound email run or a Flow-driven async run, the incident record looks the same and the Debugger inspects it identically.
Push back in the conversation. “That can’t be it because…” or “I’ve already verified X…” redirect the analysis. The conversational form is what lets you get past the model’s first guess when it’s wrong.
Next Steps
Read AI Incident Logs for the underlying record structure, or Conversation Debugger for diagnosing behavioural failures where the conversation ran but produced the wrong outcome.