Updated Nov 1, 2026

Testing and Debugging

What you'll learn

• How to use the Debug button to test pre-actions
• How to test your agent in a live conversation
• How to test an agent through the API and see every message it sent
• How to use log levels and logs to diagnose issues

Before connecting your AI agent to a production channel, it is important to test it thoroughly. AutoTalk provides several tools for testing and debugging agents at different levels.

Debugging pre-actions

If your LLM agent uses pre-actions (configured on the Actions tab), you can test them without running a full conversation:

1. Open the agent and go to the Actions tab.
2. Click the Start Debug button (its hover tooltip reads "Debug all").
3. AutoTalk runs every pre-action step in sequence and shows you the result of each step, including any data produced or errors encountered.

This lets you verify that each step works correctly before the agent goes live. If a step fails, you can fix it and click Start Debug again immediately.

Testing with live conversations

The most realistic way to test an agent is to assign it to a channel and send it messages as a customer would:

1. Assign the agent to a test channel (or a secondary number/account you control).
2. Send messages to that channel from a personal phone or browser.
3. Observe how the agent responds in the AutoTalk inbox.
4. In the conversation view, look for the bot toggle -- this allows you to enable or disable the agent on a per-conversation basis. Use it to switch between automated and manual responses during testing.

What to test

• Common questions: Ask the types of questions your real customers ask most often.
• Edge cases: Try ambiguous, off-topic, or multi-part questions to see how the agent handles them.
• Boundary tests: Ask about topics the agent should decline (to verify your system messages set proper guardrails).
• Tool usage: If the agent has tools configured, trigger scenarios that should cause tool calls and verify the results.
• Long conversations: Continue a conversation over many exchanges to check that context is maintained and the agent does not lose track.

Testing through the API (talkToAgent)

For automated tests and evaluation scripts, an agent can be driven without a real channel. The talkToAgent function sends one message to the agent, as a contact on the agent's own API channel, runs the agent, and returns what came back:

POST /v1/dynadata/type/agents/item/{agentId}/executeFunction/talkToAgent

{"type": "text", "body": {"text": "I'd like to book an appointment"}}

The API key needs the automation:admin scope. type is required -- send it for a text message too: a request without it is refused with 400 and {"error": "missing_fields", "fields": ["type"], "message": "Missing required argument(s): type", …}. It takes one of text, image, audio, video, document, location, options, option or contacts; image, audio, video and document messages need a body.file. Leave contactId out to start with a new API contact, and pass the data.contactId from a previous response to continue the same conversation.

The response uses the /v1 envelope -- success and data -- with what talkToAgent returned inside data. A successful call answers 200:

{
  "success": true,
  "data": {
    "success": true,
    "contactId": "…",
    "messages": [
      {"role": "assistant", "body": {"controlType": "…"}, "type": "control"},
      {"role": "assistant", "content": "Which day suits you?", "type": "text"}
    ],
    "outboundMessages": [
      {"role": "assistant", "messageId": "…", "type": "options", "body": {"…": "…"}},
      {"role": "assistant", "messageId": "…", "type": "text", "content": "Which day suits you?"}
    ],
    "logs": [{"level": "info", "message": "talkToAgent started"}, "…"]
  }
}

• data.messages is the run's reply buffer: what the model wrote, plus internal entries of type: "control" -- tool-call records, for example -- that the contact never sees. It does not include what the agent's tools sent. So when a tool sent the reply and the model wrote nothing after it -- a run that ended tool_reply, which is also how a tool with Ends the turn ends it -- messages holds only internal entries; read outboundMessages to see what the contact got.
• data.outboundMessages is what the contact actually received during the call, oldest first: messages sent by tools -- a document or an options menu from Compose conversation response, for example -- and the final reply, each once. Each entry is {role, messageId, type, content?, body?}: content is the text or caption, and body is kept for every non-text message, so a document keeps its file and a menu its options. Internal status messages are left out, and the list holds at most 50 messages -- 20 in one fallback case below.
• It covers this conversation only. A tool that notified someone else -- a staff member, say -- sent that message to another conversation, so it is not in the list.
• outboundMessages: null means the list could not be read (the reason is in logs), not that nothing was sent. Nothing sent is an empty list.
• The list is read from the conversation by time, so anything else that sends to the same contact during the call -- a second talkToAgent with the same contactId, or a workflow reacting to the message -- shows up as well.
• Fallback. When the run's reply buffer does not come back to the call, messages is read from the conversation instead: at most 20 of the agent's messages, so it does include what tools sent, and internal entries too. That happens when another run was already answering this contact (the call waits for that run's messages), or when nothing came back from the run at all. In the second case outboundMessages comes from that same read, without the internal entries, so it holds at most 20 messages instead of 50. Either way the call stops waiting at the first read that finds any of the agent's messages, so if the run was still sending at that moment, both lists can be incomplete. In the first case outboundMessages comes from a second read of the conversation made after that one, so a message the run sent between the two reads is in outboundMessages but not in messages; what it sent after the last read is in neither.

data.success: false means the function ran but refused the message or failed: data.error says why, and data.logs shows how far it got. The HTTP status is still 200 and the outer success is still true -- that one only says the function was called -- so check data.success:

{"success": true, "data": {"success": false, "error": "For text messages, body.text must be a non-empty string.", "logs": []}}

A request the API refuses, or one that fails outside talkToAgent itself, has no data: it answers with an error status and an error object. A key without automation:admin gets 403 with {"error": "scope_denied", "code": "scope_denied", "message": "…", "userMessage": "…", "details": {…}}, an agent id that does not exist gets 400 with {"error": "not_found", …}, and most unexpected failures get 400 as well, with {"error": "dynadata_function_error", "code": "execution_error", "message": "…", "userMessage": "…", "details": null}. Only a failure outside the function call itself gets 500, with {"success": false, "errorId": "…", "message": "Internal server error"}.

Using log levels for debugging

Every agent has a Log Level setting on its configuration form. During testing and debugging, set this to a higher verbosity level to capture more detail about what the agent is doing internally.

Once the agent is stable and running in production, you can lower the log level to reduce noise and storage usage. See Viewing Logs for details on where to find and read the logs.

Common issues and fixes

Issue	Possible cause	Fix
Agent gives inaccurate information	System messages are too vague or missing key facts	Add more specific details to the system messages on the Messages tab
Agent does not use its tools	Tool descriptions are unclear or the tool choice is misconfigured	Review tool descriptions on the Tools tab and ensure tool choice is set to "auto"
Responses are too long or rambling	Temperature is too high or max tokens is not set	Lower the temperature on the Advanced tab and set a max token limit
Agent responds to topics it should avoid	Missing guardrails in system messages	Add explicit "do not" instructions to the system messages
Pre-actions fail silently	A step has incorrect configuration	Use the "Start Debug" button (tooltip "Debug all") on the Actions tab to identify the failing step
Agent does not respond at all	The agent is not assigned to the channel, or the bot toggle is off	Check channel assignment and verify the bot toggle is enabled in the conversation
Agent sends an options menu, then more text below it	The model took another turn after the menu tool	Turn on Ends the turn on that tool (see System messages and tools)

Next steps

• Viewing logs
• System messages and tools