Skip to main content
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 decides whether it is in scope. In-scope tickets become a Job made of one or more Tasks. Out-of-scope tickets are dropped silently.

​
What’s in a ticket record

FieldSource
Title, body, priorityITSM record
Comments + attachmentsITSM record, parsed by the tenant’s multimodal model
Assignment group, environmentITSM record — used as routing filters
Requester / callerITSM record
Status mirrorUpdated 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

A job is at most 5 tasks. Tasks within a job may run in sequence or parallel depending on host targets. See Agentic Flow for the lifecycle and 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.

​
Tags that change behavior

A few keywords in the ticket body or a comment change how the agent runs:
TagEffect
@2501:investigateForce read-only mode for this ticket. Aliases: @2501:investigation
@2501:remediateForce remediate mode. Aliases: @2501:remediation
@2501 <message>Once a job exists, restarts (in progress) or reopens (completed/failed) it with new instructions
@2501 unlink-ticketDetach a dedup-linked ticket so it gets its own job
See Agents → Execution Modes and 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.