Skip to main content
A ticket lands in your ITSM and 2501 takes it through this lifecycle, end to end.

The flow

1

Ticket mirrored from the ITSM

The gateway mirrors the incoming ticket (plus its comments) into 2501 as a Ticket record. Nothing else changes in the ITSM yet.
2

Gateway parses and judges feasibility

The gateway uses the tenant’s text LLM to read the ticket, parse attachments with the multimodal model, and decide whether the request is in scope. It looks at registered hosts, available agents, and applicable rules to figure out which agent should handle it.
3

Job is created

Once the gateway has a plan, it creates a Job that wraps one or more tasks. A job is the unit of work tied back to the ticket.
4

Tasks dispatched to agents

Each Task targets a single agent on a single host. The agent receives the task description plus dynamically injected operational rules, knowledge facts, and credentials. One task = one agent. One job = N tasks, possibly across N agents.
5

Agent runs, observes, adapts, reports back

The agent executes autonomously until it has a result. The orchestrator reads that result and decides whether the ticket is resolved or whether another task is needed.
6

Job terminates

On success: the gateway closes the ticket with a summary. On failure or partial: the gateway posts a work note. After each task, the gateway comments incremental progress back to the ITSM for atomic visibility.

The 5-task ceiling

A job is capped at 5 tasks. This is a hard limit set after observing thousands of tickets:
  • Most jobs need 1–3 tasks
  • Headroom for 2 more tasks covers multi-host coordination (e.g. master + slave) or deeper investigation
  • If 5 tasks complete and the ticket is still not resolved, the job is automatically marked failed
The ceiling prevents agents from running indefinitely on unbounded problems.

Where rules and knowledge come in

The gateway and the agent both inject context at runtime:
  • Operational Rules match by tag against the target host and the inferred task action, then surface up front.
  • Knowledge facts about the host get attached automatically.
  • Credentials scoped to the agent’s host are made available for tool calls.
  • Mid-task, the agent can pull additional rules or facts on demand if the situation evolves.
For the deeper mechanics, see Dynamic Context Injection.

Where each piece is configured

PieceWhere
Who can be pickedAgents + Hosts inventory
How an agent thinksSpecialty attached to the agent
What must always be trueOperational Rules
What must never be runBlacklist
What the agent knows about your envKnowledge
How tickets become tasksGateway routing prompt