> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Flag an issue

> Prepare an issue-review process and use existing conversation tags or feedback without assuming an automatic issue-flagging tool.

An issue flag should identify a specific conversation that needs review and explain why. Keep the observation, expected behavior, and next reviewer separate from an automated decision about severity.

<Note>
  `flag_issue` is not an accepted built-in tool type in the current API. This guide does not establish automatic issue detection, ticket creation, notifications, or callbacks during a conversation.
</Note>

## Review an existing conversation

<Steps>
  <Step title="Inspect the record">
    Use [conversation inspection](/agents-platform/monitor/conversations) and [Get conversation details](/api-reference/agents-platform/get-conversation-details). Confirm the conversation and agent identifiers before recording a concern.
  </Step>

  <Step title="Describe the evidence">
    Record the relevant turn or event, what you expected, and what the stored record shows. Distinguish an unavailable tool from an incorrect answer. Keep unnecessary private information out of review notes.
  </Step>

  <Step title="Use a tag for categorization">
    If your workspace uses review tags, [Add tag to conversation](/api-reference/agents-platform/add-tag-to-conversation) accepts a `tag_ids` list. Use existing tag identifiers from the same workspace. Repeated assignments are ignored; a tag is a category, not a notification or an assigned ticket.
  </Step>

  <Step title="Record feedback separately">
    [Send conversation feedback](/api-reference/agents-platform/send-conversation-feedback) accepts `feedback` with `like`, `dislike`, or `null`. It does not accept an arbitrary issue title, severity, or reviewer assignment. Do not confuse a negative rating with a complete incident record.
  </Step>
</Steps>

## Prepare a future issue process

| Decision | What to define |
| - | - |
| Trigger | The observable condition that warrants review. |
| Evidence | Conversation ID, relevant turn, and expected outcome. |
| Owner | The person or service responsible for reviewing the concern. |
| Follow-up | How that owner records resolution and verifies a correction. |

Keep this process in your existing review system until a supported integration is available. Do not tell a user that a ticket was created or someone was notified unless the responsible service confirms it.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does adding a tag alert my team?" id="faq-flag-issue-notification">
    No notification behavior is established by the tag operation. It categorizes the stored conversation. Configure and verify any separate review or notification process independently.
  </Accordion>

  <Accordion title="Can I add flag_issue through Edit as JSON?" id="faq-flag-issue-type">
    No. It is not an accepted system-tool type. Use the existing conversation-management operations for manual review instead of inventing a tool definition.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.