---
"@context": https://schema.org
"@type": TechArticle
"@id": https://www.twilio.com/docs/conversations/intelligence/troubleshooting#article
headline: Conversation Intelligence troubleshooting
description: Troubleshoot Conversation Intelligence issues, including Debugger logs and response schema validation errors.
url: https://www.twilio.com/docs/conversations/intelligence/troubleshooting
inLanguage: en
dateModified: 2026-09-25T17:35:58.000Z
author:
  "@type": Organization
  name: Twilio Developer Education Team
publisher:
  "@type": Organization
  name: Twilio
---

# Conversation Intelligence troubleshooting

This page covers two common Conversation Intelligence issues: viewing execution logs in the Twilio Console Debugger and resolving response schema validation errors.

## View debugger logs in Twilio Console

To view detailed logs of Conversation Intelligence executions, use the Twilio Console Debugger.

1. Log in to [Twilio Console](https://1console.twilio.com/) and navigate to **Monitor** > **Debugger**.
2. To see Conversation Intelligence-related logs, filter by event source. For example, `conversation-intelligence`, `conversation-memory`.

The log information includes the Log SID, Resource SID, source, log level, timestamp (local), event type, and a log body with detailed error messages and execution metadata. This information can help you identify and troubleshoot issues with your language operators and understand their execution in the context of your conversations.

## Response schema validation errors

Conversation Intelligence strictly enforces your output schema and always modifies it before sending it to the LLM by marking all object properties as `required`. If a response doesn't match the schema, the language operator execution fails.

### How the system modifies your schema

```json title="Example: Original schema (user-provided)"
{
  "type": "object",
  "properties": {
    "response": {
      "type": "string"
    }
  }
}
```

```json title="Example: Modified schema (system-generated)"
{
  "type": "object",
  "properties": {
    "response": {
      "type": "string"
    }
  },
  "required": ["response"]
}

```

### Language operator failure scenario

A common cause of language operator failure is a conflict between the prompt and the output schema.

For example, if you have a real-time language operator with the on communication trigger, there might be moments in a conversation where the language operator can't find a valid answer. You might then instruct it in the prompt: "If no information is found, return null."

This creates a failure chain:

1. The prompt tells the language operator to return `null`.
2. The language operator correctly returns `{ "response": null }`.
3. The schema expects a `string`. Because `null` isn't a `string`, validation fails and the language operator execution errors out.

Even if the language operator's logic is correct based on your prompt, Conversation Intelligence rejects any response that violates the data types defined in your schema.

### Aligning prompt and schema

To prevent language operators from failing, your output schema must account for all possible LLM responses mentioned in your prompt. If you want the ability to return a `null` or an empty state, you must use a union type in your schema.

If your prompt allows for a null response, update your schema to accept both string and null:

```json title="Example: Updated schema to allow null response"
{
  "type": "object",
  "properties": {
    "response": {
      "type": ["string", "null"]
    }
  }
}
```