> ## 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.

# Agentic Flow

> Ticket → gateway → job → tasks → resolution, in one page

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

## The flow

<Steps>
  <Step title="Ticket mirrored from the ITSM">
    The gateway mirrors the incoming ticket (plus its comments) into 2501 as a [Ticket](/0.8/core-concepts/tickets) record. Nothing else changes in the ITSM yet.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Job is created">
    Once the gateway has a plan, it creates a [Job](/0.8/core-concepts/jobs) that wraps one or more tasks. A job is the unit of work tied back to the ticket.
  </Step>

  <Step title="Tasks dispatched to agents">
    Each [Task](/0.8/core-concepts/tasks) 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.**
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/0.8/best-practices/dynamic-context).

## Where each piece is configured

| Piece                               | Where                                                                             |
| ----------------------------------- | --------------------------------------------------------------------------------- |
| Who can be picked                   | [Agents](/0.8/core-concepts/agents) + [Hosts](/0.8/core-concepts/hosts) inventory |
| How an agent thinks                 | [Specialty](/0.8/configure/specialties) attached to the agent                     |
| What must always be true            | [Operational Rules](/0.8/configure/operational-rules)                             |
| What must never be run              | [Blacklist](/0.8/configure/blacklist)                                             |
| What the agent knows about your env | [Knowledge](/0.8/configure/knowledge)                                             |
| How tickets become tasks            | [Gateway inbound prompt](/0.8/core-concepts/gateways#inbound-prompt)              |