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

# Tickets

> Key data extracted from your ITSM, translated for 2501's pipeline

A **Ticket** is 2501's mirror of an incident or change request in your ITSM. It is not a copy of every field — only what the gateway needs to route, dispatch, and report back: title, description, comments, attachments, assignment group, requester, environment, priority.

Once a ticket exists in 2501, the [gateway](/0.9/core-concepts/gateways) decides whether it is in scope. In-scope tickets become a [Job](/0.9/core-concepts/jobs) made of one or more [Tasks](/0.9/core-concepts/tasks). Out-of-scope tickets are dropped silently.

## What's in a ticket record

| Field                         | Source                                               |
| ----------------------------- | ---------------------------------------------------- |
| Title, body, priority         | ITSM record                                          |
| Comments + attachments        | ITSM record, parsed by the tenant's multimodal model |
| Assignment group, environment | ITSM record — used as routing filters                |
| Requester / caller            | ITSM record                                          |
| Status mirror                 | Updated as the job progresses                        |

The Tickets page in Command Center shows every ticket that reached 2501, including those that were deduplicated, dropped, or escalated.

## Ticket → job → task

```
Ticket (ITSM record mirror)
  │
  ▼ gateway parses and routes
Job (the unit of work for this ticket)
  │
  ├─▶ Task 1 (agent A on host X)
  ├─▶ Task 2 (agent B on host Y)
  └─▶ Task N ...
```

A job is at most 5 tasks. Tasks within a job may run in sequence or parallel depending on host targets. See [Agentic Flow](/0.9/understand/agentic-flow) for the lifecycle and [Jobs](/0.9/core-concepts/jobs) for orchestration details.

## Visibility back to the ITSM

The gateway posts back at meaningful boundaries — never the full play-by-play:

* A **public comment** with the final outcome (success / partial / no-action explanation)
* **Internal notes** for intermediate plans, per-task progress, and failure details — visible to operators in the ITSM, not to the requester

This keeps the requester's view focused on the result while preserving the audit trail for your team. See [Gateways → Comment visibility](/0.9/core-concepts/gateways#comment-visibility).

## Tags that change behavior

A few keywords in the ticket body or a comment change how the agent runs:

| Tag                   | Effect                                                                                           |
| --------------------- | ------------------------------------------------------------------------------------------------ |
| `@2501:investigate`   | Force read-only mode for this ticket. Aliases: `@2501:investigation`                             |
| `@2501:remediate`     | Force remediate mode. Aliases: `@2501:remediation`                                               |
| `@2501 <message>`     | Once a job exists, restarts (in progress) or reopens (completed/failed) it with new instructions |
| `@2501 unlink-ticket` | Detach a dedup-linked ticket so it gets its own job                                              |

See [Agents → Execution Modes](/0.9/core-concepts/agents#execution-modes-investigate-vs-remediate) and [Gateways → Working with Active Jobs](/0.9/core-concepts/gateways#working-with-active-jobs).

## Reopening a finished ticket

Once a ticket's job has finished, two things bring the agent back:

* **An `@2501` comment** — an explicit re-request with new instructions.
* **Reopening the ticket in the ITSM** — moving a ServiceNow incident back to
  **New** or **In Progress** (or updating it while it sits in one of those states)
  after the job finished. No mention needed: the platform notices that a person —
  not its own integration account — touched a ticket it considered done, and
  re-engages.

On a state-driven reopen with no new instructions, the agent first **re-verifies
the original symptom** before deciding whether more work is needed. Work completed
before the reopen is treated as belonging to the previous run — it can't satisfy
the reopened request on its own — while the agent still uses it as context. If
verification shows the issue is genuinely resolved, the agent closes the ticket
out again with an explanatory comment.

Updates made by the platform's own ServiceNow account never trigger a reopen, so
the agent's closing comments and status changes don't re-trigger itself.